Kiểm tra tốc độ trang với tab Performance

[Nhật Quang]

Tab Performance trong Chrome DevTools cho phép bạn kiểm tra sâu hiệu năng trang, từ thời gian tải ban đầu đến độ phản hồi khi người dùng tương tác. Bài viết hướng dẫn cách thu thập profile, đọc các biểu đồ chính và tìm nguyên nhân gây chậm.

Tab Performance của Chrome DevTools chứa rất nhiều công cụ để phân tích hiệu năng trang một cách chi tiết. Bạn có thể dùng nó để kiểm tra cả quá trình tải ban đầu lẫn độ phản hồi với thao tác người dùng, được đo bằng chỉ số Interaction to Next Paint của Google.

Để mở tab Performance, truy cập trang web muốn kiểm tra rồi mở Chrome DevTools bằng cách nhấp phải và chọn Inspect (Kiểm tra).
/assets/images/open-devtools-d634b5b280c1902f76cfd003b8d7ce79.png

Trong DevTools, chọn tab Performance. Cách dễ nhất để chụp profile là nhấn biểu tượng Start profiling and reload page (Bắt đầu ghi và tải lại trang). Profil sẽ dừng tự động khi CPU và hoạt động mạng ổn định.
/assets/images/performance-tab-9d39433156d96067b40c4909193a0492.png

Bạn có thể chạy thử nghiệm trong chế độ ẩn danh vì các extension của Chrome có thể ảnh hưởng đến hiệu năng.

Một profile Performance có thể khá phức tạp, nhưng chính việc có nhiều loại dữ liệu sẽ giúp bạn đối chiếu hoạt động CPU, mạng và cập nhật giao diện để tìm ra nguyên nhân gây chậm.

Biểu đồ sử dụng CPU​

Biểu đồ CPU cho thấy mức độ bận rộn của CPU theo các loại tác vụ khác nhau, thường là JavaScript (màu vàng) và công việc Layout (màu tím). Thông thường CPU sẽ im dần sau đợt hoạt động ban đầu, giống như trên trang chủ của Stripe.
/assets/images/stripe-cpu-utilization-96cd6cc29ba4267e25888382a4143180.png

Tuy nhiên, trên một số trang (ví dụ Asana) CPU vẫn bận sau khi trang đã tải xong, điều này khiến trang khó tương tác, đặc biệt trên thiết bị yếu hơn.
/assets/images/asana-cpu-utilization-ed904a3c925f645d81860b311fe5cf30.png

Filmstrip — theo dõi tiến trình hiển thị​

Filmstrip ghi lại tiến trình render trang theo từng khung hình; rê chuột lên filmstrip để xem ảnh chụp tại thời điểm đó. Khi dùng tùy chọn Start profiling and reload page, filmstrip thường hiện trang đã được render đầy đủ từ đầu, khiến khó xác định thời điểm bắt đầu render.
/assets/images/stripe-filmstrip-f3f7795c1a05d5bf47057afd3e3c68d0.png

Bạn có thể ghi filmstrip bắt đầu từ trang trắng để thấy quá trình render dần dần, kèm network throttling để quá trình diễn ra chậm hơn và dễ quan sát.
/assets/images/stripe-filmstrip-2-3b7eb47cbc93d1d90d282a2649105637.png

Phần mạng và waterfall​

Phần network hiển thị waterfall các yêu cầu, bắt đầu với HTML ở trên cùng rồi đến các yêu cầu tiếp theo. Nhấp vào từng request để xem URL đầy đủ, thời gian, ưu tiên tài nguyên và kích thước tải về.
/assets/images/network-lane-9695e10ca2a77868bf887da7a3e4aa83.png

Timeline mạng rất hữu ích để đối chiếu các request với cập nhật giao diện hoặc hoạt động CPU. Ví dụ ảnh chụp trang Stripe ngay trước khi font kết thúc tải:
/assets/images/stripe-before-font-fc1ee28719fbd1757393e666d78a16d8.png

Ngay sau khi file font tải xong, UI rerender với font mới — bạn có thể thấy khác biệt bằng cách so sánh trước-sau và kiểm tra request nào đã giữ việc cập nhật giao diện.
/assets/images/stripe-after-font-4a2842fa18cbd71c5b1d05b05c91ef81.png

Flame chart và mã nguồn​

Phần main-thread CPU có một flame chart đảo ngược thể hiện sự phân bổ các tác vụ CPU theo hàm. Chọn một hàm JavaScript trong flame chart sẽ hiển thị thông tin chi tiết về lần gọi hàm đó, bao gồm vị trí nguồn.
/assets/images/stripe-flamechart-6f4675d710521fbbbcfde75ae0a40bed.png

Nhấp vào vị trí nguồn sẽ chuyển bạn đến mã nguồn trong tab Sources; dùng nút Prettify để làm mã dễ đọc hơn.
/assets/images/source-code-4a7e77ae718744c8e88666d395976243.png

Forced reflow (tái tính toán bố cục bắt buộc)​

Thông thường trình duyệt chạy JavaScript xong rồi mới cập nhật giao diện. Forced reflow xảy ra khi JS truy cập các thuộc tính layout của phần tử trong khi vẫn còn các thay đổi giao diện chờ tính toán — trình duyệt buộc phải tính toán lại layout đồng bộ ngay lập tức, có thể gây chậm.
/assets/images/style-recalculation-3d84eeb19b5652bd1e0f9afe74c183bb.png

Profiler cung cấp dữ liệu chi tiết để giúp bạn hiểu và gỡ lỗi các synchronous layouts; task style recalculation sẽ chỉ ra vị trí trong mã gây ra vấn đề.
/assets/images/layout-invalidation-fdea1dbf5b8a9b5623fd348cd5b813e1.png

Tổng hợp hoạt động CPU và các chế độ xem khác​

Nếu không chọn task cụ thể, bảng chi tiết dưới cùng của tab Performance sẽ hiển thị tổng quan phân chia hoạt động CPU thành các loại chính, giúp bạn nắm nhanh nguồn tiêu tốn thời gian.
/assets/images/cpu-activity-overview-b593f7cdf467a980c2c5008adb19667a.png

Bạn có thể chọn các luồng khác nhau (threads) bằng chuột hoặc phím mũi tên; ví dụ có thể xem breakdown cho một web worker.
/assets/images/web-worker-breakdown-53a8794f4681dfcdab2f013285cea1a4.png

Chế độ Bottom-Up cho thấy phân tích chi tiết theo các hàm cấp thấp nhất, thường lộ ra các hàm native như getBBox hoặc setAttribute — mở rộng chúng để tìm phần mã bạn kiểm soát và tối ưu.
/assets/images/bottom-up-2b888db65c26b8080fff51af59097e63.png

Tab Call Tree tương tự flame chart nhưng tổng hợp các lần gọi lặp lại, giúp xác định chính xác những đoạn mã chiếm nhiều thời gian nhất.

Kết luận: kết hợp filmstrip, mạng, flame chart và các chế độ xem Bottom-Up/Call Tree sẽ giúp bạn lần ra nguyên nhân gây chậm và lập kế hoạch tối ưu hoá hiệu năng trang một cách hiệu quả.

Nguồn: https://www.debugbear.com/blog/devtools-performance