Core Web Vitals là gì? 3 chỉ số LCP, INP, CLS và cách tối ưu

4.9/5 - (118 bình chọn)

Bạn đã từng thoát khỏi một website vì trang tải quá lâu, bấm nút mà không thấy phản hồi, hoặc đang định bấm vào một liên kết thì nội dung bị “nhảy” sang chỗ khác? Đó chính là những trải nghiệm mà Core Web Vitals được tạo ra để đo lường.

Core Web Vitals là bộ chỉ số do Google đề xuất để đánh giá trải nghiệm thực tế của người dùng trên một trang web. Google xác nhận các chỉ số này được hệ thống xếp hạng của Google Search sử dụng. Vì vậy, đây là phần không thể bỏ qua khi làm SEO và thiết kế website hiện nay.

Bài viết này tổng hợp từ tài liệu chính thức của Google (web.dev, Google Search Central). HATENA sẽ giải thích dễ hiểu từng chỉ số LCP, INP, CLS, cách đo đúng, và những cách tối ưu thực tế cho website doanh nghiệp, đặc biệt là website WordPress.

1. Core Web Vitals là gì?

Core Web Vitals là một phần trong sáng kiến Web Vitals của Google. Mục tiêu là đưa ra một bộ chỉ số thống nhất, dễ hiểu, để chủ website không cần là chuyên gia hiệu năng vẫn biết trang của mình mang lại trải nghiệm tốt hay chưa.

Hiện nay, Core Web Vitals gồm 3 chỉ số, tương ứng với 3 khía cạnh của trải nghiệm người dùng:

Tốc độ tải: Largest Contentful Paint (LCP).
Khả năng phản hồi khi tương tác: Interaction to Next Paint (INP).
Độ ổn định của bố cục: Cumulative Layout Shift (CLS).

Bộ chỉ số này có thể thay đổi theo thời gian. Ví dụ tiêu biểu: từ tháng 3/2024, chỉ số INP đã chính thức thay thế FID (First Input Delay) vì INP phản ánh khả năng phản hồi của trang đầy đủ hơn. Theo web.dev, Google cam kết các chỉ số ổn định sẽ không thay đổi quá một lần mỗi năm và luôn thông báo trước.

2. Ba chỉ số Core Web Vitals: LCP, INP, CLS

2.1. LCP (Largest Contentful Paint): Nội dung chính hiển thị nhanh đến đâu?

LCP đo thời gian từ lúc người dùng bắt đầu tải trang đến khi phần tử nội dung lớn nhất trong khung nhìn hiển thị xong. Phần tử này thường là ảnh banner đầu trang, ảnh sản phẩm hoặc một khối văn bản lớn.

Theo dữ liệu Web Almanac 2024 do web.dev trích dẫn, 73% trang trên di động có phần tử LCP là hình ảnh. Vì vậy, ảnh đầu trang thường là “thủ phạm” chính khiến LCP chậm.

2.2. INP (Interaction to Next Paint): Trang phản hồi nhanh đến đâu khi người dùng thao tác?

INP đo độ trễ từ lúc người dùng bấm, chạm hoặc gõ phím đến khi trình duyệt hiển thị phản hồi tiếp theo. INP xét toàn bộ các lần tương tác trong suốt thời gian người dùng ở trên trang, không chỉ lần đầu tiên như FID trước đây.

INP kém thường gặp ở các website có quá nhiều JavaScript: slider nặng, popup, plugin chat, mã theo dõi quảng cáo, page builder phức tạp.

2.3. CLS (Cumulative Layout Shift): Bố cục có bị “nhảy” không?

CLS đo mức độ các phần tử trên trang bị dịch chuyển bất ngờ trong khi người dùng đang xem. Ví dụ: đang đọc thì một banner quảng cáo chèn vào phía trên làm toàn bộ nội dung bị đẩy xuống, hoặc bấm nhầm nút vì nút vừa bị dịch chỗ.

2.4. Ngưỡng đánh giá Core Web Vitals chuẩn của Google

Chỉ số	Tốt	Cần cải thiện	Kém
LCP	≤ 2,5 giây	2,5 – 4 giây	> 4 giây
INP	≤ 200 mili giây	200 – 500 mili giây	> 500 mili giây
CLS	≤ 0,1	0,1 – 0,25	> 0,25

Điểm quan trọng mà nhiều người hiểu sai: Google đánh giá theo phân vị thứ 75 của các lượt tải trang thực tế, tách riêng cho di động và máy tính. Nghĩa là ít nhất 75% lượt truy cập phải đạt ngưỡng “Tốt”. Một trang chỉ được coi là đạt khi cả 3 chỉ số đều đạt ngưỡng tốt.

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

Theo tài liệu Understanding page experience của Google Search Central:

Core Web Vitals được hệ thống xếp hạng của Google sử dụng. Google khuyến nghị chủ website đạt Core Web Vitals tốt để thành công trên Google Search.
Tuy nhiên, điểm tốt trong Search Console hay các công cụ khác không đảm bảo trang sẽ lên top. Google vẫn ưu tiên nội dung liên quan và hữu ích nhất, kể cả khi trải nghiệm trang chưa hoàn hảo.
Khi có nhiều trang cùng hữu ích như nhau, trải nghiệm trang tốt có thể là yếu tố giúp bạn vượt lên.
Google cũng nói rõ: cố đạt điểm tuyệt đối chỉ vì SEO có thể không phải là cách dùng thời gian hiệu quả nhất.

Kết luận thực tế: Core Web Vitals không thay thế được nội dung tốt, nhưng là “điểm cộng” giúp nội dung tốt cạnh tranh hiệu quả hơn. Quan trọng hơn, website nhanh và ổn định giúp giảm tỷ lệ thoát, tăng tỷ lệ khách để lại thông tin hoặc mua hàng. Đây là lợi ích trực tiếp về doanh thu, không chỉ là SEO.

Nếu bạn muốn hiểu toàn bộ các yếu tố kỹ thuật khác, hãy xem thêm bài 12 tiêu chí website chuẩn SEO của HATENA.

4. Cách đo Core Web Vitals đúng: dữ liệu thực tế và dữ liệu phòng thí nghiệm

Có hai loại dữ liệu mà bạn cần phân biệt rõ:

Dữ liệu thực tế (field data): Thu thập từ người dùng Chrome thật qua báo cáo CrUX (Chrome User Experience Report). Đây là dữ liệu Google dùng để đánh giá.
Dữ liệu phòng thí nghiệm (lab data): Mô phỏng một lần tải trang trong môi trường giả lập, ví dụ Lighthouse. Hữu ích để tìm lỗi và thử nghiệm trước khi cập nhật website.

4.1. Các công cụ đo Core Web Vitals miễn phí

PageSpeed Insights: Hiển thị cả dữ liệu thực tế (nếu trang đủ lượt truy cập) và điểm Lighthouse. Phần đầu “Khám phá trải nghiệm của người dùng thực” mới là phần quan trọng nhất.
Google Search Console → Chỉ số thiết yếu về trang web: Nhóm các URL theo trạng thái Tốt/Cần cải thiện/Kém, giúp phát hiện lỗi hàng loạt theo mẫu trang.
Chrome DevTools: Tab Performance đo được cả LCP, INP, CLS khi bạn thao tác trực tiếp trên trang.

4.2. Vì sao điểm Lighthouse và dữ liệu thực tế khác nhau?

Lighthouse chạy trong môi trường giả lập, không có người dùng thật, nên không đo được INP. Thay vào đó, Lighthouse dùng chỉ số TBT (Total Blocking Time) làm chỉ số tham khảo. Cải thiện TBT trong phòng thí nghiệm thường giúp cải thiện INP thực tế.

Ngoài ra, người dùng thật có thiết bị, mạng 4G/Wi-Fi rất khác nhau. Vì vậy, điểm PageSpeed 95 không có nghĩa là Core Web Vitals đạt, và ngược lại. Hãy luôn ưu tiên dữ liệu thực tế khi đánh giá.

Với website mới hoặc ít truy cập, PageSpeed Insights có thể báo “không đủ dữ liệu”. Khi đó, bạn dùng dữ liệu phòng thí nghiệm để tối ưu trước, rồi theo dõi Search Console khi lượng truy cập tăng.

5. Cách tối ưu LCP: giúp nội dung chính hiển thị nhanh hơn

Dưới đây là các khuyến nghị có tác động lớn nhất theo nhóm Chrome (bài The most effective ways to improve Core Web Vitals trên web.dev), kèm cách áp dụng thực tế:

5.1. Để trình duyệt phát hiện ảnh LCP ngay trong HTML

Dùng thẻ <img> với thuộc tính src hoặc srcset cho ảnh banner đầu trang. Tránh đặt ảnh chính làm background-image trong CSS hoặc dùng data-src chờ JavaScript nạp. Theo web.dev, 7% trang đang giấu ảnh LCP sau data-src.
Không lazy-load ảnh đầu trang. Bỏ loading="lazy" khỏi ảnh LCP. Đây là lỗi rất phổ biến khi bật lazy-load cho toàn bộ ảnh bằng plugin.
Thêm fetchpriority="high" cho ảnh LCP để trình duyệt ưu tiên tải trước.

5.2. Giảm thời gian phản hồi máy chủ (TTFB)

Trình duyệt không thể tải bất kỳ thứ gì trước khi nhận được byte đầu tiên của trang. Để giảm TTFB:

Dùng bộ nhớ đệm trang (page cache) để máy chủ không phải xử lý PHP và truy vấn cơ sở dữ liệu cho mỗi lượt xem.
Dùng CDN để phân phối nội dung từ máy chủ gần người dùng. Web.dev cho biết mới chỉ khoảng 33% yêu cầu tài liệu HTML được phục vụ qua CDN, nên đây vẫn là dư địa cải thiện lớn.
Chọn hosting có máy chủ đặt gần khách hàng mục tiêu, dùng phiên bản PHP mới và ổ cứng NVMe. Xem thêm bài Hosting ảnh hưởng như thế nào đến SEO.

5.3. Tối ưu dung lượng hình ảnh

Chuyển ảnh sang định dạng WebP hoặc AVIF, nén ảnh trước khi tải lên.
Cắt ảnh đúng kích thước hiển thị, không dùng ảnh 4000px cho khung 1200px.
Dùng srcset để trình duyệt tự chọn ảnh nhỏ hơn cho điện thoại. WordPress tự tạo srcset nếu bạn chèn ảnh từ thư viện.

5.4. Hạn chế tài nguyên chặn hiển thị

Các file CSS, JavaScript lớn nạp ở đầu trang khiến trình duyệt phải chờ trước khi vẽ nội dung. Hãy hoãn (defer) JavaScript không quan trọng, gộp và rút gọn CSS, loại bỏ font chữ không dùng tới.

6. Cách tối ưu INP: giúp website phản hồi tức thì

6.1. Chia nhỏ các tác vụ dài (long tasks)

Theo web.dev, mọi tác vụ chạy quá 50 mili giây được gọi là tác vụ dài. Khi một tác vụ dài đang chạy, trình duyệt không thể phản hồi thao tác của người dùng. Lập trình viên cần chia nhỏ các đoạn xử lý JavaScript nặng để trình duyệt có cơ hội phản hồi ở giữa.

6.2. Loại bỏ JavaScript không cần thiết

Gỡ các plugin không dùng tới. Mỗi plugin có thể nạp thêm file JavaScript trên mọi trang.
Rà soát Google Tag Manager định kỳ, xóa các thẻ theo dõi cũ không còn dùng.
Trì hoãn các tiện ích chat, widget mạng xã hội cho đến khi người dùng cuộn trang hoặc tương tác.
Dùng tab Coverage trong Chrome DevTools để tìm mã không được sử dụng.

6.3. Giữ cấu trúc trang (DOM) gọn nhẹ

Web.dev chỉ ra rằng kích thước DOM càng lớn thì mỗi lần cập nhật giao diện càng tốn nhiều công tính toán. Các page builder lồng quá nhiều lớp div, menu hàng trăm mục, trang danh mục hiển thị quá nhiều sản phẩm đều làm DOM phình to.

7. Cách tối ưu CLS: chống “nhảy” bố cục

Luôn khai báo kích thước cho ảnh và video bằng thuộc tính width và height để trình duyệt giữ chỗ trước khi ảnh tải xong.
Dành sẵn không gian cho quảng cáo, banner, iframe (bản đồ, video YouTube) bằng chiều cao tối thiểu cố định.
Không chèn nội dung lên phía trên nội dung đang hiển thị, như thanh thông báo cookie hoặc banner khuyến mãi đẩy toàn bộ trang xuống. Nếu cần, dùng dạng nổi (overlay) ở cuối màn hình.
Tối ưu font chữ: tải trước (preload) font chính, dùng font-display hợp lý để hạn chế việc chữ đổi kích thước khi font tải xong.
Dùng hiệu ứng bằng thuộc tính transform thay vì thay đổi top, height để không gây dịch chuyển bố cục.
Đảm bảo trang dùng được bộ nhớ đệm quay lại (bfcache): Khi người dùng bấm “Quay lại”, trang hiển thị tức thì và không bị dịch chuyển. Web.dev cho biết hai lý do phổ biến khiến trang không dùng được bfcache là tiêu đề Cache-Control: no-store và sự kiện unload.

8. Checklist tối ưu Core Web Vitals cho website WordPress

Phần lớn website doanh nghiệp tại Việt Nam dùng WordPress. Dưới đây là checklist HATENA thường áp dụng, sắp xếp theo mức độ ưu tiên:

Kiểm tra dữ liệu thực tế trong Search Console để biết nhóm trang nào đang kém và chỉ số nào kém.
Bật page cache và nén GZIP/Brotli. Cân nhắc dùng CDN.
Nâng cấp PHP lên phiên bản được hỗ trợ (PHP 8.x) và kiểm tra tài nguyên hosting.
Thay ảnh đầu trang bằng ảnh WebP dung lượng nhỏ, bỏ lazy-load cho ảnh đó, thêm fetchpriority="high".
Thay slider nhiều ảnh ở đầu trang bằng một ảnh tĩnh. Slider vừa làm chậm LCP vừa tốn JavaScript.
Rà soát và gỡ plugin không cần thiết. Thay plugin nặng bằng giải pháp nhẹ hơn.
Trì hoãn tải mã chat, Facebook Pixel, widget mạng xã hội.
Khai báo width/height cho mọi ảnh, giữ chỗ cho banner và iframe.
Kiểm tra lại trên điện thoại tầm trung với mạng 4G, không chỉ trên máy tính văn phòng.
Theo dõi Search Console sau 28 ngày vì dữ liệu CrUX được tổng hợp theo chu kỳ 28 ngày.

Lưu ý: Đừng cài cùng lúc nhiều plugin tối ưu tốc độ. Các plugin cache, nén mã chồng chéo có thể gây lỗi giao diện hoặc làm trang chậm hơn.

9. Câu hỏi thường gặp về Core Web Vitals

Điểm PageSpeed Insights bao nhiêu là tốt?

Điểm hiệu suất (0-100) là điểm Lighthouse trong phòng thí nghiệm, không phải tiêu chí Google dùng để xếp hạng. Điều quan trọng là phần đánh giá Core Web Vitals từ dữ liệu người dùng thực ở đầu báo cáo đạt “Đạt” (Passed). Một trang có điểm 70 nhưng dữ liệu thực tế đạt chuẩn vẫn tốt hơn trang có điểm 95 mà dữ liệu thực tế kém.

Website ít truy cập có bị Google đánh giá Core Web Vitals không?

Nếu không đủ dữ liệu thực tế trong CrUX, Search Console sẽ không có báo cáo cho trang đó. Tuy nhiên, bạn vẫn nên tối ưu vì trải nghiệm nhanh, ổn định giúp tăng tỷ lệ chuyển đổi ngay từ những khách hàng đầu tiên.

Sau khi tối ưu bao lâu thì Search Console cập nhật?

Dữ liệu Core Web Vitals trong Search Console dựa trên khoảng thời gian 28 ngày gần nhất. Vì vậy, sau khi sửa, bạn cần chờ khoảng 4 tuần để thấy kết quả phản ánh đầy đủ. Bạn có thể dùng tính năng “Xác thực bản sửa lỗi” để Google theo dõi.

FID còn được dùng không?

Không. Từ tháng 3/2024, INP đã thay thế FID trong bộ Core Web Vitals. Nếu tài liệu hoặc công cụ nào còn hướng dẫn tối ưu FID, đó là thông tin đã cũ.

Kết luận

Core Web Vitals gồm LCP, INP và CLS. Đây là cách Google đo trải nghiệm thực tế của người dùng: trang tải nhanh không, phản hồi nhanh không, có ổn định không. Hãy tối ưu dựa trên dữ liệu thực tế, ưu tiên những thay đổi có tác động lớn (ảnh đầu trang, bộ nhớ đệm, JavaScript), và đừng chạy theo con số 100 điểm chỉ để đẹp báo cáo.

Nếu website của bạn đang ở trạng thái “Kém” hoặc “Cần cải thiện” trong Search Console, đội kỹ thuật HATENA có thể phân tích và tối ưu trực tiếp trên mã nguồn. Tham khảo dịch vụ tối ưu PageSpeed website, hoặc liên hệ HATENA để được kiểm tra miễn phí.

Tài liệu tham khảo

Liên hệ HATENA để được tư vấn tối ưu Core Web Vitals và tốc độ website

CÔNG TY TNHH CÔNG NGHỆ PHẦN MỀM HATENA

📞 Hotline: 0934 217 611

📧 Email: hatenasolution@gmail.com

📍 Địa chỉ: Tầng 15, Khối A Tòa nhà Sông Đà, đường Phạm Hùng, Phường Từ Liêm, Thành phố Hà Nội, Việt Nam

HATENA – Đồng hành cùng doanh nghiệp trên hành trình xây dựng và phát triển hệ thống công nghệ số.