Muốn cải thiện Core Web Vitals, hãy dựa vào dữ liệu người dùng thật (CrUX) ở phân vị 75, không chỉ điểm Lighthouse. Mục tiêu là LCP ≤2,5 giây, INP ≤200 ms và CLS ≤0,1. Sửa ảnh LCP và kích thước ảnh trước, rồi chia nhỏ JavaScript nặng để INP xuống mức tốt.
Ba chỉ số Core Web Vitals và ngưỡng chính thức
Theo web.dev của Google, LCP đo tốc độ tải cảm nhận được, INP đo khả năng phản hồi và CLS đo độ ổn định hình ảnh. Nếu bạn đang tìm câu trả lời cho "inp là gì": đó là chỉ số cho biết trang phản hồi nhanh hay chậm khi người dùng bấm, chạm hoặc gõ.
Ngưỡng chính thức như sau:
- INP: tốt khi ≤200 ms, kém khi >500 ms.
- CLS: tốt khi ≤0,1, kém khi >0,25.
Cả ba đều được đánh giá ở phân vị 75. Một trang được xếp tốt ở một chỉ số khi ít nhất 75% lượt xem đạt ngưỡng tốt. Trang bị xếp kém khi ít nhất 25% lượt xem rơi vào ngưỡng kém.
Ví dụ trong tài liệu của Google: LCP ở phân vị 75 là 2 giây thì tốt, là 5 giây thì kém. Ngưỡng dùng chung cho mobile và desktop.
Lý do chọn phân vị 75, theo cùng nguồn: phần lớn lượt truy cập (3 trên 4) đạt mục tiêu, và giá trị ít bị kéo lệch bởi vài mẫu ngoại lai. Nguồn này cũng nhận xét nhiều site vẫn có lợi nếu tối ưu vượt cả ngưỡng tốt.
Dữ liệu người dùng thật khác điểm Lighthouse thế nào
Điểm Lighthouse là dữ liệu lab. Theo bài của Philip Walton trên web.dev, dữ liệu lab đo trong môi trường kiểm soát, với thiết bị và mạng định sẵn. Dữ liệu field lấy từ người dùng thật, thường qua CrUX.
Tổng quan về CrUX mô tả đây là bộ dữ liệu của chương trình Web Vitals, thu từ trình duyệt thật trên toàn cầu. Google Search dùng dữ liệu này để cung cấp thông tin cho yếu tố xếp hạng trải nghiệm trang. Các công cụ báo điểm field lấy phân phối của 28 ngày và dùng phân vị 75.
Hai loại số liệu có thể lệch nhau khá xa. Bài của web.dev nêu ví dụ một trang có LCP field là 1,8 giây trong khi lab cho 3,0 giây.
Nguyên nhân thường gặp:
- Phần tử LCP ngoài thực tế có thể khác lab, do kích thước màn hình, trạng thái đăng nhập hoặc A/B test.
- Lab thường tải với cache lạnh.
- TBT trong lab không tính các tương tác thật.
- Lab chỉ tính CLS ở phần trên màn hình đầu và lúc tải, còn field tính cả dịch chuyển khi người dùng cuộn.
Kết luận của nguồn: khi có cả hai loại dữ liệu, hãy dùng field để quyết định việc nào làm trước. Lab vẫn hữu ích để tìm cơ hội cho mạng chậm hoặc máy yếu.
Có một giới hạn cần biết: không phải origin hay trang nào cũng có mặt trong CrUX. Điều kiện chính là công khai và có đủ lượng truy cập. Với site ít truy cập, bạn sẽ phải dựa nhiều hơn vào lab.
Thứ tự sửa: LCP, CLS rồi INP
Nhưng nếu dữ liệu field cho thấy INP mới là chỉ số trượt, hãy làm INP trước. Bài các cách cải thiện Core Web Vitals hiệu quả cũng xếp INP lên đầu vì ít site đạt mức tốt, nên còn nhiều chỗ để cải thiện.
Cải thiện LCP
Theo cùng bài, 40% site trong CrUX chưa đạt ngưỡng LCP khuyến nghị. Bài trích Web Almanac 2024: 73% trang mobile có ảnh là phần tử LCP, nên bắt đầu từ ảnh là hợp lý.
- Để ảnh LCP nằm ngay trong HTML (
<img src>hoặc<link rel="preload">). Dùngdata-srcsẽ làm ảnh tải chậm hơn. - Thêm
fetchpriority="high"cho ảnh LCP và bỏloading="lazy"khỏi ảnh đó. - Dùng CDN để giảm TTFB.
- Dùng bfcache và Speculation Rules để điều hướng gần như tức thì.
Giảm CLS
Khoảng một phần tư site chưa đạt ngưỡng CLS. Theo bài, 66% trang có ít nhất một ảnh không khai báo kích thước.
- Đặt
widthvàheightcho ảnh. - Dùng
aspect-ratiohoặcmin-heightcho nội dung nạp động như quảng cáo và embed. - Giữ trang đủ điều kiện dùng bfcache.
- Với animation, ưu tiên
transformthay vìtop,lefthaymargin.
Cải thiện INP
Bài khuyến nghị ba hướng: chia nhỏ các tác vụ dài (trên 50 ms), bỏ JavaScript không cần thiết, và tránh cập nhật render lớn. Với chủ website, việc đầu tiên thường là rà lại plugin, script bên thứ ba và đoạn mã chạy mỗi khi người dùng bấm.
Những điểm dễ làm sai khi tối ưu
- Chỉ nhìn điểm Lighthouse. Điểm lab đẹp chưa chắc phản ánh trải nghiệm thật, vì lab và field đo khác nhau như phần trên đã nêu.
- Coi chênh lệch lab và field là lỗi công cụ. Đó là hiện tượng bình thường, hãy ưu tiên theo field khi có dữ liệu.
- Lazy-load ảnh LCP. Thuộc tính
loading="lazy"trên ảnh LCP làm LCP chậm hơn. - Đo từng trang đơn lẻ rồi kết luận cho cả site. Chỉ số được tính theo phân vị 75 trên nhiều lượt xem, nên một lần đo không đại diện được.
Theo dõi kết quả sau khi sửa
Sau mỗi thay đổi, hãy chờ dữ liệu field cập nhật vì CrUX lấy phân phối trong 28 ngày. Lab giúp bạn kiểm tra nhanh một bản sửa, còn field cho biết người dùng thật có cảm nhận được hay không.
Công cụ TỐI ƯU SEO kết nối PageSpeed và CrUX; kiểm tra cơ bản miễn phí, kiểm tra chuyên sâu trừ credit. Nếu muốn xem thử, bạn có thể đăng ký dùng thử miễn phí.
Câu hỏi thường gặp
INP là gì và ngưỡng nào là tốt?
INP đo khả năng phản hồi của trang. Theo web.dev, INP tốt khi ≤200 ms ở phân vị 75 và kém khi >500 ms.
Vì sao điểm Lighthouse và dữ liệu CrUX khác nhau?
Lighthouse là dữ liệu lab đo trong môi trường định sẵn, còn CrUX là dữ liệu field từ người dùng Chrome thật trong 28 ngày. Phần tử LCP, cache và cách tính CLS cũng khác nhau giữa hai loại.
Nên dùng lab hay field để ưu tiên việc cần sửa?
Khi có cả hai, web.dev khuyên dùng field để ưu tiên công việc. Lab vẫn hữu ích để tìm cơ hội cho mạng chậm hoặc máy yếu.
Nguồn tham khảo
- How the Core Web Vitals metrics thresholds were defined, web.dev (Google), 21/05/2020, cập nhật 07/05/2025. Đọc ngày 22/10/2026.
- Why lab and field data can be different (and what to do about it), web.dev (Google), 18/07/2022. Đọc ngày 22/10/2026.
- The most effective ways to improve Core Web Vitals, web.dev (Google), 31/10/2024. Đọc ngày 22/10/2026.
- Overview of CrUX, Chrome for Developers, 08/02/2024. Đọc ngày 22/10/2026.
Bài do TỐI ƯU SEO biên soạn từ các nguồn ghi ở cuối bài, đã qua kiểm tra trước khi đăng.
Thấy chỗ chưa đúng? Báo lỗi bài này.