Core Web Vitals ngoài thực địa: Tìm đúng điểm nghẽn mà người dùng thực sự cảm nhận
Một cách làm thực tế để kết nối các bài đo trong phòng thí nghiệm với Core Web Vitals của người dùng thực, ưu tiên các bản sửa và kiểm chứng mức cải thiện trên cả di động lẫn desktop.
Một lần chạy nhanh trong phòng thí nghiệm là manh mối, không phải phán quyết cuối cùng
Một trang có thể trông rất nhanh trong một bài kiểm tra được kiểm soát mà vẫn khiến khách truy cập cảm thấy chậm trên những chiếc điện thoại cũ, trong các mạng đang bận rộn, hoặc trên những tuyến đường xa tới máy chủ. Các bài đo trong phòng thí nghiệm giúp tái tạo một lượt tải trang và phơi bày request waterfall của nó. Dữ liệu thực địa cho thấy các lượt truy cập thực tế hành xử ra sao trên nhiều thiết bị và điều kiện khác nhau. Hãy dùng cả hai: dữ liệu thực địa chọn ra vấn đề, còn các lần chạy lặp lại trong phòng thí nghiệm giúp định vị và sửa nó.
Google đánh giá ba chỉ số Core Web Vitals ở phân vị thứ 75, với di động và desktop được xét riêng biệt. Các mục tiêu tốt hiện tại là LCP ở mức 2.5 giây trở xuống, INP ở mức 200 ms trở xuống và CLS ở mức 0.1 trở xuống. Giá trị trung bình có thể che giấu trải nghiệm chậm hơn của một nhóm người dùng không hề nhỏ, vì vậy hãy nhìn vào dữ liệu phân vị và phân đoạn theo thiết bị. Google’s threshold guidance giải thích phương pháp dùng phân vị này.
Bắt đầu từ chỉ số đang không đạt
LCP chỉ vào khâu tải. Hãy kiểm tra xem độ trễ đến từ trước khi có phản hồi HTML, từ CSS chặn hiển thị, hay từ việc phát hiện và tải xuống hình ảnh hoặc đoạn văn bản chính. So sánh TTFB giữa các vùng, rồi rà soát request waterfall. Nén và đặt đúng kích thước cho hình ảnh chính, làm cho nó có thể được phát hiện ngay trong HTML ban đầu, và chỉ preload khi nó thực sự là tài nguyên LCP.
INP chỉ vào tương tác. Một bài kiểm tra tải trang trong phòng thí nghiệm không thể đo đầy đủ INP, vì chỉ số này cần những tương tác thực của người dùng. Hãy dùng dữ liệu thực địa để xác định các tương tác chậm, rồi phân tích thao tác nhấp chuột hoặc gõ phím tương ứng trong công cụ dành cho nhà phát triển của trình duyệt. Các tác vụ JavaScript dài, việc hiển thị tốn kém và các script của bên thứ ba đều có thể làm chậm lần vẽ tiếp theo. Chia nhỏ công việc thành các tác vụ ngắn hơn và hoãn các script không thiết yếu là hai thử nghiệm đầu tiên đáng làm. web.dev’s measurement guide giải thích vì sao Total Blocking Time chỉ là một đại diện trong phòng thí nghiệm chứ không phải thứ thay thế được INP.
CLS chỉ vào sự xê dịch về mặt hình ảnh. Hãy kiểm tra cả lượt tải ban đầu lẫn các tương tác về sau trong dữ liệu thực địa. Đặt kích thước hoặc tỷ lệ khung hình rõ ràng cho hình ảnh và nội dung nhúng, chừa chỗ cho quảng cáo, và tránh chèn nội dung vào phía trên phần mà người dùng đang đọc. Việc đổi font cũng có thể làm văn bản bị xê dịch; hãy dùng một font dự phòng có thông số tương đương và kiểm tra trang thực tế khi hiển thị.
Biến một điểm số thành một thử nghiệm có kiểm soát
Hãy thay đổi từng nguyên nhân có khả năng xảy ra trong mỗi lần. Giữ cho tuyến đường, viewport, cấu hình thiết bị, trạng thái cache và vị trí đo được nhất quán, đồng thời chạy bài kiểm tra nhiều hơn một lần. So sánh request waterfall và chỉ số liên quan, chứ không chỉ một điểm số tổng hợp duy nhất. Sau đó kiểm tra lại dữ liệu thực địa khi thay đổi đã đến tay người dùng: một cải thiện trên một tuyến hay một thiết bị có thể không chuyển sang mọi trang.
Với việc giám sát thực địa, hãy nhóm các template trang tương tự nhau lại và rà soát phân đoạn thiết bị bị ảnh hưởng nặng nhất trước tiên. Một header dùng chung hoặc một trình quản lý đồng ý (consent manager) có thể ảnh hưởng tới rất nhiều URL, trong khi một hình ảnh sản phẩm có thể chỉ ảnh hưởng tới một template. Cách gom nhóm này giúp phân biệt được một vấn đề trên toàn trang với một vấn đề chỉ ở một trang cụ thể.
Ưu tiên trải nghiệm người dùng hơn một con số hoàn hảo
Core Web Vitals là những công cụ chẩn đoán hữu ích, không phải một định nghĩa trọn vẹn về một trang web tốt. Google cho biết kết quả tốt trong một báo cáo Core Web Vitals không bảo đảm vị trí tìm kiếm cao nhất; mức độ liên quan và trải nghiệm trang theo nghĩa rộng hơn vẫn có vai trò. Hãy sửa những điểm ma sát đo lường được mà người dùng thực sự gặp phải, và dùng các chỉ số để xác minh thay đổi đó thay vì theo đuổi một điểm số một cách tách biệt. Google’s page experience guidance cung cấp bối cảnh đó.