Mỗi lần Google đánh giá một trang để xếp hạng, nó không chỉ nhìn nội dung mà còn nhìn cảm giác của người dùng khi mở trang đó: trang hiện ra nhanh hay chậm, bấm nút có phản hồi liền hay khựng, và bố cục có nhảy lung tung làm bấm nhầm hay không. Ba câu hỏi này được mã hoá thành ba con số đo được. Đó là lý do bài viết này tồn tại: giúp bạn đọc được ba con số đó và biết khi nào trang của bạn thật sự đạt.
Ba chỉ số trong bộ Core Web Vitals 2026
Bộ chỉ số hiện tại gồm đúng ba thành phần, mỗi cái đo một mặt khác nhau của trải nghiệm:
- LCP (Largest Contentful Paint — thời điểm phần tử lớn nhất hiện ra): đo tốc độ tải. Nó đánh dấu lúc khối nội dung lớn nhất trong khung nhìn (thường là ảnh bìa hoặc tiêu đề lớn) vẽ xong, tức lúc người dùng cảm thấy “trang đã lên”.
- INP (Interaction to Next Paint — độ trễ tới khung hình kế tiếp): đo độ phản hồi. Mỗi lần người dùng bấm, gõ, chạm, trình duyệt mất bao lâu để vẽ ra phản hồi thị giác — INP lấy con số tệ nhất trong số đó làm đại diện.
- CLS (Cumulative Layout Shift — tổng độ dịch chuyển bố cục): đo độ ổn định. Nó cộng dồn mức nội dung bị xê dịch ngoài ý muốn trong lúc tải, ví dụ ảnh chưa khai báo kích thước đẩy đoạn văn xuống đúng lúc bạn định bấm.
Một điểm cần chốt cho năm 2026: INP đã chính thức thay FID (First Input Delay — độ trễ tương tác đầu tiên) từ ngày 12/3/2024. FID chỉ đo lần tương tác đầu và rất dễ “qua bài” vì nó bỏ qua mọi lần bấm sau đó. INP đo mọi tương tác trong suốt phiên, nên bắt được các tác vụ nặng làm khựng ô tìm kiếm, bộ lọc hay giỏ hàng — những thứ người dùng cảm nhận thật. Nếu tài liệu nào còn nhắc FID như chỉ số chính, tài liệu đó đã lỗi thời.
Ngưỡng “Good” và cách Google chấm đạt hay không
Mỗi chỉ số có ba mức: Good (tốt), Needs Improvement (cần cải thiện) và Poor (kém). Mục tiêu là cả ba cùng nằm trong vùng Good. Bảng dưới là ngưỡng chính thức theo web.dev:
| Chỉ số | Đo cái gì | Good | Cần cải thiện | Kém |
|---|---|---|---|---|
| LCP | Tốc độ tải | ≤ 2,5 giây | 2,5 – 4,0 giây | > 4,0 giây |
| INP | Độ phản hồi | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS | Độ ổn định | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Chìa khoá nằm ở chữ p75 (phân vị thứ 75). Google không lấy lần tải nhanh nhất hay trung bình, mà lấy con số ở mốc 75% lượt tải. Nói cách khác, 75% số lượt mở trang phải đạt ngưỡng Good thì trang mới được tính là đạt chỉ số đó. Cách chấm này cố tình khắt khe với 25% người dùng yếu thế nhất — máy cũ, mạng chậm, ở xa máy chủ — chứ không để bạn lấy bình quân che lấp nhóm trải nghiệm tệ.
Field data và lab data — vì sao điểm đo lại lệch nhau
Đây là chỗ khiến nhiều người bối rối: Lighthouse báo 100 điểm mà trang vẫn trượt Core Web Vitals. Lý do là có hai loại dữ liệu hoàn toàn khác nhau.
- Field data (dữ liệu thực địa): thu từ chính người dùng thật của bạn, đủ loại máy, mạng, vị trí, hành vi. Google gom vào tập CrUX (Chrome User Experience Report — báo cáo trải nghiệm người dùng Chrome) và chỉ dùng dữ liệu này để xếp hạng. Tìm hiểu thêm trong bài dữ liệu CrUX của Google là gì.
- Lab data (dữ liệu phòng thí nghiệm): chạy một lần trong môi trường mô phỏng cố định, thường là một thiết bị di động bị bóp CPU và mạng. Lighthouse và PageSpeed Insights cho điểm này. Nó tuyệt vời để gỡ lỗi, nhưng không đại diện cho trải nghiệm 75% người dùng của bạn.
Vì vậy luôn ghi nhớ nguyên tắc: dùng field data để biết mình đạt hay chưa, dùng lab data để biết phải sửa chỗ nào. Một hệ quả thực tế: INP đo được trong field nhưng lab thì không (vì lab không có người bấm thật), nên ở lab người ta dùng TBT (Total Blocking Time) làm chỉ số thay thế gần đúng cho khả năng phản hồi.
Vì sao Core Web Vitals quan trọng cho cả SEO lẫn người dùng
Core Web Vitals là một phần trong tín hiệu “trải nghiệm trang” mà Google công khai dùng cho xếp hạng. Nó không phải yếu tố mạnh nhất — nội dung phù hợp vẫn quan trọng hơn — nhưng khi hai trang nội dung tương đương, trải nghiệm tốt hơn là lợi thế. Quan trọng hơn cả SEO: ba chỉ số này phản ánh đúng cảm giác bực bội khi trang chậm, khi bấm nút không ăn, khi vừa định bấm thì nội dung nhảy. Sửa chúng là sửa cho người dùng thật, còn thứ hạng là phần thưởng đi kèm.
Web22 vận hành chính web22.dev trên LiteSpeed (web server) kèm LiteSpeed Cache và Cloudflare (CDN — mạng phân phối nội dung), tự localize Google Font và đặt font-display: swap. Từ thực tế đo bằng Lighthouse và PageSpeed, bài học rõ nhất là: đừng tin một con số lab đẹp, hãy nhìn field data sau khi người dùng thật đã dùng vài tuần.
Đi sâu từng chỉ số và công cụ đo
Bài này là bản đồ tổng quan. Mỗi nhánh đều có bài riêng đào sâu:
- LCP — cách đo và tối ưu thời điểm phần tử lớn nhất hiện ra
- INP — chỉ số phản hồi đã thay FID
- CLS — xử lý dịch chuyển bố cục
- TTFB — đào sâu kỹ thuật giảm thời gian phản hồi máy chủ (định nghĩa cơ bản xem TTFB là gì)
- FCP và LCP khác nhau ra sao
- Đọc báo cáo PageSpeed Insights đúng cách
Lộ trình tối ưu theo thứ tự đáng làm
Khi bắt tay vào, hãy đi theo thứ tự đòn bẩy lớn trước, đừng nhảy lung tung:
- Đo bằng field data trước: mở PageSpeed Insights hoặc Search Console, xác định chỉ số nào đang trượt và trên thiết bị nào (mobile thường tệ hơn).
- Cache trang và rút ngắn TTFB: máy chủ trả HTML nhanh là nền móng cho LCP tốt.
- Sửa LCP: tối ưu ảnh bìa, preload tài nguyên quan trọng, localize font.
- Sửa INP: chia nhỏ tác vụ JavaScript dài, hoãn script không cần thiết.
- Sửa CLS: khai báo kích thước cho mọi ảnh, video, quảng cáo và chừa chỗ trước.
- Đợi và đo lại field data: CrUX cập nhật theo cửa sổ 28 ngày, nên kết quả thật cần thời gian mới phản ánh.
Câu hỏi thường gặp
Đạt 100 điểm Lighthouse là đạt Core Web Vitals chưa?
Chưa chắc. Lighthouse là lab data đo một lần mô phỏng, còn Google chấm đạt dựa trên field data thật từ CrUX ở phân vị 75. Điểm lab đẹp chỉ là tín hiệu tốt, không phải bằng chứng đạt.
Bao lâu thì thay đổi của tôi hiện trên Core Web Vitals?
CrUX dùng cửa sổ trượt 28 ngày, nên sau khi tối ưu bạn thường cần vài tuần để field data phản ánh đầy đủ. Lab data thì thấy ngay nhưng không dùng để xếp hạng.
Trang phải đạt cả ba chỉ số mới được tính đạt?
Đúng. Để một URL được đánh giá đạt Core Web Vitals, cả LCP, INP và CLS đều phải nằm trong ngưỡng Good ở p75. Trượt một chỉ số là trượt cả cụm.
Nếu trang của bạn đang trượt và bạn muốn tìm đúng đòn bẩy thay vì sửa mò, dịch vụ tối ưu hiệu năng web của Web22 có thể giúp đo và xử lý theo thứ tự ưu tiên.