Cách đọc báo cáo Core Web Vitals trong Search Console bắt đầu từ một nguyên tắc: báo cáo chia các nhóm URL theo trạng thái Kém, Cần cải thiện hoặc Tốt, và nhãn của mỗi nhóm lấy theo chỉ số chậm nhất. Đọc đúng nhãn giúp biết nhóm trang nào cần sửa trước. Phần dưới đi qua từng lớp của báo cáo và cách xử lý khi báo cáo trống.
Cách đọc báo cáo Core Web Vitals trong Search Console: báo cáo này cho biết điều gì
Theo trang trợ giúp Search Console của Google, báo cáo Core Web Vitals dùng dữ liệu người dùng thực tế, thường gọi là dữ liệu thực tế tại trang. Dữ liệu được chia theo thiết bị di động hoặc máy tính.
Core Web Vitals là nhóm chỉ số đo mức thân thiện với người dùng dựa trên thời gian tải, độ ổn định hình ảnh và khả năng tương tác. Báo cáo phân nhóm theo trạng thái, loại chỉ số (CLS, INP, LCP) và nhóm URL.
Báo cáo không dùng để kiểm tra một trang riêng lẻ. Nó nhóm các trang có vấn đề tương tự nhau, và chỉ là một mẫu trang chứ không phải danh sách đầy đủ mọi URL đã lập chỉ mục. Chỉ URL đã được lập chỉ mục mới xuất hiện.
Ngưỡng LCP, INP, CLS và ý nghĩa của từng nhãn
Ba chỉ số có ngưỡng riêng, và việc nắm ngưỡng lcp inp cls là điều kiện để hiểu vì sao một nhóm bị gắn nhãn xấu. LCP đo thời gian hiển thị phần nội dung lớn nhất, INP đo độ phản hồi khi tương tác, CLS đo mức xô lệch bố cục.
- LCP: Tốt từ 2,5 giây trở xuống, Cần cải thiện từ 2,6 đến 4 giây, Kém trên 4 giây.
- CLS: Tốt từ 0,1 trở xuống, Cần cải thiện từ 0,1 đến 0,25, Kém trên 0,25.
- INP: Google Search Central khuyến nghị giữ dưới 200 mili giây.
INP thay thế FID từ ngày 12 tháng 3 năm 2024 và đánh giá thời gian phản hồi trong suốt quá trình tương tác, không chỉ lần đầu. Với ba nhãn trạng thái kém cần cải thiện tốt, mỗi nhóm URL nhận nhãn của chỉ số tệ nhất. Ví dụ, nhóm có CLS kém nhưng INP tốt vẫn mang nhãn Kém.
Đọc trang tổng quan, biểu đồ và trang chi tiết theo thứ tự
Nên đọc từ trên xuống: chọn thiết bị, nhìn biểu đồ, mở bảng vấn đề, rồi vào từng nhóm URL. Cách này tránh nhầm giữa dữ liệu di động và máy tính, vì hai báo cáo tách riêng.
- Mở báo cáo Core Web Vitals trong Search Console và chọn Di động hoặc Máy tính. Kết quả cần thấy: biểu đồ đếm URL theo ba trạng thái.
- Xem biểu đồ để nhận ra xu hướng. Mỗi URL chỉ được đếm một lần, theo vấn đề chậm nhất của nó.
- Mở bảng vấn đề, ví dụ “CLS: trên 0,25”, để biết chỉ số nào kéo nhãn xuống.
- Vào trang chi tiết của vấn đề để xem các nhóm URL và URL mẫu trong nhóm.
Dữ liệu gán cho URL thực tế chứ không phải URL chính tắc, và tổng hợp từ mọi vị trí. Nếu trạng thái thay đổi mạnh dù không sửa gì, có thể các trang ở ngưỡng biên đã bị đẩy sang nhãn khác do lưu lượng hoặc tốc độ dịch vụ thay đổi. Số liệu PageSpeed Insights của một URL cũng có thể khác kết quả nhóm trong báo cáo.
Khi báo cáo trống: Core Web Vitals không có dữ liệu
Màn hình core web vitals không có dữ liệu thường không phải lỗi của website. Theo Google, màn hình này xuất hiện khi tài sản mới được thêm hoặc chưa đủ dữ liệu CrUX, và có thể cần vài ngày sau khi tạo tài sản.
URL không có đủ dữ liệu tối thiểu cho cả LCP và CLS sẽ bị loại khỏi báo cáo. Vì vậy trang ít lưu lượng thường không xuất hiện.
Trường hợp khác là lỗi nguồn dữ liệu. Một bài đăng ghi nhận báo cáo CWV trên di động bị sụt giảm từ khoảng ngày 10 tháng 7 rồi dừng hẳn. John Mueller xác nhận phía Search Console không thay đổi gì, vấn đề nằm ở dữ liệu CrUX, và Barry Pollard thừa nhận có gián đoạn đang được Chrome khắc phục. Khi báo cáo trống do lỗi nguồn, không nên kết luận site có vấn đề mà nên chờ cập nhật, đồng thời đối chiếu với PageSpeed Insights.
Từ báo cáo đến hành động: ưu tiên và theo dõi sau khi sửa
Nên sửa mọi nhóm URL Kém trước, rồi ưu tiên theo số URL bị ảnh hưởng hoặc theo URL quan trọng. Nhóm Cần cải thiện xử lý sau.
Về cách sửa core web vitals, nguồn tham khảo của Semrush nêu các hướng chính. Với LCP: nén ảnh, dùng định dạng như WebP, bật bộ nhớ đệm trang và nâng cấp hosting khi cần. Với CLS: thêm thuộc tính width và height cho ảnh và video, hạn chế web font và dùng khung tỉ lệ khung hình. Bài hướng dẫn của Semrush về Core Web Vitals mô tả chi tiết hơn các bước này.
Sau khi sửa, nhấn Start Tracking trên trang chi tiết vấn đề để Search Console xác thực. Quá trình theo dõi kéo dài 28 ngày. Google cũng khuyến nghị tối ưu theo chu trình đo lường, gỡ lỗi, cải thiện, theo tài liệu của Google Search Central.
Sai lầm thường gặp
Sai lầm đầu tiên là coi nhóm URL như điểm số của từng trang. Báo cáo chỉ là mẫu theo nhóm, nên cần PageSpeed Insights để xem một URL cụ thể, kèm lưu ý kết quả có thể lệch.
Sai lầm thứ hai là chỉ nhìn chỉ số tốt. Một nhóm có INP tốt vẫn bị Kém nếu CLS kém.
Sai lầm thứ ba là kết luận website hỏng khi báo cáo trống hoặc tụt đột ngột, trong khi nguyên nhân có thể là tài sản mới, thiếu dữ liệu hoặc gián đoạn CrUX. Cuối cùng, nhiều người sửa xong rồi bỏ qua bước Start Tracking nên không biết bản sửa có được xác thực hay không.
Kết luận: đọc theo nhóm, sửa theo thứ tự
Cách đọc báo cáo Core Web Vitals trong Search Console hiệu quả là chọn thiết bị, xác định chỉ số chậm nhất của từng nhóm, sửa nhóm Kém trước rồi theo dõi 28 ngày. Việc nên làm tiếp theo là mở bảng vấn đề của thiết bị di động và ghi lại ba nhóm URL lớn nhất. Nếu cần rà soát thêm tình trạng lập chỉ mục, xem cách xử lý Discovered currently not indexed trong Search Console. Nếu trang chậm do hosting, kiểm tra thêm cách tự động backup database trong hosting cPanel trước khi thay đổi cấu hình.
