HAR File Analyzer

Tính năng nổi bật

• Đọc file HAR chuẩn 1.2 xuất từ Chrome, Edge, Firefox, Safari và các trình duyệt nhân Chromium
• Tổng số request, tổng dung lượng truyền trên đường mạng và tổng dung lượng gốc chưa nén
• Thời gian tải lấy từ mốc onLoad của trang, kèm độ dài toàn phiên tính từ request đầu tới request cuối
• Phân bổ dung lượng theo bảy nhóm tài nguyên: document, script, stylesheet, hình ảnh, font, XHR và media
• Biểu đồ waterfall bằng SVG chia rõ sáu pha: chờ hàng đợi, DNS, kết nối, gửi, chờ máy chủ và nhận dữ liệu
• Bảng request chậm nhất và request nặng nhất, đổi qua lại bằng một nút bấm
• Phân bổ theo tên miền và thống kê mã trạng thái để thấy ngay bên thứ ba nào đang chiếm băng thông
• Sáu nhóm cảnh báo: chuyển hướng nhiều lần, tài nguyên không nén, thiếu khai báo cache, chờ máy chủ lâu, hàng đợi dài và request lỗi

Vì sao đọc lại file HAR có giá trị khác hẳn việc chấm điểm một địa chỉ

Các công cụ chấm điểm tốc độ đều làm cùng một việc: tự mở trang bằng một trình duyệt trên máy chủ của họ, đo rồi trả về điểm số. Cách đó rất tiện nhưng có ba giới hạn mà bất kỳ ai từng đi tìm nguyên nhân trang chậm đều gặp. Thứ nhất, nó chỉ vào được những trang công khai, còn khu vực sau đăng nhập, trang giỏ hàng, trang quản trị hay ứng dụng nội bộ thì nằm ngoài tầm với. Thứ hai, nó đo từ vị trí máy chủ của công cụ chứ không phải từ chỗ khách hàng của bạn ngồi, nên độ trễ đường truyền và cả kết quả phân giải tên miền đều khác. Thứ ba, nó không nhìn thấy những gì chỉ xảy ra trên máy người dùng thật, chẳng hạn tiện ích mở rộng chèn thêm request, mạng công ty chặn một tài nguyên, hay bộ nhớ đệm còn giữ bản cũ. File HAR giải quyết cả ba: nó là bản ghi chính xác của phiên tải đã thực sự diễn ra trên máy bạn, ở mạng của bạn, với tài khoản của bạn. Khi khách hàng báo trang chậm mà bạn kiểm tra thì thấy nhanh, xin họ một file HAR là cách nhanh nhất để nhìn đúng thứ họ đã nhìn thấy.

Lợi ích khi sử dụng

• •Nhìn được cả phần sau đăng nhập, nơi các công cụ chấm điểm từ xa không vào được
• •Tách bạch thời gian chờ máy chủ với thời gian tải dữ liệu, nên biết nên sửa phía nào
• •Thấy ngay tên miền bên thứ ba nào đang chiếm băng thông và làm chậm trang
• •Nhận file HAR do chính khách hàng gửi để tái hiện đúng vấn đề họ gặp
• •Toàn bộ xử lý trong trình duyệt nên dùng được với dữ liệu của hệ thống nội bộ

Cách xuất và phân tích file HAR

1. 1Mở trang cần đo, nhấn F12 để mở công cụ dành cho nhà phát triển rồi chuyển sang tab Network.
2. 2Tích ô giữ lại nhật ký nếu trang có chuyển hướng, sau đó tải lại trang để ghi trọn phiên tải từ request đầu tiên.
3. 3Khi trang tải xong, bấm chuột phải vào danh sách request và chọn mục lưu tất cả thành HAR. Nếu chỉ cần đo hiệu năng, hãy chọn cách lưu không kèm nội dung phản hồi để tệp nhẹ hơn và bớt dữ liệu nhạy cảm.
4. 4Kéo tệp vừa lưu vào khung tải lên trên trang này, hoặc bấm vào khung để chọn tệp từ máy.
5. 5Đọc phần tổng quan trước, rồi tới bảng phân bổ theo loại tài nguyên, rồi xem waterfall để biết thứ tự thời gian, cuối cùng đọc danh sách vấn đề để có việc cụ thể cần sửa.

File HAR là dữ liệu nhạy cảm, hãy đối xử với nó như với mật khẩu

Đây là điều cần nói trước mọi thứ khác. Một file HAR ghi lại toàn bộ header của từng request và từng phản hồi trong phiên tải, nghĩa là nó chứa cookie phiên đăng nhập của bạn, header xác thực dạng Authorization mang theo mã thông báo, khóa API gửi kèm, và tùy tùy chọn khi xuất còn có thể chứa cả nội dung request lẫn nội dung phản hồi. Cookie phiên là thứ đủ để đăng nhập vào tài khoản mà không cần biết mật khẩu, chừng nào phiên đó còn hiệu lực. Vì vậy một file HAR gửi nhầm vào một kênh chat chung, đính kèm vào ticket công khai hay đăng lên diễn đàn hỏi đáp là một sự cố bảo mật thật sự chứ không phải chuyện nhỏ. Nguyên tắc an toàn gồm mấy điểm: khi xuất chỉ để đo hiệu năng thì chọn cách lưu không kèm nội dung phản hồi, ghi lại phiên bằng cửa sổ ẩn danh với tài khoản thử nghiệm nếu có thể, chỉ gửi cho người thật sự cần và qua kênh riêng tư, và sau khi gửi thì đăng xuất để vô hiệu hóa phiên đã bị lộ trong tệp. Riêng công cụ này xử lý toàn bộ bằng JavaScript ngay trên máy bạn, không có bước tải lên, không ghi vào cơ sở dữ liệu, không lưu vào bộ nhớ trình duyệt, và tải lại trang là kết quả biến mất.

Sáu pha của một request và pha nào chỉ ra vấn đề gì

Mỗi thanh trong biểu đồ waterfall chia thành sáu pha, và biết pha nào dài giúp bạn đi thẳng tới nguyên nhân thay vì đoán. Pha chờ hàng đợi là khoảng thời gian request đã được tạo nhưng chưa được gửi đi, thường do trình duyệt giới hạn số kết nối đồng thời tới cùng một tên miền, hoặc do luồng chính đang bận. Pha phân giải tên miền là thời gian tra cứu địa chỉ máy chủ, chỉ xuất hiện ở request đầu tiên tới mỗi tên miền mới, nên nhiều tên miền bên thứ ba đồng nghĩa với nhiều lần tra cứu. Pha kết nối và mã hóa là thời gian bắt tay với máy chủ, cũng chỉ tính cho kết nối mới. Pha gửi gần như luôn rất ngắn trừ khi bạn tải tệp lớn lên. Pha chờ máy chủ là khoảng từ lúc gửi xong tới lúc nhận được byte đầu tiên, phản ánh thời gian máy chủ xử lý cộng với độ trễ đường truyền hai chiều. Pha nhận dữ liệu là thời gian tải hết nội dung, tỷ lệ với dung lượng và băng thông. Quy tắc đọc nhanh: pha chờ máy chủ dài thì sửa phía máy chủ hoặc đưa nội dung ra gần người dùng hơn, pha nhận dữ liệu dài thì giảm dung lượng, pha chờ hàng đợi dài thì giảm số request hoặc nâng cấp giao thức.

Dung lượng truyền và dung lượng gốc là hai con số khác nhau

Bảng tổng quan hiển thị hai con số dễ bị nhầm lẫn. Dung lượng truyền là số byte thực sự đi qua đường mạng, tức là dung lượng sau khi đã nén cộng với phần header. Dung lượng gốc là kích thước nội dung sau khi trình duyệt giải nén, tức là thứ mà mã JavaScript phải phân tích và trình duyệt phải dựng lên. Cả hai đều quan trọng nhưng cho hai loại kết luận khác nhau. Dung lượng truyền quyết định thời gian tải trên mạng chậm và quyết định hóa đơn băng thông. Dung lượng gốc quyết định thời gian trình duyệt xử lý, và với JavaScript thì đây mới là con số đáng lo, vì một tệp nén còn hai trăm kilobyte nhưng giải ra bảy trăm kilobyte vẫn phải được phân tích cú pháp và biên dịch đủ bảy trăm kilobyte trên chiếc điện thoại tầm trung của người dùng. Khoảng cách giữa hai con số cũng chính là thước đo hiệu quả nén: với HTML, CSS, JavaScript và JSON, mức nén tốt thường đưa dung lượng truyền xuống còn khoảng một phần ba so với bản gốc. Nếu hai con số gần bằng nhau ở nhóm tài nguyên văn bản, gần như chắc chắn máy chủ chưa bật nén, và đó là thứ sửa được trong vài phút cấu hình.

Chuỗi chuyển hướng: chi phí ẩn thường bị bỏ qua nhất

Chuyển hướng là thứ dễ tích tụ theo thời gian mà không ai để ý, vì mỗi lần thêm một luật đều có lý do chính đáng riêng. Một trang có thể đi từ địa chỉ không bảo mật sang địa chỉ bảo mật, rồi từ tên miền không có tiền tố sang tên miền có tiền tố, rồi từ đường dẫn cũ sang đường dẫn mới sau một lần đổi cấu trúc, và thế là ba lần chuyển hướng trước khi nội dung thật bắt đầu tải. Chi phí không chỉ là ba lần đi về máy chủ. Nếu các bước nằm trên tên miền khác nhau thì mỗi bước còn phải tra cứu tên miền và bắt tay mã hóa lại từ đầu, và trên mạng di động với độ trễ cao thì tổng chi phí có thể lên tới cả giây trước khi byte đầu tiên của trang thật xuất hiện. Với công cụ tìm kiếm, chuỗi chuyển hướng dài còn làm loãng tín hiệu liên kết và tiêu tốn ngân sách thu thập dữ liệu. Công cụ này ghép các bước chuyển hướng liên tiếp thành chuỗi và báo động khi chuỗi có từ hai bước trở lên. Cách sửa gồm hai phần: gộp các luật ở tầng máy chủ để mọi địa chỉ đầu vào nhảy thẳng một bước tới địa chỉ cuối cùng, và sửa nguồn gốc bằng cách cập nhật liên kết trong trang, trong quảng cáo và trong sơ đồ trang web để chúng trỏ thẳng tới địa chỉ đúng.

Đọc kết quả theo thứ tự nào để tìm ra việc cần làm

Một phiên tải trung bình có hàng trăm request, nên nhìn vào bảng chi tiết trước sẽ rất dễ lạc. Thứ tự đọc hiệu quả bắt đầu từ bốn con số tổng quan. Nếu tổng dung lượng truyền vượt quá vài megabyte thì vấn đề là dung lượng, hãy đi thẳng xuống bảng phân bổ theo loại tài nguyên để biết nhóm nào chiếm phần lớn, thường là hình ảnh hoặc JavaScript. Nếu tổng dung lượng ổn mà thời gian tải vẫn dài, hãy nhìn tổng thời gian chờ máy chủ: con số này lớn nghĩa là thời gian trôi vào việc chờ chứ không phải việc tải, và cách sửa nằm ở phía máy chủ. Tiếp theo mở waterfall để xem hình dạng chung. Nếu các thanh xếp thành bậc thang nối tiếp thay vì chồng lên nhau thì có phụ thuộc dây chuyền, thường là một tệp phải tải xong mới biết cần tải tệp tiếp theo, và cách sửa là khai báo tải trước cho tài nguyên quan trọng. Nếu nhiều thanh cùng bắt đầu một lúc nhưng phần chờ hàng đợi rất dài thì đang nghẽn số kết nối đồng thời. Cuối cùng mới đọc danh sách vấn đề, vì đến lúc này bạn đã có bối cảnh để biết mục nào đáng sửa trước. Nguyên tắc chọn việc là sửa thứ vừa dễ vừa ảnh hưởng lớn trước, thường là bật nén và đặt thời hạn cache, rồi mới tới việc tốn công như tách gói JavaScript.

Câu hỏi thường gặp (FAQ)

Từ khóa liên quan

• phân tích file har
• har file analyzer online
• đọc file har
• cách xuất file har chrome
• har viewer tiếng việt
• phân tích waterfall network
• kiểm tra tốc độ tải trang bằng har
• file har chứa gì
• file har có nhạy cảm không
• tab network devtools
• thời gian chờ máy chủ ttfb
• request bị chuyển hướng nhiều lần
• tài nguyên không được nén gzip
• kiểm tra cache-control
• phân bổ dung lượng theo loại tài nguyên
• top request chậm nhất
• thống kê mã trạng thái http
• công cụ phân tích hiệu năng web
• har analyzer không cần upload
• tối ưu tốc độ website từ har