Technical SEO

Web Performance Metrics (Core Web Vitals)

Bộ chỉ số đo lường trải nghiệm người dùng trên web gồm LCP, FID/INP và CLS, ảnh hưởng trực tiếp đến xếp hạng SEO.

5 lượt xem Cập nhật: 31/05/2026

Web Performance Metrics (Core Web Vitals) là gì?

Web Performance Metrics (Core Web Vitals) là bộ ba chỉ số đo lường trải nghiệm người dùng trên trang web, do Google đề xuất và tích hợp vào thuật toán xếp hạng tìm kiếm từ tháng 6/2021. Ba chỉ số này là: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) và Cumulative Layout Shift (CLS). Từ đầu năm 2024, Google chính thức thay thế First Input Delay (FID) bằng INP — vì FID không phản ánh đầy đủ hiệu suất tương tác trên toàn phiên người dùng.

Tại sao quan trọng trong SEO?

Core Web Vitals là một trong những yếu tố xếp hạng trực tiếp của Google trong nhóm trải nghiệm người dùng (User Experience). Trang web đạt chuẩn Core Web Vitals có khả năng cao hơn được ưu tiên hiển thị ở vị trí tốt trên kết quả tìm kiếm — đặc biệt trên thiết bị di động. Đây cũng là yêu cầu bắt buộc để xuất hiện trong các tính năng như Top Stories (trên Google News) hoặc Rich Results nhất định.

Ngoài ra, các chỉ số này liên quan mật thiết đến hành vi người dùng thực tế: trang tải chậm (LCP cao) làm tăng tỷ lệ thoát; layout nhảy lung tung (CLS cao) gây khó chịu khi đọc; phản ứng chậm sau chạm (INP cao) khiến người dùng bỏ cuộc. Tất cả đều ảnh hưởng gián tiếp đến thứ hạng qua dữ liệu hành vi (bounce rate, dwell time, conversion).

Cách hoạt động

Mỗi chỉ số đo một khía cạnh riêng của trải nghiệm:

  • LCP đo thời gian để phần tử lớn nhất trong vùng nhìn (viewport) được hiển thị đầy đủ — thường là ảnh, video hoặc khối văn bản lớn. Được tính từ lúc bắt đầu tải trang đến khi phần tử đó render xong.
  • INP đo độ trễ giữa lần tương tác đầu tiên (click, chạm, nhập liệu…) và thời điểm trình duyệt phản hồi bằng cách vẽ lại giao diện (paint). Giá trị INP lấy từ phân vị 75 của tất cả tương tác trong phiên — tức là 75% lần tương tác có độ trễ ≤ giá trị báo cáo.
  • CLS đo mức độ dịch chuyển bất ngờ của các phần tử trong quá trình tải — ví dụ: quảng cáo nhảy xuống làm lệch nút bấm, ảnh chưa đặt kích thước nên co giãn sau khi load. Tính bằng tổng các layout shift scores trong suốt vòng đời trang.

Hướng dẫn thực hiện

  1. Đo lường hiện trạng: Dùng công cụ miễn phí như PageSpeed Insights, Web.dev Measure hoặc Chrome DevTools (tab Performance & Rendering). Lưu ý: dữ liệu trường hợp (field data) từ Chrome User Experience Report (CrUX) mới phản ánh trải nghiệm thực tế — khác với lab data (thử nghiệm trong môi trường kiểm soát).
  2. Phân tích nguyên nhân: Với LCP → kiểm tra ảnh/video chưa tối ưu, render-blocking resources, server response chậm. Với INP → tìm JavaScript nặng, xử lý đồng bộ dài, thiếu code-splitting. Với CLS → xác định phần tử không có width/height, font tải chậm gây FOIT/FOUT, quảng cáo hoặc widget động chèn vào DOM muộn.
  3. Áp dụng cải tiến:
    • LCP: Nén ảnh (WebP/AVIF), dùng loading="eager" cho ảnh trên cùng, triển khai preconnect với CDN, giảm thời gian phản hồi máy chủ (TTFB < 200ms).
    • INP: Chuyển xử lý nặng sang Web Worker, phân mảnh JavaScript (code splitting), loại bỏ long tasks (>50ms), dùng debounce/throttle cho sự kiện scroll/input.
    • CLS: Đặt kích thước cố định cho ảnh/video (width/height hoặc aspect ratio box), tránh chèn nội dung động phía trên DOM đã hiển thị, preload font quan trọng, dùng font-display: optional.
  4. Giám sát liên tục: Thiết lập cảnh báo qua Google Search Console (báo cáo Core Web Vitals), tích hợp Lighthouse CI vào quy trình phát triển, theo dõi CrUX Dashboard hàng tháng.

Lỗi thường gặp

Chỉ số Lỗi phổ biến Cách khắc phục
LCP Ảnh nền (background-image) không được Lighthouse nhận diện là LCP candidate Dùng thẻ <img> thay vì CSS background, hoặc thêm fetchpriority="high" và decoding="async"
INP Giá trị INP cao dù FID thấp (do FID chỉ đo lần đầu, INP đo toàn phiên) Phân tích bằng Chrome DevTools > Performance tab, tìm main-thread tasks dài >50ms; ưu tiên tối ưu các sự kiện click/tap trên nút CTA, form.
CLS CLS tăng mạnh sau khi người dùng tương tác (ví dụ: mở menu dropdown) Đảm bảo dropdown có chiều cao cố định hoặc dùng transition CSS thay vì thay đổi height auto; tránh thay đổi layout trong event handler.

Ví dụ thực tế

Một trang tin điện tử tại Việt Nam từng có LCP = 4.8s (trên mobile), CLS = 0.32 và INP = 120ms — tất cả đều ngoài ngưỡng đạt chuẩn. Sau khi:

  • Thay toàn bộ ảnh bài viết sang WebP + lazy-load thông minh (không áp dụng cho ảnh đầu bài),
  • Loại bỏ 2 thư viện JavaScript không cần thiết (tổng dung lượng giảm 1.2MB),
  • Thêm aspect-ratio cho thẻ <figure> và đặt font-display: swap cho font chữ,
… kết quả đo lại sau 4 tuần: LCP giảm còn 1.9s, CLS về 0.05, INP xuống 32ms. Trong Google Search Console, tỷ lệ trang đạt “tốt” tăng từ 31% lên 89%. Lưu lượng tìm kiếm hữu cơ tăng 22% trong 2 tháng tiếp theo — không kèm chiến dịch content mới.

Câu hỏi thường gặp

Core Web Vitals có áp dụng cho trang AMP không?

AMP không còn là yêu cầu bắt buộc để xuất hiện trong Top Stories kể từ tháng 6/2021. Các trang AMP vẫn phải đạt chuẩn Core Web Vitals như trang HTML bình thường — vì Google đánh giá trải nghiệm người dùng, không phải công nghệ nền tảng.

Tôi đang dùng WordPress – có plugin nào đảm bảo đạt chuẩn không?

Không có plugin nào “đảm bảo” đạt chuẩn — vì kết quả phụ thuộc vào chủ đề, hosting, cấu hình CDN và nội dung thực tế. Plugin như WP Rocket, LiteSpeed Cache hay Autoptimize hỗ trợ tốt nhưng cần tinh chỉnh thủ công (ví dụ: bật preloading font, tắt JS không cần thiết trên trang chủ). Kiểm tra luôn bằng PageSpeed Insights sau mỗi thay đổi.

Core Web Vitals có thay đổi không?

Có thể thay đổi. Google đã thay FID bằng INP năm 2024 và từng cập nhật ngưỡng chuẩn (ví dụ: CLS từ ≤0.1 thành ≤0.1 — vẫn giữ nguyên nhưng cách tính chi tiết hơn). Các ngưỡng hiện hành (cập nhật tháng 4/2024) là: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1. Bạn nên theo dõi web.dev/vitals để cập nhật chính thức.