Core Web Vitals gồm ba chỉ số: LCP đo tốc độ hiện nội dung chính, INP đo độ trễ khi bấm, CLS đo mức nhảy bố cục. Để đạt mức tốt, LCP không quá 2,5 giây, INP không quá 200 ms và CLS không quá 0,1, đo trên 75% lượt truy cập thật. Muốn core web vitals cải thiện đúng hướng, hãy đọc dữ liệu thật trước, tìm phần tử gây chậm, rồi sửa từng nguyên nhân một. Bài này kèm số đo Lighthouse trên chính trang chủ netsolutions.vn.
- Core Web Vitals là gì và đo bằng gì
- Cách đọc điểm Lighthouse
- Cải thiện LCP
- Cải thiện INP
- Cải thiện CLS
- Số đo thật: trang chủ netsolutions.vn
- Quy trình của chúng tôi
- Khi nào chưa cần sửa
- Câu hỏi thường gặp
Core Web Vitals là gì và đo bằng công cụ nào
Core Web Vitals là bộ ba chỉ số Google dùng để mô tả trải nghiệm tải và dùng trang. Mỗi chỉ số có hai mốc: tốt và kém, tính ở phân vị 75 của lượt truy cập thật. Nghĩa là 75% lượt truy cập phải đạt mốc.
| Chỉ số | Đo cái gì | Mức tốt | Mức kém |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Lúc phần nội dung lớn nhất hiện ra: ảnh, khối chữ, video | ≤ 2,5 giây | > 4 giây |
| INP (Interaction to Next Paint) | Độ trễ từ lúc bấm, chạm, gõ phím đến lúc trang vẽ phản hồi | ≤ 200 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Mức nhảy bố cục ngoài ý muốn khi trang tải | ≤ 0,1 | > 0,25 |
Nguồn: web.dev, bài Defining the Core Web Vitals metrics thresholds, ghi nhận 10/10/2026.
INP thay FID làm chỉ số phản hồi chính thức từ ngày 12/03/2024 (nguồn: web.dev). Bài hướng dẫn nào còn dạy tối ưu FID là bài cũ.
Có hai loại dữ liệu và chúng không thay nhau được. Dữ liệu thật (field) lấy từ người dùng Chrome, gộp trong 28 ngày. Dữ liệu giả lập (lab) là một lần chạy trên máy đo, dùng để tìm nguyên nhân.
| Công cụ | Loại dữ liệu | Dùng để làm gì | Lưu ý |
|---|---|---|---|
| Google Search Console | Thật, 28 ngày | Biết nhóm URL nào đạt hoặc không đạt | Chỉ hiện khi site đủ lượt truy cập |
| CrUX (báo cáo trải nghiệm người dùng Chrome) | Thật, 28 ngày | Xem phân bố chỉ số theo trang hoặc theo tên miền | Là nguồn của báo cáo Search Console |
| PageSpeed Insights | Thật (nếu đủ mẫu) và giả lập | Một trang xem được cả hai loại, kèm gợi ý sửa | Điểm tổng là điểm giả lập |
| Lighthouse, DevTools | Giả lập | Tìm phần tử và đoạn mã gây chậm | Không đo INP, thay bằng TBT |
Nguồn: tài liệu của Google Search Central và web.dev, ghi nhận 10/10/2026. Lighthouse không đo INP vì cần thao tác của người dùng thật.
Google gọi đây là tín hiệu trải nghiệm trang, nhưng nội dung liên quan vẫn được ưu tiên khi xếp hạng. Một trang chậm vẫn có thể lên top nếu nó trả lời đúng câu hỏi. Một trang nhanh mà nội dung nghèo thì không được kéo lên. Vì vậy chúng tôi coi tốc độ là điều kiện cần, không phải đòn bẩy chính. Phần nguyên nhân chậm nói chung nằm ở bài tại sao website chậm.
Cách đọc điểm Lighthouse để biết sửa gì trước
Điểm Performance của Lighthouse là tổng có trọng số của năm chỉ số. Ba chỉ số TBT, LCP và CLS chiếm 80% tổng điểm. Vì vậy muốn điểm tăng nhanh, hãy nhìn vào ba chỉ số này trước.
| Chỉ số Lighthouse | Trọng số | Liên quan đến |
|---|---|---|
| Total Blocking Time (TBT) | 30% | INP, qua mã JavaScript chặn luồng chính |
| Largest Contentful Paint (LCP) | 25% | LCP |
| Cumulative Layout Shift (CLS) | 25% | CLS |
| First Contentful Paint (FCP) | 10% | Cảm giác trang bắt đầu hiện |
| Speed Index | 10% | Tốc độ lấp đầy màn hình |
Nguồn: web.dev, bài Lighthouse performance scoring (Lighthouse 10 trở lên), ghi nhận 10/10/2026. Tổng trọng số = 100%.
Điểm tổng chỉ là con số tiện nhìn. Điều bạn cần là mục Largest Contentful Paint element và các tác vụ dài trong báo cáo, vì chúng chỉ ra phần tử cụ thể cần sửa.
Cải thiện LCP: chia 2,5 giây thành bốn phần rồi tìm phần bị vượt
LCP không chỉ là chuyện ảnh nặng. Google chia thời gian LCP thành bốn phần, và mỗi phần có tỷ lệ lý tưởng riêng. Bạn chỉ cần xem phần nào vượt ngân sách.
| Phần của LCP | Tỷ lệ lý tưởng | Ngân sách trong 2.500 ms | Cách giảm |
|---|---|---|---|
| TTFB (máy chủ trả byte đầu tiên) | khoảng 40% | 1.000 ms | Cache trang, CDN, hosting mạnh hơn. TTFB tốt là ≤ 800 ms |
| Độ trễ bắt đầu tải tài nguyên | dưới 10% | 250 ms | Để ảnh LCP có sẵn trong HTML, không chờ JavaScript chèn vào |
| Thời gian tải tài nguyên | khoảng 40% | 1.000 ms | Ảnh WebP đúng kích thước hiển thị, ưu tiên tải bằng fetchpriority |
| Độ trễ hiển thị | dưới 10% | 250 ms | Bớt CSS và JavaScript chặn hiển thị, bớt hiệu ứng khởi tạo |
Nguồn: web.dev, bài Optimize Largest Contentful Paint; số ms do chúng tôi tính từ tỷ lệ, ghi nhận 10/10/2026.
Có ba lỗi hay gặp. Thứ nhất, đặt loading="lazy" cho ảnh đầu trang. Google khuyên không tải lười ảnh LCP; hãy thêm fetchpriority="high" cho ảnh đó. Thứ hai, dùng ảnh gốc 3.000 px để hiển thị trong khung 800 px. Thứ ba, để slider hoặc page builder dựng phần đầu trang bằng JavaScript, khiến trình duyệt chờ mã chạy xong mới vẽ.
Cải thiện INP: tìm tác vụ dài trên luồng chính
INP xấu thường do JavaScript chiếm luồng chính quá lâu. Tác vụ nào chạy quá 50 ms được gọi là tác vụ dài, và trình duyệt không thể phản hồi cú bấm trong lúc nó chạy. Lighthouse không đo INP nên dùng TBT để theo dõi thay thế.
TBT cộng phần vượt 50 ms của mọi tác vụ dài. Ví dụ trang có bốn tác vụ 120, 80, 300 và 45 ms. Phần vượt là 70 + 30 + 250 + 0, tức TBT bằng 350 ms. Chỉ riêng tác vụ 300 ms đã chiếm 250 ms trong số đó, nên cắt nhỏ nó có lợi hơn nhiều so với tối ưu ba tác vụ còn lại.
- Tìm thủ phạm trước: mục Avoid long main-thread tasks trong Lighthouse liệt kê tệp JavaScript và thời gian chạy.
- Trì hoãn mã bên thứ ba: thẻ quảng cáo, chat, bản đồ nên nạp sau khi trang tương tác được.
- Cắt tác vụ dài: chia việc nặng thành nhiều phần nhỏ, nhường luồng chính giữa các phần.
- Bỏ plugin thừa: trên WordPress, mỗi plugin giao diện hoặc slider có thể thêm hàng trăm KB JavaScript.
Cải thiện CLS: giữ chỗ trước cho mọi thứ nạp muộn
Bố cục nhảy khi một phần tử xuất hiện mà trình duyệt chưa biết nó cao bao nhiêu. Cách sửa chung là khai kích thước trước.
- Ảnh và iframe: luôn có
widthvàheighthoặcaspect-ratio, kể cả ảnh nhỏ ở chân trang. - Banner, popup, thanh thông báo: chừa sẵn chiều cao, hoặc để chúng phủ lên nội dung thay vì đẩy nội dung xuống.
- Nhúng bên ngoài: video, bản đồ, khung đánh giá cần một khung có chiều cao cố định.
- Hiệu ứng: dùng
transformthay vì đổitop,heighthaymargin.
CLS dễ kiểm hơn hai chỉ số kia: báo cáo Lighthouse chỉ rõ phần tử nào nhảy và nhảy bao nhiêu. Nên làm CLS sớm vì mỗi lỗi thường chỉ cần sửa một dòng.
Số đo thật: Lighthouse chạy trên trang chủ netsolutions.vn
Chúng tôi đo chính website của mình trước khi hướng dẫn người khác. Ngày 10/10/2026, Lighthouse 12.8.2 chạy một lượt trên trang chủ, một lần cho điện thoại và một lần cho máy tính. Đây là dữ liệu giả lập, chưa phải dữ liệu thật từ người dùng.
| Chỉ số | Điện thoại | Máy tính | Ngưỡng tốt |
|---|---|---|---|
| Điểm Performance | 26 | 46 | 90 trở lên |
| LCP | 6,6 giây | 4,5 giây | ≤ 2,5 giây |
| CLS | 0,137 | 0,243 | ≤ 0,1 |
| TBT | 10.610 ms | 250 ms | càng thấp càng tốt |
| Máy chủ trả byte đầu tiên | 668 ms | 266 ms | ≤ 800 ms |
Nguồn: Lighthouse 12.8.2, một lượt đo mỗi khung, trang chủ netsolutions.vn, 10/10/2026. TBT trên điện thoại dao động mạnh giữa các lượt đo.
Điều đáng đọc nằm ở bốn phần của LCP. Trên điện thoại, máy chủ trả byte đầu tiên sau 668 ms, trong ngân sách 1.000 ms. Phần còn lại, 5.945 ms, là độ trễ hiển thị, tức 90% thời gian LCP. Trên máy tính con số là 94%.
Ngân sách cho phần này chỉ là 250 ms. Con số thực tế gấp khoảng 23,8 lần. Phần tử LCP là một khối chữ trên điện thoại và một lớp chữ của slider trên máy tính, không phải ảnh nặng. Nén ảnh ở đây sẽ không giải quyết được gì.
Báo cáo chỉ ra hai điểm. Thứ nhất, hai tệp CSS của giao diện chặn hiển thị, Lighthouse ước tính tiết kiệm được 970 ms trên điện thoại. Thứ hai, trên điện thoại có 13.126 ms tác vụ dài, trong đó 9.443 ms (72%) đến từ tệp JavaScript của plugin slider, riêng một tác vụ kéo dài 7.867 ms.
CLS cũng vượt ngưỡng: 0,137 trên điện thoại và 0,243 trên máy tính, so với mức tốt là 0,1. Chúng tôi chưa sửa các điểm này khi viết bài. Đây là lý do chúng tôi muốn cho thấy cách đọc báo cáo trên một trang có vấn đề thật, thay vì một ví dụ đã được làm đẹp.
Quy trình đo và sửa Core Web Vitals của chúng tôi
Quy trình dưới đây áp dụng cho cả website của chúng tôi lẫn khách hàng. Nó đi từ dữ liệu thật đến nguyên nhân cụ thể, rồi đo lại sau khi dữ liệu 28 ngày đã quay vòng. Phần kiểm tra kỹ thuật này là một nhóm việc trong dịch vụ SEO audit chuyên sâu.
- Xem dữ liệu thật: báo cáo Core Web Vitals trong Search Console, xem nhóm URL nào không đạt.
- Xác định chỉ số đỏ: LCP, INP hay CLS, trên điện thoại hay máy tính.
- Tìm phần tử gây ra: chạy Lighthouse, đọc phần tử LCP, tác vụ dài, nguồn nhảy bố cục.
- Sửa một nguyên nhân mỗi lần: để biết thay đổi nào có tác dụng.
- Đo lại sau 28 ngày: dữ liệu thật mới phản ánh thay đổi.
Với website WordPress, phần cache, plugin và hosting nằm trong dịch vụ chăm sóc website; phần nội dung và cấu trúc nằm trong dịch vụ SEO. Cách tốc độ tác động đến thứ tự ưu tiên on-page được nói ở bài SEO on-page.
Điều chúng tôi không làm, và khi nào bạn chưa cần sửa
Chúng tôi không cam kết thứ hạng sau khi sửa Core Web Vitals, vì Google không công bố mức ảnh hưởng và nội dung vẫn là yếu tố chính. Chúng tôi cũng không cam kết điểm Lighthouse 100: điểm giả lập thay đổi theo từng lượt đo.
Bạn chưa cần sửa nếu Search Console báo cả ba chỉ số đạt ở nhóm URL quan trọng. Lúc đó hãy dồn công sức vào nội dung. Nếu site còn quá ít lượt truy cập để có dữ liệu thật, đừng chạy theo điểm giả lập; hãy sửa những lỗi hiển nhiên như ảnh không khai kích thước hay banner đẩy bố cục.
Câu hỏi thường gặp
Core Web Vitals có ảnh hưởng đến thứ hạng không? Có, như một tín hiệu trải nghiệm trang. Google nói rõ nội dung liên quan vẫn được ưu tiên, và không công bố tỷ trọng cụ thể. Bất kỳ con số phần trăm ảnh hưởng nào bạn thấy trên mạng đều không có nguồn từ Google.
Cải thiện xong bao lâu thì thấy kết quả? Báo cáo Search Console và CrUX dùng dữ liệu 28 ngày cuộn. Sau khi sửa, bạn cần khoảng bốn tuần để số liệu thật phản ánh đủ thay đổi. Thứ hạng có tăng hay không còn phụ thuộc yếu tố khác, nên không ai hứa trước được.
Điểm PageSpeed và dữ liệu Search Console khác nhau, tin cái nào? Dùng Search Console để biết trang có đạt không, vì đó là dữ liệu thật. Dùng Lighthouse để tìm nguyên nhân, vì chỉ nó cho biết phần tử cụ thể. Hai loại dữ liệu bổ sung cho nhau.
CrUX khác RUM tự đo ở điểm nào? CrUX là dữ liệu Chrome tự thu từ người dùng Chrome đồng ý chia sẻ, công khai và miễn phí. RUM là script bạn tự gắn vào site để thu dữ liệu của mọi trình duyệt, chi tiết hơn nhưng cần tự triển khai và lưu trữ.
Bao lâu nên kiểm tra một lần? Xem báo cáo Search Console mỗi tháng là đủ cho đa số website. Kiểm tra thêm ngay sau khi đổi giao diện, cài plugin mới hoặc thêm thẻ theo dõi, vì đây là những thay đổi hay làm tụt chỉ số.
Nên sửa LCP, INP hay CLS trước? Sửa chỉ số đang ở mức kém trên Search Console trước. Nếu cả ba cùng kém, bắt đầu với CLS vì dễ sửa nhất, rồi LCP, sau cùng là INP vì thường đụng đến mã JavaScript.
Nếu bạn muốn biết website của mình đang đỏ ở chỉ số nào và nguyên nhân nằm ở đâu, hãy gọi 0906.207.001 hoặc nhắn Zalo cùng số. Chúng tôi sẽ đọc báo cáo cùng bạn và nói thẳng việc nào đáng sửa.
Cập nhật 10/10/2026 bởi Công ty TNHH Net Solutions.
