# Core Web Vitals là gì? LCP, INP, CLS: ngưỡng "tốt" và cách đo đúng cho website của bạn

URL: https://opcaios.org/blog/core-web-vitals-la-gi
Ngày: 2026-11-15
Cập nhật: 2026-10-25
Tác giả: Lê Quốc Nghĩa
Chuyên mục: Hướng dẫn

Core Web Vitals là gì? Core Web Vitals là bộ ba chỉ số do Google đề xuất để đo trải nghiệm trang web: Largest Contentful Paint (LCP) đo tốc độ tải, Interaction to Next Paint (INP) đo khả năng phản hồi khi tương tác, và Cumulative Layout Shift (CLS) đo độ ổn định hình ảnh. Theo web.dev (đọc ngày 25/10/2026), ngưỡng "tốt" ở phân vị 75 là LCP không quá 2,5 giây, INP không quá 200 mili giây và CLS không quá 0,1. Bài này giải thích Core Web Vitals là gì, ngưỡng, dữ liệu thực địa và dữ liệu phòng thí nghiệm, cách cải thiện và kinh nghiệm của OPCAIOS.

![Sơ đồ Core Web Vitals: LCP tải, INP tương tác, CLS ổn định; ngưỡng tốt 2,5 giây, 200 mili giây, 0,1; dữ liệu thực địa và phòng thí nghiệm](https://opcaios.org/images/blog/core-web-vitals-la-gi/so-do.webp)
*Ba chỉ số, ba ngưỡng, đo bằng người dùng thật ở phân vị 75. Sơ đồ: OPCAIOS.*

## Core Web Vitals là gì và gồm những chỉ số nào?

Core Web Vitals gồm ba chỉ số tập trung vào cảm nhận của người dùng thật: trang tải nhanh đến đâu (LCP), có phản hồi khi bấm hay gõ không (INP) và nội dung có nhảy lung tung không (CLS). Chúng thuộc bộ chỉ số về trải nghiệm trang của Google.

| Chỉ số | Đo gì | Ngưỡng "tốt" (phân vị 75) |
|---|---|---|
| LCP (Largest Contentful Paint) | Tốc độ tải phần nội dung lớn nhất | 2,5 giây hoặc ít hơn |
| INP (Interaction to Next Paint) | Độ phản hồi khi tương tác | 200 mili giây hoặc ít hơn |
| CLS (Cumulative Layout Shift) | Độ ổn định bố cục | 0,1 hoặc ít hơn |

Theo web.dev, INP thay thế First Input Delay (FID): được đưa từ thử nghiệm lên trạng thái chờ năm 2023 rồi thành chỉ số ổn định năm 2024. Bài được đăng 4/5/2020 và cập nhật lần cuối 31/10/2024; web.dev nói các chỉ số ổn định đổi không quá một lần mỗi năm.

## "Phân vị 75" nghĩa là gì?

Ngưỡng được áp ở phân vị 75 của các lượt tải trang: ít nhất 75% lượt truy cập phải đạt ngưỡng thì trang mới được coi là "tốt" ở chỉ số đó. Web.dev khuyên tách kết quả theo di động và máy tính.

Điều này khác với một lần đo lẻ: một lần tải nhanh trên máy mạnh không chứng minh trang tốt với người dùng thật, nhất là người dùng điện thoại cấu hình thấp và mạng chậm.

## Dữ liệu thực địa và dữ liệu phòng thí nghiệm

Dữ liệu thực địa đến từ người dùng thật; web.dev nói chỉ đo thực địa mới phản ánh đầy đủ bức tranh. Dữ liệu phòng thí nghiệm, từ công cụ như Lighthouse, hữu ích khi phát triển nhưng chạy trong điều kiện giả lập.

- **Thực địa:** phản ánh người dùng thật; cần đủ lượng truy cập mới có dữ liệu.
- **Phòng thí nghiệm:** chạy lặp lại được, tiện gỡ lỗi; không phản ánh đa dạng thiết bị.
- **INP và Lighthouse:** theo web.dev, Lighthouse không đo được INP vì không có thao tác người dùng, nên dùng Total Blocking Time (TBT) làm chỉ số thay thế.

Bạn có thể xem dữ liệu thực địa của site trong báo cáo trải nghiệm trang của [Google Search Console](/blog/google-search-console-la-gi) khi có đủ dữ liệu.

## Cách cải thiện từng chỉ số

Cải thiện theo nguyên nhân: LCP thường do ảnh hoặc khối chữ lớn tải chậm; INP do JavaScript chặn luồng chính; CLS do ảnh hoặc quảng cáo không có kích thước định sẵn. Các gợi ý dưới đây là thực hành chung của OPCAIOS, không trích từ bài web.dev tôi đọc.

| Chỉ số | Nguyên nhân thường gặp | Hướng xử lý |
|---|---|---|
| LCP | Ảnh lớn, máy chủ chậm, hiệu ứng mở đầu nặng | Nén ảnh (WebP), dùng [CDN](/blog/cdn-la-gi), ưu tiên tải ảnh chính, bỏ hiệu ứng thừa |
| INP | JavaScript nặng chạy lâu | Giảm mã chạy ở luồng chính, chia nhỏ tác vụ |
| CLS | Ảnh/khung không khai báo kích thước, phông chữ đổi | Đặt chiều rộng, chiều cao; dành chỗ cho nội dung chèn sau |

Khung dựng web cũng ảnh hưởng, xem [Next.js là gì](/blog/nextjs-la-gi) và [Cloudflare](/blog/cloudflare-la-gi).

## Kinh nghiệm của OPCAIOS

Chúng tôi đo bằng Lighthouse chạy cục bộ và thấy kết quả dao động khá mạnh, nên dùng trung vị của nhiều lần chạy thay vì một lần. Ghi chú nội bộ ngày 17/10/2026 ghi nhận LCP khoảng 3,9 đến 4,8 giây trên trang chủ do hiệu ứng mở đầu; đó là số đo cục bộ nhiễu, không phải dữ liệu thực địa, và có thể đã thay đổi sau các tối ưu về sau.

Điều chúng tôi rút ra: đừng kết luận từ một lần đo, và hiệu ứng trang trí mở đầu có thể kéo LCP đáng kể. Hạn chế: bài này không đưa điểm hiện tại của site vì chưa đo lại bằng dữ liệu thực địa ngày viết. Xem thêm [rà soát bảo mật website](/blog/ra-soat-bao-mat-website-mot-nguoi-15-viec-trong-mot-buoi-chieu) cho các việc kỹ thuật khác.

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

### INP thay thế chỉ số nào?
INP thay thế First Input Delay (FID), trở thành chỉ số ổn định của Core Web Vitals năm 2024 theo web.dev.

### Core Web Vitals có ảnh hưởng thứ hạng không?
Trang web.dev tôi đọc không bàn về mức ảnh hưởng đến xếp hạng nên tôi không khẳng định; hãy coi đây chủ yếu là chỉ số trải nghiệm người dùng.

### Vì sao điểm Lighthouse của tôi thay đổi mỗi lần?
Vì chạy phòng thí nghiệm bị nhiễu bởi máy và mạng. Chạy nhiều lần và lấy trung vị.

### Site nhỏ không có dữ liệu thực địa thì sao?
Có thể chưa đủ truy cập để Google báo cáo. Dùng Lighthouse để phát hiện vấn đề rồi chờ có dữ liệu.

### Tôi nên bắt đầu từ đâu?
Đo trang chính bằng Lighthouse nhiều lần, sửa phần nặng nhất (thường là ảnh), rồi theo dõi dữ liệu thực địa. Cần hỗ trợ, xem [dịch vụ đào tạo ứng dụng AI](/services/dao-tao-ung-dung-ai).

*Nguồn: web.dev, "Web Vitals" (đăng 4/5/2020, cập nhật 31/10/2024), đọc ngày 25/10/2026; chưa đọc tài liệu riêng từng chỉ số. Ghi chú LCP của OPCAIOS là đo cục bộ nhiễu ngày 17/10/2026. Bảng cách cải thiện là thực hành chung của OPCAIOS. Kinh nghiệm là của OPCAIOS.*