Core Web Vitals là gì và cách cải thiện cho website

Core Web Vitals là bộ ba chỉ số của Google đo trải nghiệm thực của người dùng trên một trang web: tốc độ hiển thị nội dung chính (LCP), độ nhanh khi phản hồi tương tác (INP) và độ ổn định bố cục (CLS). Trải nghiệm được xem là "tốt" khi cả ba đạt ngưỡng ở phân vị 75 của dữ liệu thực: LCP ≤ 2,5 giây, INP ≤ 200 ms, CLS ≤ 0,1.

Tóm tắt nhanh

• Core Web Vitals gồm 3 chỉ số: LCP (tải), INP (tương tác), CLS (ổn định hình ảnh).
• Ngưỡng "tốt": LCP ≤ 2,5 s · INP ≤ 200 ms · CLS ≤ 0,1, tính theo phân vị 75 trên di động và máy tính, đo từ người dùng thật.
• INP đã thay thế FID trong bộ Core Web Vitals từ tháng 3/2024.
• Là một tín hiệu trải nghiệm trang mà Google dùng khi xếp hạng, nhưng nội dung đúng ý định tìm kiếm vẫn quan trọng hơn; tốc độ tốt giúp giữ người dùng và giảm tỷ lệ thoát.
• Cách cải thiện chủ yếu: tối ưu ảnh LCP, giảm JavaScript, đặt kích thước cho ảnh/embed/quảng cáo, cache và CDN, tải font hợp lý.
• Với CMS headless, bạn kiểm soát frontend nên tối ưu được tận gốc; KDIGI CMS hỗ trợ bằng HTML sạch kèm width/height cho ảnh, WebP khi upload (site dùng R2) và webhook revalidate.

Core Web Vitals là gì?

Core Web Vitals (CWV) là tập con của "Web Vitals" – sáng kiến của Google nhằm chuẩn hóa các chỉ số chất lượng trải nghiệm. Chúng tập trung vào ba khía cạnh người dùng cảm nhận được:

Chỉ số	Viết tắt của	Đo cái gì	Tốt	Cần cải thiện	Kém
LCP	Largest Contentful Paint	Thời gian hiển thị phần tử nội dung lớn nhất trong khung nhìn (thường là ảnh hero hoặc khối tiêu đề)	≤ 2,5 s	2,5–4 s	> 4 s
INP	Interaction to Next Paint	Độ trễ từ lúc người dùng tương tác (nhấp, chạm, bấm phím) đến khi giao diện cập nhật, lấy giá trị gần như tệ nhất trong suốt phiên	≤ 200 ms	200–500 ms	> 500 ms
CLS	Cumulative Layout Shift	Mức độ bố cục bị xê dịch ngoài ý muốn	≤ 0,1	0,1–0,25	> 0,25

Một trang đạt CWV khi cả ba chỉ số ở mức "tốt" tại phân vị 75, tức 75% lượt truy cập thực tế đạt hoặc tốt hơn ngưỡng. Google đánh giá riêng cho di động và máy tính.

LCP: ảnh hoặc tiêu đề hiện nhanh đến đâu

LCP phụ thuộc bốn khâu nối tiếp: thời gian phản hồi của máy chủ (TTFB), độ trễ phát hiện tài nguyên, thời gian tải tài nguyên (thường là ảnh) và độ trễ render. Khâu nào chậm nhất sẽ kéo LCP.

INP: trang có "mượt" khi bấm không

INP thay thế FID (First Input Delay) từ tháng 3/2024. Khác FID chỉ đo độ trễ của lần tương tác đầu tiên, INP quan sát mọi tương tác trong suốt thời gian người dùng ở trang. JavaScript nặng chiếm luồng chính là nguyên nhân hàng đầu khiến INP kém.

CLS: nội dung có "nhảy" không

CLS tăng khi ảnh không có kích thước, quảng cáo/embed chèn muộn, font tải làm đổi cỡ chữ hoặc banner chèn đẩy nội dung xuống.

Core Web Vitals có ảnh hưởng đến SEO không?

Google nêu rằng Core Web Vitals được các hệ thống xếp hạng cốt lõi sử dụng như một phần của trải nghiệm trang, nhưng không phải yếu tố quyết định: nội dung phù hợp ý định tìm kiếm vẫn được ưu tiên hơn một trang nhanh nhưng nội dung nghèo. Lợi ích thực tế của CWV tốt:

1. Tỷ lệ thoát thấp hơn, chuyển đổi cao hơn vì trang phản hồi nhanh và ổn định.
2. Lợi thế khi hai trang có nội dung tương đương nhau.
3. Nền tảng kỹ thuật chắc chắn cho mọi hoạt động SEO khác – xem Website chuẩn SEO là gì: checklist 2026.

Đừng kỳ vọng CWV "đẩy lên top" một mình; hãy coi nó là điều kiện để không bị tụt hậu.

Cách đo Core Web Vitals

Phân biệt hai loại dữ liệu:

• Dữ liệu thực (field data): từ người dùng Chrome thật, tổng hợp trong Chrome UX Report (CrUX). Đây là dữ liệu Google dùng để đánh giá. Xem ở Search Console → Core Web Vitals và phần đầu của PageSpeed Insights.
• Dữ liệu phòng thí nghiệm (lab data): chạy giả lập bằng Lighthouse/PageSpeed Insights/DevTools. Hữu ích để gỡ lỗi nhưng không phản ánh mọi thiết bị.

Công cụ nên dùng:

Công cụ	Dùng để
Google Search Console	Xem nhóm URL kém/cần cải thiện theo dữ liệu thực
PageSpeed Insights	Xem cả dữ liệu thực (CrUX) lẫn lab cho một URL
Chrome DevTools → Performance, Lighthouse	Gỡ lỗi chi tiết: chuỗi tải, tác vụ dài, layout shift
Thư viện web-vitals (JavaScript)	Tự thu thập LCP/INP/CLS từ người dùng thật của bạn

Ví dụ thu thập số đo thật bằng thư viện chính thức:

import { onLCP, onINP, onCLS } from 'web-vitals'

function send(metric) {
  navigator.sendBeacon('/api/vitals', JSON.stringify(metric))
}
onLCP(send)
onINP(send)
onCLS(send)

Cách cải thiện LCP

1. Xác định phần tử LCP. Dùng PageSpeed Insights hoặc DevTools để xem đó là ảnh hero, tiêu đề hay khối nào.
2. Tối ưu ảnh LCP: dùng định dạng hiện đại (WebP/AVIF), đúng kích thước hiển thị, nén hợp lý; không để loading="lazy" cho ảnh LCP – hãy tải ưu tiên (fetchpriority="high" hoặc priority trong next/image).
3. Giảm TTFB: cache trang ở CDN hoặc tạo trang tĩnh/ISR thay vì render lại mỗi request; đặt máy chủ gần người dùng.
4. Loại bỏ tài nguyên chặn render: CSS/JS không cần thiết ở phần đầu trang, tải font hợp lý.
5. Preload tài nguyên quan trọng: ảnh hero và font chính.

Cách cải thiện INP

1. Giảm lượng JavaScript gửi cho trình duyệt: bỏ thư viện không dùng, tách mã theo trang (code splitting), tải trễ các widget bên thứ ba.
2. Chia nhỏ tác vụ dài (trên 50 ms) để luồng chính kịp xử lý tương tác.
3. Tránh xử lý nặng trong sự kiện nhấp/nhập; chuyển sang web worker hoặc trì hoãn.
4. Kiểm soát script bên thứ ba (chat, tracking, quảng cáo): chỉ nạp khi cần, dùng async/defer.
5. Giảm kích thước DOM quá lớn.

Cách cải thiện CLS

1. Luôn đặt width và height (hoặc aspect-ratio) cho ảnh, video, iframe.
2. Dành chỗ trước cho banner, quảng cáo, khối embed.
3. Không chèn nội dung phía trên nội dung đang hiển thị trừ khi do người dùng thao tác.
4. Tải font có chiến lược: font-display: swap/optional, preload font chính, chọn font dự phòng có kích thước gần với font web.
5. Dùng animation transform thay vì thay đổi thuộc tính ảnh hưởng bố cục.

Cache và CDN: đòn bẩy lớn nhất cho TTFB

Hầu hết cải thiện bền vững đến từ việc không dựng lại trang cho mỗi lượt truy cập:

• Trang tĩnh/ISR: render trước và làm mới khi nội dung đổi.
• CDN: phân phối bản sao gần người dùng, nén brotli/gzip, HTTP/2 hoặc HTTP/3.
• Cache header hợp lý cho tài nguyên tĩnh có băm tên file.

Điều kiện cần là cơ chế làm mới cache khi nội dung thay đổi, nếu không bạn sẽ phải chọn giữa nhanh và đúng.

CMS ảnh hưởng thế nào đến Core Web Vitals?

CMS không tự quyết định CWV, nhưng kiến trúc của nó ảnh hưởng đến mức độ bạn kiểm soát được:

Kiểu CMS	Điểm mạnh	Rủi ro với CWV
Truyền thống (ví dụ WordPress)	Có cache plugin, CDN, theme tối ưu	Nhiều plugin/page builder làm tăng JavaScript và CSS; phải tối ưu liên tục
Headless	Frontend tự chọn: SSG/ISR, ảnh tối ưu, ít JavaScript	Phải tự dựng và tối ưu frontend

Xem thêm WordPress là gì? Ưu nhược điểm và khi nào nên thay thế và CMS là gì? để chọn kiến trúc phù hợp.

KDIGI CMS hỗ trợ gì cho CWV?

Theo tài liệu của dự án, KDIGI CMS là admin + API; phần hiển thị do frontend của bạn quyết định, còn CMS cung cấp những nền tảng sau:

• width/height cho ảnh trong thân bài. Khi REST chuyển Markdown thành HTML, thẻ <img> được chèn width/height từ bản ghi media của site khi biết kích thước – giúp tránh CLS.
• WebP khi upload với site dùng Cloudflare R2; thư viện media có trình sửa ảnh (xoay, lật, cắt, đổi kích thước) và nhập ảnh từ URL (có chống SSRF).
• Media qua CDN. Site có Sites.r2.publicBaseUrl trả URL từ domain công khai của bucket; ảnh sau khi sửa có thêm ?v=<version> để CDN lấy bản mới.
• Webhook revalidate. Khi lưu hoặc xóa nội dung, CMS xếp job revalidateFrontend gọi POST https://{domain}/api/cms/revalidate (timeout 5 giây, thử lại 3 lần) để frontend làm mới đúng trang – cho phép dùng trang tĩnh/ISR mà không bị nội dung cũ. Cần đặt ENABLE_JOBS_AUTORUN=true trên đúng một instance.
• Chỉ lấy trường cần thiết. select và depth giúp giảm kích thước phản hồi API cho danh sách; ví dụ: ?select[title]=true&select[slug]=true&depth=1.
• Ảnh OG fallback giúp chia sẻ nhanh và đẹp mà không cần nhập tay từng trang.

Đoạn mã dưới đây (Next.js, App Router) minh họa ý tưởng ISR kết hợp webhook; tên hàm là ví dụ, bạn thay bằng cách làm của mình:

// app/api/cms/revalidate/route.ts
import { revalidatePath } from 'next/cache'

export async function POST(req: Request) {
  const { collection, slug } = await req.json()
  // collection: "posts" | "pages" | ... ; slug có thể là id với menus/faqs
  revalidatePath(collection === 'posts' ? `/blog/${slug}` : `/${slug}`)
  return Response.json({ ok: true })
}

Lưu ý từ tài liệu: request này không được xác thực, vì vậy handler phải idempotent, rẻ và nên được bảo vệ hoặc giới hạn tốc độ ở lớp biên nếu cần. Chi tiết hợp đồng API có trong Headless API và Thư viện media.

Checklist cải thiện Core Web Vitals

• [ ] Xác định nhóm URL kém trong Search Console và chọn 3–5 mẫu trang tiêu biểu.
• [ ] Ghi lại phần tử LCP của từng mẫu trang.
• [ ] Ảnh LCP: định dạng hiện đại, đúng kích thước, tải ưu tiên, không lazy.
• [ ] Mọi ảnh/video/iframe có kích thước hoặc aspect-ratio.
• [ ] Giảm JavaScript không dùng; trì hoãn script bên thứ ba.
• [ ] Trang tĩnh/ISR hoặc cache CDN; TTFB ổn định.
• [ ] Font: preload font chính, font-display phù hợp.
• [ ] Đo lại bằng dữ liệu thực sau 28 ngày (CrUX là cửa sổ trượt khoảng 28 ngày) trước khi kết luận.

Những hiểu lầm thường gặp

• "Điểm Lighthouse 100 là đạt CWV." Lighthouse là dữ liệu lab; CWV đánh giá bằng dữ liệu thực ở phân vị 75.
• "Nén ảnh là đủ." Nếu ảnh LCP bị lazy-load hoặc phát hiện muộn, LCP vẫn chậm.
• "Cài thêm plugin tốc độ là xong." Plugin cũng thêm JavaScript/CSS; cải thiện bền vững đến từ việc giảm thứ phải tải.
• "CWV là tất cả của SEO." Nó là một phần của trải nghiệm trang; hãy làm cùng nội dung, cấu trúc và dữ liệu có cấu trúc.

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

Core Web Vitals là gì?

Core Web Vitals là ba chỉ số của Google đo trải nghiệm thực của người dùng: LCP (tốc độ hiển thị nội dung chính), INP (độ nhanh phản hồi khi tương tác) và CLS (độ ổn định bố cục). Trang đạt khi cả ba ở mức tốt tại phân vị 75 của dữ liệu thực.

Ngưỡng Core Web Vitals tốt là bao nhiêu?

LCP không quá 2,5 giây, INP không quá 200 mili giây và CLS không quá 0,1. Giá trị được tính ở phân vị 75 của lượt truy cập thực, riêng cho di động và máy tính. Mức "kém" là LCP trên 4 giây, INP trên 500 ms hoặc CLS trên 0,25.

INP khác FID như thế nào?

FID chỉ đo độ trễ của lần tương tác đầu tiên, còn INP xem xét mọi tương tác trong suốt phiên và đo cả thời gian đến khi giao diện được cập nhật. INP thay thế FID trong Core Web Vitals từ tháng 3/2024 nên phản ánh sát hơn cảm giác "mượt" của trang.

Core Web Vitals có phải yếu tố xếp hạng không?

Có, nhưng chỉ là một phần của tín hiệu trải nghiệm trang và không thay thế được nội dung phù hợp ý định tìm kiếm. Trang chậm nhưng có nội dung tốt vẫn có thể xếp hạng; tuy nhiên tốc độ tốt giúp giữ người dùng và là lợi thế khi nội dung tương đương.

Vì sao PageSpeed Insights hiển thị hai loại số liệu?

Phần "Discover what your real users are experiencing" là dữ liệu thực từ CrUX (người dùng Chrome thật, cửa sổ khoảng 28 ngày) và là cơ sở đánh giá của Google. Phần Lighthouse là dữ liệu lab chạy giả lập để gỡ lỗi nên có thể khác dữ liệu thực.

CMS headless có giúp Core Web Vitals tốt hơn không?

Không tự động, nhưng cho bạn kiểm soát hoàn toàn frontend: dùng trang tĩnh/ISR, ảnh tối ưu, ít JavaScript. Đổi lại bạn phải tự dựng và tối ưu. Với KDIGI CMS, API trả HTML sạch có width/height cho ảnh và webhook revalidate để làm mới cache đúng lúc.

Nguồn

• web.dev – Web Vitals, LCP, INP, CLS
• web.dev – INP trở thành Core Web Vital
• Google Search Central – Understanding page experience in Google Search results
• Google – PageSpeed Insights và Chrome UX Report
• GoogleChrome – thư viện web-vitals
• KDIGI CMS – Tài liệu REST API và media và mã nguồn

Bài viết do Đội ngũ KDIGI biên soạn, cập nhật 03/11/2026. Ngưỡng và tiêu chí của Google có thể thay đổi; hãy đối chiếu với tài liệu web.dev khi áp dụng.