Core Web Vitals là gì? Cách tối ưu cải thiện CWV tốt nhất cho SEO 2025

Viết bởi: Nguyễn Thanh Trường

Cập nhật lần gần đây nhất: 15:56 - 05/09/2025

Cập nhật tin tức SEO hàng ngày:

Core Web Vitals là một tập hợp ba chỉ số quan trọng gồm LCP, INP, CLS, được Google sử dụng để đánh giá chất lượng trải nghiệm người dùng trên một website. Core Web Vitals tập trung vào ba khía cạnh chính: hiệu suất tải trang, khả năng tương tác, và độ ổn định hình ảnh.

Vậy làm thế nào để tối ưu Core Web Vitals được Google đánh giá cao? Đo lường hiệu quả sau khi tối ưu Core Web Vitals như thế nào? Tất cả sẽ được tôi, Nguyễn Thanh Trường – Founder & CEO của SEO Center giải đáp chi tiết trong bài viết dưới đây.

Mục tiêu của bài viết này là giúp bạn trang bị kiến thức từ cơ bản đến nâng cao về Core Web Vitals, từ đó có thể tự tay tối ưu website của mình thân thiện hơn trong mắt của người dùng và Google.

Nội dung chính của bài viết:
Core Web Vitals (CWV) là ba chỉ số quan trọng (LCP, INP, CLS) do Google sử dụng để đánh giá chất lượng trải nghiệm người dùng trên website dựa trên hiệu suất tải trang, khả năng tương tác và độ ổn định hình ảnh, có ảnh hưởng đến thứ hạng SEO.
LCP (Largest Contentful Paint) đo tốc độ hiển thị nội dung chính, INP (Interaction to Next Paint) đo khả năng phản hồi của trang với tương tác người dùng, và CLS (Cumulative Layout Shift) đo độ ổn định hình ảnh, với mục tiêu đạt điểm “Tốt” lần lượt là <= 2.5s, <= 200ms và <= 0.1.
Để tối ưu CWV, cần tập trung vào nén và lazy load hình ảnh (LCP), giảm thời gian thực thi JavaScript và công việc luồng chính (INP), cùng với việc đặt thuộc tính kích thước cho phương tiện và tránh chèn nội dung động (CLS).
Khi đánh giá CWV, Google ưu tiên dữ liệu thực tế (Field Data) từ người dùng (từ CrUX) thay vì dữ liệu phòng thí nghiệm (Lab Data), và sẽ nhóm các URL có trải nghiệm tương tự để báo cáo, với trạng thái nhóm được quyết định bởi chỉ số CWV tệ nhất.
Luôn sử dụng các công cụ như Google Search Console (để xem tổng quan Field Data), PageSpeed Insights (cho Lab & Field Data của từng URL) và Chrome Lighthouse (để chẩn đoán sâu Lab Data) để theo dõi và xác định các vấn đề cần cải thiện, đồng thời nhớ rằng việc tối ưu CWV là một quá trình liên tục và không chỉ làm một lần.

Nội dung bài học

Core Web Vitals là gì?

“Core Web Vitals” hay CWV là một tập hợp các chỉ số quan trọng mà Google sử dụng để đo lường hiệu suất trải nghiệm của người dùng trên một website. Nói một cách đơn giản, Core Web Vitals giúp Google hiểu được cảm nhận thực tế của bạn khi truy cập một website: liệu nó có mượt mà, nhanh chóng và dễ sử dụng không.

Các chỉ số này tập trung vào ba khía cạnh cốt lõi của trải nghiệm người dùng:

Hiệu suất tải trang (Loading Performance): Điều này đo lường tốc độ web của bạn hiển thị nội dung chính cho người dùng.
Khả năng tương tác (Interactivity): Khía cạnh này đánh giá xem website của bạn phản hồi nhanh đến mức nào khi bạn thực hiện các hành động như nhấp chuột, chạm vào màn hình hoặc gõ phím.
Độ ổn định hình ảnh (Visual Stability): Đây là việc đo lường xem các yếu tố trên website có bị di chuyển hoặc “nhảy” bất ngờ trong quá trình tải hay không.

Tại sao Core Web Vitals lại quan trọng?

Cải thiện trải nghiệm người dùng (UX)

Một website có Core Web Vitals tốt sẽ đảm bảo cung cấp trải nghiệm chất lượng cao cho khách truy cập. Khi trang tải nhanh, phản hồi kịp thời và không có những xê dịch bất ngờ, người dùng sẽ có xu hướng ở lại trang lâu hơn và tương tác nhiều hơn với nội dung.

Hãy tưởng tượng bạn đang tìm mua một chiếc áo online. Nếu web của cửa hàng tải siêu nhanh, bạn bấm chọn màu sắc, size, và thêm vào giỏ hàng mà không hề có độ trễ hay bất kỳ hình ảnh nào nhảy nhót làm bạn bấm nhầm. Bạn sẽ cảm thấy rất thoải mái và có khả năng mua hàng cao hơn. Ngược lại, nếu trang cứ giật giật, nút bấm không phản hồi, bạn sẽ thoát ra ngay lập tức.

Theo tài liệu báo cáo “Milliseconds make Millions”, 70% người tiêu dùng cho biết tốc độ trang ảnh hưởng đến quyết định mua hàng của họ.

Hiệu suất SEO

Google sử dụng Core Web Vitals như một yếu tố xếp hạng trong các kết quả tìm kiếm của mình. Nghĩa là, những website có điểm Core Web Vitals tốt sẽ có khả năng xuất hiện cao hơn trên các trang kết quả tìm kiếm của Google (SERPs).

Tuy nhiên, điều quan trọng cần nhớ là chất lượng và sự liên quan của nội dung vẫn là yếu tố quan trọng nhất. Core Web Vitals không phải là yếu tố duy nhất quyết định thứ hạng, nhưng nó có thể mang lại lợi thế cạnh tranh cho website của bạn, đặc biệt khi nội dung của bạn tương tự với đối thủ nhưng trải nghiệm người dùng trên trang của bạn tốt hơn.

Bạn có thể xem Core Web Vitals như một “yếu tố xếp hạng nhỏ” hoặc “yếu tố phá vỡ thế bế tắc”. Tức là, nếu có hai web đều có nội dung tuyệt vời và rất liên quan đến truy vấn tìm kiếm của người dùng (ví dụ: cả hai đều có bài viết hướng dẫn làm bánh mì tuyệt đỉnh), thì trang nào có trải nghiệm người dùng tốt hơn (nhờ Core Web Vitals) sẽ có cơ hội được xếp hạng cao hơn.

3 Chỉ số Core Web Vitals chính

1. Largest Contentful Paint (LCP)

Largest Contentful Paint hay LCP là chỉ số đo thời gian từ khi trang bắt đầu tải cho đến khi phần tử nội dung lớn nhất có thể nhìn thấy được trong “khung nhìn” được hiển thị hoàn toàn.

Chỉ số này cực kỳ quan trọng vì nó cho bạn biết người dùng cảm nhận được trang của bạn đang thực sự “tải” nhanh đến mức nào. Nếu phần tử chính xuất hiện nhanh, người dùng sẽ có cảm giác web tải nhanh và có tính phản hồi cao.

“Phần tử lớn nhất” này thường là hình Thumbnail, video, hoặc một khối văn bản lớn như H1. Các loại phần tử có thể được tính vào LCP bao gồm thẻ <img>, thẻ <image> bên trong thẻ <svg>, hình ảnh trong thẻ <video>, hình nền được tải bằng hàm url(), hoặc các khối văn bản cấp khối (block-level text elements).

Theo web.dev, LCP của một nhóm URL được thể hiện bằng thời gian mà 75% lượt truy cập vào các URL trong nhóm đó đạt được trạng thái LCP. Nghĩa là Google nhìn vào trải nghiệm của phần lớn người dùng, chứ không phải chỉ một vài trường hợp tốt nhất hay tệ nhất.

Google phân loại điểm LCP thành ba mức, dựa trên thời gian tải của phần tử lớn nhất:

Tốt (Good): <= 2.5 giây. Trang của bạn đang cung cấp trải nghiệm tải nhanh cho người dùng.
Cần cải thiện (Needs Improvement): > 2.5 giây – <= 4 giây. Trang tải hơi chậm, cần xem xét tối ưu hóa.
Kém (Poor): > 4 giây. Trang tải rất chậm, gây khó chịu cho người dùng và có thể khiến họ rời đi.

Ví dụ: Bạn đang truy cập VnExpress để đọc bài viết về kết quả trận bóng đá đêm qua. Khi bạn nhấp vào liên kết, điều đầu tiên bạn muốn thấy là hình ảnh nổi bật của trận đấu hoặc tiêu đề lớn của bài báo. Nếu hình ảnh cầu thủ đang ăn mừng và dòng tiêu đề “Việt Nam thắng lớn!” hiện ra chỉ trong vòng 2 giây, bạn sẽ cảm thấy rất hài lòng vì trang đã tải rất nhanh và bạn đã thấy được nội dung chính ngay lập tức. Đây chính là LCP tốt.

2. Interaction to Next Paint (INP)

Interaction to Next Paint hay INP là chỉ số đo lường thời gian từ khi người dùng tương tác với trang (ví dụ như khi bạn nhấp chuột, chạm vào màn hình cảm ứng, hoặc gõ phím,…) cho đến khi trình duyệt phản hồi tương tác.

Điểm đặc biệt của INP là nó đánh giá toàn bộ khả năng phản hồi của trang đối với tất cả các tương tác xảy ra trong suốt thời gian người dùng truy cập trang, chứ không chỉ tương tác đầu tiên. Giá trị INP cuối cùng sẽ là tương tác dài nhất được quan sát thấy, bỏ qua các trường hợp ngoại lệ.

INP đã chính thức thay thế First Input Delay (FID) làm chỉ số Core Web Vital chính vào ngày 12 tháng 3 năm 2024 vì INP cung cấp cái nhìn toàn diện và chính xác hơn về mức độ phản hồi của trang.

Các tương tác được tính cho INP bao gồm: nhấp vào liên kết hoặc nút, nhập văn bản vào trường, chọn một mục từ menu thả xuống, hoặc mở menu điều hướng trên thiết bị di động. Tuy nhiên, các hành động như cuộn trang hoặc phóng to/thu nhỏ sẽ không được tính vào INP.

Cũng giống như LCP, INP có các ngưỡng cụ thể để đánh giá hiệu suất:

Tốt (Good): <= 200 mili giây (ms). Trang của bạn phản hồi rất nhanh với tương tác của người dùng.
Cần cải thiện (Needs Improvement): > 200 ms – <= 500 ms. Trang phản hồi chấp nhận được nhưng có thể cải thiện để mượt mà hơn.
Kém (Poor): > 500 ms. Có độ trễ đáng kể, gây ra trải nghiệm tương tác không tốt cho người dùng.
INP của nhóm URL cũng được thể hiện bằng giá trị mà 75% lượt truy cập vào các URL trong nhóm đó đạt được hoặc tốt hơn.

Ví dụ: Bạn đang mua sắm trên một trang thương mại điện tử như Shopee. Sau khi tìm được sản phẩm ưng ý, bạn nhấn nút “Thêm vào giỏ hàng”. Nếu giỏ hàng của bạn cập nhật ngay lập tức (ví dụ: hiển thị số lượng sản phẩm tăng lên, hoặc có thông báo “Đã thêm vào giỏ hàng” xuất hiện) chỉ trong vòng dưới 200 mili giây, đó là một INP tốt. Ngược lại, nếu bạn bấm nút và phải chờ đợi vài giây mới thấy giỏ hàng thay đổi, đó là trải nghiệm INP kém.

3. Cumulative Layout Shift (CLS)

Cumulative Layout Shift hay CLS liên quan đến độ ổn định hình ảnh của trang khi nó tải và trong suốt quá trình người dùng tương tác. CLS đo lường tổng điểm của tất cả các lần dịch chuyển bố cục không mong muốn xảy ra trong toàn bộ thời gian tồn tại của trang.

Một “dịch chuyển bố cục” xảy ra khi một phần tử hiển thị trên trang thay đổi vị trí của nó một cách bất ngờ, làm cho các nội dung khác cũng bị di chuyển theo.

Cumulative Layout Shift cực kỳ quan trọng vì việc các phần tử trên trang di chuyển trong khi người dùng đang cố gắng tương tác với chúng sẽ gây ra trải nghiệm rất tồi tệ và gây nhầm lẫn. Ví dụ, bạn đang định nhấp vào một nút nhưng ngay lúc đó, nút lại nhảy đi chỗ khác, khiến bạn nhấp nhầm vào link bài viết chẳng hạn.

Điểm CLS là một số từ 0 đến bất kỳ số dương nào, với 0 nghĩa là không có dịch chuyển bố cục nào xảy ra. Số càng lớn thì càng có nhiều dịch chuyển bố cục trên trang.

CLS của nhóm URL cũng được thể hiện bằng giá trị mà 75% lượt truy cập vào các URL trong nhóm đó đạt được hoặc tốt hơn.

Nguyên nhân phổ biến gây ra tình trạng CLS bao gồm: hình ảnh, quảng cáo, nội dung nhúng (embeds) hoặc iframe không có kích thước xác định; nội dung được chèn bằng JavaScript; hoặc việc áp dụng phông chữ hoặc kiểu dáng muộn trong quá trình tải

Điểm CLS được phân loại như sau:

Tốt (Good): <= 0.1. Trang của bạn có độ ổn định hình ảnh rất tốt, không gây xê dịch khó chịu cho người dùng.
Cần cải thiện (Needs Improvement): > 0.1 – <= 0.25. Có một số dịch chuyển nhỏ, cần xem xét để cải thiện trải nghiệm.
Kém (Poor): > 0.25. Trang có nhiều dịch chuyển bố cục không mong muốn, gây ảnh hưởng đáng kể đến trải nghiệm người dùng.

Ví dụ: Bạn đang đọc một bài blog về các mẹo tiết kiệm điện trong gia đình. Bạn đang đọc dở dòng “Hãy ngắt các thiết bị…” thì đột nhiên, một quảng cáo lớn về tủ lạnh mới xuất hiện ở đầu trang, đẩy toàn bộ nội dung bài viết xuống dưới. Điều này làm bạn mất dòng đang đọc, phải cuộn lại để tìm vị trí cũ, gây khó chịu. Đây chính là một ví dụ về CLS kém.

Cách tối ưu và cải thiện Core Web Vitals

Nguyên tắc chung khi tối ưu Core Web Vitals

Trước khi đi vào chi tiết từng chỉ số, hãy cùng xem xét một số nguyên tắc vàng khi tối ưu hóa Core Web Vitals:

Tối ưu hóa cho trải nghiệm người dùng tốt nhất, không chỉ để đạt các chỉ số của Google. Đừng chỉ chạy theo con số mà bỏ qua cảm nhận thực sự của người dùng.
Nâng cao tốc độ trang để cải thiện trải nghiệm người dùng (UX) và thứ hạng tìm kiếm.
Ưu tiên hiệu suất trên thiết bị di động. Google sử dụng hệ thống lập chỉ mục ưu tiên di động (mobile-first indexing), và hơn 60% lưu lượng truy cập website đến từ thiết bị di động. Do đó, trải nghiệm trên di động cực kỳ quan trọng.
Tập trung vào dữ liệu thực tế (field data). Đây là dữ liệu từ người dùng thực tế, phản ánh chính xác trải nghiệm của họ, thay vì chỉ dựa vào dữ liệu phòng thí nghiệm (lab data) được thu thập trong môi trường kiểm soát.
Thường xuyên theo dõi hiệu suất. Hiệu suất website có thể giảm dần theo thời gian khi nội dung và bố cục thay đổi.

Cách cải thiện LCP

Để cải thiện LCP, bạn cần tập trung vào việc hiển thị nội dung chính nhanh nhất có thể:

1. Tối ưu hóa hình ảnh

Nén hình ảnh để giảm kích thước file.
Sử dụng các định dạng hình ảnh hiện đại như WebP, vì WebP giúp giảm kích thước file tới 34% so với các định dạng truyền thống.
Áp dụng kỹ thuật lazy loading cho các hình ảnh nằm dưới màn hình hiển thị ban đầu (below the fold), tức là những hình ảnh mà người dùng phải cuộn xuống mới thấy. Quan trọng: Tránh lazy loading cho hình ảnh hoặc phần tử lớn nhất nằm trong tầm nhìn đầu tiên của người dùng vì sẽ làm tăng thời gian LCP.
Thay đổi kích thước hình ảnh để không vượt quá mức cần thiết. Ví dụ như chiều ngang phần main Content chỉ có 800px thì bạn chỉ cần làm hình ảnh rộng tối đa 800px là đủ, không cần làm ảnh rộng tới 1000px vì sẽ làm tăng LCP.

2. Sử dụng bộ nhớ đệm (caching)

Bộ nhớ đệm trình duyệt sẽ giúp lưu trữ bản sao các file của trang trên máy tính của người dùng, giảm thời gian tải cho những lần truy cập sau.

Ngoài ra, bạn cũng có thể sử dụng Mạng phân phối nội dung (CDN – Content Delivery Network) như Akamai, Google CloudFront hoặc Cloudflare để phân phối nội dung đã được lưu vào bộ đệm từ các máy chủ gần vị trí người dùng nhất, giúp giảm độ trễ khi tải trang.

3. Giảm thời gian phản hồi của máy chủ

Tối ưu hóa máy chủ và cân nhắc nâng cấp lên nhà cung cấp hosting nhanh hơn như các hosting chuyên dụng hoặc điện toán đám mây. Thời gian phản hồi máy chủ chậm là một nguyên nhân lớn gây LCP kém.
Giảm thiểu việc sử dụng các plugin hoặc script chậm.
Xóa các script bên thứ ba không cần thiết. Các script bên thứ ba có thể làm chậm trang đáng kể, ví dụ, mỗi script có thể làm chậm trang 34ms.

4. Nén CSS

Trong video “Optimize for Core Web Vitals” của Chrome for Developers, Chloé đã tối ưu và nén CSS bằng cách triển khai Critical CSS (chỉ tải CSS cần thiết cho phần hiển thị đầu tiên của trang) trong quy trình xây dựng, giúp giảm FCP từ 2.1 giây xuống 1.1 giây và LCP từ 2.9 giây xuống 1.5 giây.

Họ cũng sử dụng Server Push của Akamai để đẩy các tài nguyên quan trọng như CSS và font chữ đến trình duyệt sớm hơn, giảm LCP từ 4 giây xuống 2.5 giây trong thử nghiệm lab.

Bạn có thể xem qua video chia sẻ về cách tối ưu Core Web Vitals và cách dùng Critical CSS của Chloé ở video dưới đây:

Cách cải Thiện INP

Để cải thiện INP, bạn cần đảm bảo trang phản ứng nhanh nhạy mỗi khi người dùng thực hiện một hành động:

Giảm thời gian thực thi JavaScript:
- Chia nhỏ các tác vụ JavaScript dài thành các tác vụ nhỏ hơn. Khi một tác vụ JavaScript quá dài, trình duyệt sẽ bị “chặn” và không thể phản hồi tương tác của người dùng.
- Trì hoãn (defer) JavaScript không quan trọng và loại bỏ mã không sử dụng.
Giảm thiểu công việc trên luồng chính: Luồng chính của trình duyệt chịu trách nhiệm xử lý hầu hết các tác vụ như phân tích cú pháp HTML, sắp xếp bố cục, vẽ pixel và chạy JavaScript. Tối ưu hóa CSS, sử dụng web worker scripts (cho phép chạy các script nặng ở một luồng riêng biệt, không chặn luồng chính) và tránh các hoạt ảnh nặng.
Ưu tiên nội dung quan trọng: Đảm bảo nội dung mà người dùng cần tương tác xuất hiện và hoạt động trước.
Loại bỏ các script bên thứ ba không quan trọng.
Sử dụng kết xuất trước (prerendering) hoặc kết xuất phía máy chủ (Server-Side Rendering – SSR). SSR có thể giúp giảm công việc JS ban đầu ở phía client.

Cách cải hiện CLS

Đặt thuộc tính kích thước cho phương tiện (hình ảnh, video, iframe)

Luôn chỉ định chiều rộng và chiều cao (width và height) cho tất cả hình ảnh và video. Điều này giúp trình duyệt biết trước bao nhiêu không gian cần dành cho chúng, ngăn chúng “nhảy” khi tải xong.

Ngoài ra, bạn có thể sử dụng CSS aspect ratio boxes (hộp tỷ lệ khung hình) để tạo một vùng chứa có tỷ lệ cố định, đảm bảo mọi thứ giữ nguyên vị trí.

Tránh chèn nội dung động phía trên nội dung hiện có

Đặc biệt là các quảng cáo, banner, hoặc pop-up được chèn động vào giữa hoặc đầu trang mà không có không gian dự trữ. Điều này làm toàn bộ nội dung hiện có bị đẩy xuống.

Chỉ chèn nội dung mới phía trên khi đó là phản hồi trực tiếp từ hành động của người dùng (ví dụ: mở menu điều hướng).

Sử dụng CSS cho các hoạt ảnh

Thay vì thay đổi các thuộc tính kích thước hoặc vị trí (như top, left, width, height) có thể gây dịch chuyển bố cục, hãy sử dụng các thuộc tính CSS như transform và opacity để tạo hoạt ảnh mượt mà hơn và không ảnh hưởng đến bố cục.

Tối ưu hóa phông chữ

Việc tải phông chữ web chậm có thể gây ra hiện tượng “Flash of Unstyled Text” (FOUT) hoặc “Flash of Invisible Text” (FOIT), khiến nội dung văn bản hiển thị rồi thay đổi kiểu chữ, gây dịch chuyển.

Cố gắng sử dụng phông chữ hệ thống (system fonts) nếu có thể, hoặc giới hạn số lượng và cách tải phông chữ web.

Những sai lầm phổ biến cần tránh khi tối ưu Core Web Vitals

Chỉ tập trung vào một chỉ số duy nhất: Các chỉ số Core Web Vitals có mối liên hệ với nhau. Cải thiện một chỉ số (ví dụ: nén hình ảnh quá mức để tăng LCP) có thể vô tình làm xấu đi chỉ số khác (ví dụ: làm tăng CLS do ảnh bị thay đổi kích thước đột ngột). Cần có cái nhìn tổng thể.
Bỏ qua hiệu suất trên di động: Luôn nhớ rằng Google sử dụng lập chỉ mục ưu tiên di động, và trải nghiệm di động của bạn cực kỳ quan trọng.
Bỏ qua tác động tích lũy: Nhiều thay đổi nhỏ, riêng lẻ có vẻ không đáng kể, nhưng tổng hợp lại có thể gây ra tác động lớn đến Core Web Vitals (ví dụ: nhiều script bên thứ ba, dù nhỏ, có thể cộng dồn lại làm ảnh hưởng đến INP). Hãy xem xét lợi ích tổng thể của tất cả các thay đổi.
Bỏ qua dữ liệu người dùng thực (field data): Mặc dù các công cụ như Lighthouse cung cấp dữ liệu phòng thí nghiệm hữu ích để chẩn đoán, nhưng chỉ dữ liệu từ người dùng thực (từ Chrome User Experience Report – CrUX) mới phản ánh chính xác cách khách truy cập trải nghiệm website của bạn.
Không thường xuyên theo dõi hiệu suất: Việc tối ưu hóa Core Web Vitals không phải là công việc chỉ làm một lần. Hiệu suất website sẽ giảm dần theo thời gian khi bố cục và nội dung thay đổi.

Ưu tiên khi tối ưu Core Web Vitals

Xem xét mức độ dễ thực hiện: Một số vấn đề dễ khắc phục hơn (ví dụ: tối ưu hóa hình ảnh cho LCP) so với việc điều chỉnh bố cục phức tạp (cho CLS).

Xem xét mục đích của website:

Nếu website của bạn nặng về nội dung (blog, trang tin tức), ưu tiên LCP trước có thể mang lại tác động lớn nhất vì người dùng muốn thấy nội dung chính nhanh chóng.
Nếu đó là một trang thương mại điện tử hoặc website phụ thuộc nhiều vào tương tác người dùng, thì ưu tiên CLS và INP trước sẽ hợp lý hơn.

Xem xét dữ liệu: Bắt đầu với các trang có hiệu suất kém nhất hoặc có trạng thái “Kém” (Poor) và “Cần cải thiện” (Needs Improvement) trong báo cáo Core Web Vitals của Search Console. Tập trung vào các “nhóm URL” có vấn đề tương tự, vì việc sửa lỗi trên một mẫu có thể cải thiện nhiều trang cùng lúc.

Các công cụ đo lường Core Web Vitals

Các loại dữ liệu đo lường chính

Để hiểu các công cụ hoạt động ra sao, việc đầu tiên là bạn phải phân biệt hai loại dữ liệu này:

1. Field Data

Field Data là dữ liệu được thu thập từ chính những người dùng thực tế khi họ truy cập website của bạn.

Hãy tưởng tượng hàng triệu người dùng trên khắp thế giới đang lướt web của bạn với đủ loại thiết bị (điện thoại cũ, máy tính mới), tốc độ mạng khác nhau (wifi nhanh, 3G chập chờn), và từ nhiều vị trí địa lý khác nhau. Dữ liệu thực tế ghi nhận chính xác những gì họ trải nghiệm.

Dữ liệu này chủ yếu đến từ Báo cáo trải nghiệm người dùng Chrome (CrUX), một bộ dữ liệu công khai được thu thập một cách ẩn danh từ những người dùng trình duyệt Chrome đã đồng ý chia sẻ dữ liệu.

Field Data là loại dữ liệu quan trọng nhất mà Google sử dụng để đánh giá CWV và ảnh hưởng trực tiếp đến thứ hạng tìm kiếm của bạn vì nó phản ánh “thế giới thực”.

Điều này đã được John Mueller nhắc đến trong Video Core Web Vitals and SEO:

Tuy nhiên, vì là dữ liệu trung bình được thu thập trong khoảng một tháng, nên khi bạn thực hiện thay đổi trên website, sẽ mất khoảng 28 ngày để thấy được tác động của những thay đổi đó trong báo cáo dựa trên dữ liệu thực tế. Nó cũng không cung cấp chi tiết “từng bước” để chẩn đoán vấn đề cụ thể.

2. Lab Data

Lab Data là dữ liệu được thu thập trong một môi trường được kiểm soát, với các điều kiện mạng (ví dụ: tốc độ 3G mô phỏng) và thiết bị (ví dụ: một loại điện thoại cụ thể mô phỏng) đã được cố định.

Nhiều công cụ hiện nay sử dụng Lighthouse làm nền tảng cho các bài kiểm tra phòng thí nghiệm.

Lab Data cực kỳ hữu ích cho các nhà phát triển vì:

Bạn có thể thử nghiệm các thay đổi mà không cần phải chờ đợi dữ liệu người dùng thực.
Nó cung cấp chi tiết rất sâu về những gì đang xảy ra trên website của bạn.
Phát hiện các lỗi hiệu suất trước khi chúng xảy ra. Chẳng hạn, một phiên bản code mới có thể làm chậm web, bạn sẽ biết được ngay lập tức.
Vì môi trường cố định, bạn có thể chạy lại cùng một thử nghiệm nhiều lần và nhận được kết quả tương tự.

Tuy nhiên Lab Data này không thể phản ánh chính xác trải nghiệm của mọi người dùng trong thế giới thực, vì nó bỏ qua các yếu tố như bộ nhớ đệm của trình duyệt, ứng dụng chạy nền trên thiết bị người dùng, hay vị trí địa lý của họ. Ví dụ, một website có thể đạt điểm “Tốt” trong môi trường phòng thí nghiệm nhưng lại “Kém” đối với người dùng ở vùng có mạng yếu.

6 Công cụ hỗ trợ đo lường Core Web Vitals chính

1. Báo cáo Core Web Vitals trong Google Search Console (GSC)

Google Search Console là một công cụ miễn phí của Google, cung cấp bức tranh tổng thể về hiệu suất CWV của website bạn dựa trên dữ liệu thực tế (CrUX).

Chức năng chính của Google Search Console:

Phân loại trang theo trạng thái: GSC sẽ nhóm các URL trên website của bạn thành ba loại: Kém (Poor), Cần cải thiện (Needs Improvement) và Tốt (Good).
Nhóm các URL tương tự: Thay vì hiển thị từng URL riêng lẻ, GSC nhóm các trang có trải nghiệm người dùng tương tự lại với nhau. Điều này rất hữu ích vì thường một lỗi hiệu suất xuất phát từ một mẫu thiết kế hoặc template chung, khi bạn sửa một lần, nó sẽ cải thiện cho cả nhóm trang đó.
Ưu tiên chỉ số tệ nhất: Nếu một nhóm URL có nhiều chỉ số CWV (LCP, INP, CLS), trạng thái của nhóm đó sẽ được quyết định bởi chỉ số tệ nhất. Ví dụ, nếu CLS là “Kém” nhưng LCP là “Tốt”, cả nhóm URL đó sẽ được gắn nhãn “Kém”.
Chỉ hiển thị URL đã lập chỉ mục: Báo cáo này chỉ hiển thị một mẫu các URL đã được Google lập chỉ mục.
Lý do “Không có dữ liệu”: Nếu bạn thấy thông báo “No data available” (Không có dữ liệu), có thể website của bạn mới được thêm vào Search Console, hoặc không có đủ dữ liệu người dùng thực cho loại thiết bị (di động/máy tính) mà bạn đang chọn để báo cáo.
Xác thực sửa lỗi: Sau khi bạn đã sửa một vấn đề, bạn có thể yêu cầu GSC “Bắt đầu theo dõi” (Start Tracking) để theo dõi lại trong 28 ngày xem vấn đề đó đã được khắc phục hoàn toàn chưa.

Bạn nên sử dụng Google Search Console khi bạn muốn có cái nhìn tổng quan về hiệu suất CWV trên toàn bộ website của mình, đặc biệt là để xác định các vấn đề lớn đang ảnh hưởng đến nhiều trang.

2. Google PageSpeed Insights (PSI)

Google PageSpeed Insights là một công cụ miễn phí khác của Google, cho phép bạn phân tích hiệu suất của MỘT URL cụ thể.

Chức năng chính:

Cung cấp cả dữ liệu Lab và Field: PSI hiển thị cả dữ liệu được thu thập trong môi trường phòng thí nghiệm (từ Lighthouse) và dữ liệu thực tế từ người dùng (từ CrUX). Điều này giúp bạn vừa có cái nhìn “ngay lập tức” về tác động của các thay đổi (lab data), vừa biết được người dùng thực tế đang trải nghiệm ra sao (field data).
Điểm hiệu suất tổng thể: PSI đưa ra một điểm hiệu suất từ 0 đến 100 dựa trên nhiều chỉ số khác nhau, không chỉ riêng CWV.
Đề xuất cải thiện chi tiết: Công cụ này cung cấp danh sách các gợi ý cụ thể để cải thiện tốc độ và trải nghiệm người dùng của trang, kèm theo ước tính thời gian tiết kiệm được. Bạn có thể lọc các gợi ý theo từng chỉ số CWV.

Bạn nên dùng Google PageSpeed Insights khi bạn muốn kiểm tra nhanh hiệu suất của một trang cụ thể sau khi thực hiện thay đổi, hoặc muốn chẩn đoán sâu vấn đề trên một trang cụ thể để tìm nguyên nhân gốc rễ và cách khắc phục.

3. Chrome Lighthouse (tích hợp trong Chrome DevTools)

Chrome Lighthouse là một công cụ mã nguồn mở, tự động hóa để kiểm tra và cải thiện chất lượng website. Nó được tích hợp sẵn trong trình duyệt Chrome (qua Chrome DevTools), rất tiện lợi cho các nhà phát triển.

Chức năng chính:

Đo lường dữ liệu Lab: Lighthouse chủ yếu cung cấp dữ liệu phòng thí nghiệm.
Đánh giá đa chiều: Ngoài hiệu suất (bao gồm CWV), Lighthouse còn đánh giá các khía cạnh khác như khả năng tiếp cận (Accessibility), SEO, và các thực hành tốt nhất (Best Practices).
Không đo trực tiếp INP: Vì là công cụ phòng thí nghiệm không có tương tác người dùng thực, Lighthouse không thể đo trực tiếp INP. Thay vào đó, nó sử dụng Total Blocking Time (TBT) làm chỉ số đại diện (proxy) cho INP. Các cải tiến hiệu suất giúp giảm TBT trong phòng thí nghiệm thường cũng sẽ cải thiện INP trong thực tế.
Chẩn đoán sâu: Cung cấp thông tin chi tiết về các điểm nghẽn hiệu suất, như công việc trên luồng chính (main thread work) hay thời gian thực thi JavaScript.

Dùng Chrome Lighthouse khi bạn là một nhà phát triển và muốn phân tích kỹ thuật chuyên sâu một website cụ thể để tìm ra nguyên nhân chính xác của các vấn đề hiệu suất và nhận các gợi ý để cải thiện code.

Bạn sử dụng Chrome Lighthouse bằng cách mở Chrome DevTools (nhấp chuột phải vào trang và chọn “Inspect” – Kiểm tra), vào tab Lighthouse, chọn “Performance” và chạy báo cáo. Kết quả sẽ hiển thị các tác vụ JavaScript nào đang chiếm dụng luồng chính và gây ra độ trễ.

4. GTmetrix

GTmetrix là một công cụ trực tuyến miễn phí kết hợp dữ liệu từ Lighthouse và CWV, cùng với các phân loại và điểm số bổ sung riêng của họ.

Chức năng chính:

Điểm số dễ hiểu: GTmetrix cung cấp các điểm tổng hợp đơn giản như “Grade” (điểm chữ cái A, B, C…), “Performance” (phần trăm hiệu quả) và “Structure” (điểm cấu trúc).
Biểu đồ thác nước (Waterfall Chart): Đây là một tính năng nổi bật, hiển thị chi tiết thời gian tải của từng thành phần trên website, giúp bạn xác định tài nguyên nào đang làm chậm trang.
Cài đặt kiểm tra: Theo mặc định, GTmetrix có thể chạy kiểm tra mà không bị điều tiết (unthrottled), cho ra kết quả quá lý tưởng. Bạn nên điều chỉnh cài đặt để mô phỏng kết nối thực tế hơn, ví dụ: chọn “LTE connection”.

Dùng GTmetrix khi bạn cần một công cụ thứ hai để kiểm tra và xác nhận kết quả từ các công cụ của Google, hoặc khi bạn muốn có biểu đồ phân tích thời gian tải chi tiết của từng yếu tố trên trang

5. Semrush Site Audit

Semrush Site Audit là một phần của bộ công cụ SEO của Semrush, chuyên về kiểm tra kỹ thuật tổng thể website, bao gồm việc theo dõi và cung cấp các đề xuất cải thiện CWV.

Chức năng chính:

Kiểm tra kỹ thuật toàn diện: Ngoài CWV, công cụ này còn phát hiện nhiều vấn đề kỹ thuật khác trên website của bạn.
Theo dõi lịch sử hiệu suất: Hiển thị trạng thái các trang của bạn theo thời gian, giúp bạn nhìn thấy sự thay đổi và tiến bộ.
Đề xuất hành động: Cung cấp danh sách các đề xuất cụ thể để cải thiện LCP, CLS, và TBT (là chỉ số đại diện cho INP).
Phân tích theo phiên bản: Bạn có thể chọn phân tích phiên bản di động hoặc máy tính của website.

Sử dụng Semrush Site Audit khi bạn muốn có một báo cáo kỹ thuật tổng thể về sức khỏe website của mình, đặc biệt là khi bạn là một SEO chuyên nghiệp hoặc đội ngũ marketing muốn theo dõi và nhận các gợi ý cải thiện CWV một cách có hệ thống.

6. Báo cáo Trải nghiệm Người dùng Chrome (CrUX Report/Dashboard)

CrUX Report là bộ dữ liệu công khai lớn nhất chứa thông tin về trải nghiệm người dùng thực tế trên web, thu thập từ người dùng Chrome.

Chức năng chính:

Truy cập dữ liệu Field: Cung cấp dữ liệu CWV thực tế (field data) cho hàng triệu website.
Dashboard trực quan: Bạn có thể truy cập qua CrUX Dashboard cho Looker Studio, một giao diện trực quan cho phép bạn nhập URL và xem dữ liệu CWV của trang đó và domain của nó.
API cho lập trình: CrUX cũng có API cho phép các nhà phát triển và công cụ khác truy cập dữ liệu một cách tự động, giúp xây dựng các dashboard tùy chỉnh.

Sử dụng CrUX Report khi bạn muốn khám phá dữ liệu người dùng thực cho bất kỳ website nào (của mình hoặc đối thủ), hoặc khi bạn muốn xây dựng các hệ thống báo cáo hiệu suất tự động

Các công cụ khác

Ngoài các công cụ chính của Google và Semrush, còn có một số công cụ khác hữu ích:

AMP Page Experience Guide: Một công cụ kiểm tra trực tiếp toàn diện cho các trang AMP, bao gồm các chỉ số Core Web Vitals, và hiển thị cả dữ liệu kiểm tra trực tiếp lẫn dữ liệu trường.
Screaming Frog SEO Spider: Một công cụ thu thập dữ liệu (crawler) phổ biến trong SEO kỹ thuật. Nó có thể được kết nối với API của PageSpeed Insights để lấy hàng loạt điểm Pass/Fail của CWV cho nhiều trang cùng lúc.
WebPageTest: Cung cấp các bài kiểm tra hiệu suất chuyên sâu và biểu đồ thác nước rất chi tiết, tương tự như GTmetrix, giúp bạn phân tích từng yêu cầu tải tài nguyên.
Google Analytics: Mặc dù không phải là công cụ đo lường CWV trực tiếp, bạn có thể tích hợp dữ liệu CWV vào Google Analytics thông qua các thư viện JavaScript như web-vitals.js để theo dõi chi tiết hiệu suất của từng lượt xem trang

7 vấn đề thường xảy ra đối khi tối ưu Core Web Vitals

1. Nhóm URL và Trạng thái

Google là một cỗ máy khổng lồ xử lý hàng tỷ website khác nhau. Để hiệu quả hơn, thay vì đánh giá từng URL một cách riêng lẻ, Google thường nhóm các URL có trải nghiệm người dùng tương tự nhau lại thành một “nhóm URL”.

Nếu các URL trên website của bạn có cùng cấu trúc, cùng mẫu thiết kế (ví dụ: tất cả các trang sản phẩm, hoặc tất cả các bài viết blog sử dụng cùng một template), thì chúng sẽ có cùng những vấn đề về hiệu suất.

Bằng cách nhóm lại, Google giúp bạn dễ dàng xác định các vấn đề chung và khắc phục chúng một lần là có thể cải thiện cho rất nhiều trang cùng lúc.

Trạng thái của một nhóm URL (là “Tốt”, “Cần cải thiện” hay “Kém”) sẽ được quyết định bởi chỉ số hoạt động kém nhất trong bộ ba CWV (LCP, INP, CLS) cho một loại thiết bị cụ thể (di động hoặc máy tính để bàn).

Ví dụ: Nếu bạn có một nhóm các trang sản phẩm trên website của mình:

Trên thiết bị di động, nhóm trang này có LCP “Tốt” (tải nhanh), nhưng CLS lại “Kém” (các yếu tố bị xê dịch nhiều). Vậy thì, toàn bộ nhóm trang sản phẩm đó trên di động sẽ bị đánh giá là “Kém”. Google luôn lấy chỉ số tệ nhất để cảnh báo bạn.
Tương tự, một nhóm URL có LCP trên di động là “Cần cải thiện” và CLS là “Tốt” thì trạng thái của nó trên di động vẫn sẽ là “Cần cải thiện“.

2. “Không có dữ liệu” No data available

Nếu bạn mở báo cáo Core Web Vitals trong Google Search Console và thấy thông báo “Không có dữ liệu” (No data available), đừng quá lo lắng ngay lập tức. Có hai lý do chính cho điều này:

Website mới: Website của bạn là một tài sản mới được thêm vào Search Console. Mặc dù cơ sở dữ liệu CrUX (Báo cáo trải nghiệm người dùng Chrome) đã thu thập thông tin về URL của bạn, nhưng cần một vài ngày để Search Console phân tích và hiển thị dữ liệu đó.
Không đủ dữ liệu CrUX: Đơn giản là chưa có đủ dữ liệu từ người dùng thực tế truy cập website của bạn (qua trình duyệt Chrome và đồng ý chia sẻ dữ liệu) để Google có thể cung cấp thông tin có ý nghĩa cho loại thiết bị bạn đang xem (máy tính hoặc di động). Điều này thường xảy ra với các website mới hoặc có lượng truy cập rất thấp.

Lưu ý: Các trang bị noindex (tức là bạn đã yêu cầu Google không lập chỉ mục chúng) sẽ không xuất hiện trong báo cáo này vì Google chỉ thu thập dữ liệu từ các trang công khai và đáp ứng tiêu chí lập chỉ mục.

3. Lý do trạng thái trang thay đổi mà không có sự can thiệp

Bạn không hề động chạm gì đến code của website mình, nhưng bỗng dưng một ngày đẹp trời, bạn nhận thấy trạng thái CWV của nhiều trang bị thay đổi (ví dụ, từ “Tốt” sang “Cần cải thiện” hoặc từ “Cần cải thiện” sang “Kém”)? Có thể có một số nguyên nhân nằm ngoài sự kiểm soát trực tiếp của bạn:

Trạng thái sát ngưỡng: Nhiều trang của bạn có điểm CWV chỉ vừa đủ “Tốt” hoặc “Cần cải thiện”. Một sự kiện nhỏ trên toàn website có thể đẩy chúng qua ngưỡng. Ví dụ: Phần lớn các trang trên website của bạn đều có điểm LCP sát ngưỡng “Tốt” (ví dụ 2.4 giây). Bỗng nhiên, vào dịp Tết, lượng truy cập vào website của bạn tăng đột biến. Hoặc nhà cung cấp dịch vụ lưu trữ hình ảnh của bạn gặp sự cố, làm tăng thời gian phản hồi máy chủ. Những yếu tố này có thể làm cho thời gian tải trang trung bình của các trang tăng nhẹ, đủ để đẩy chúng từ “Tốt” sang “Cần cải thiện” hoặc “Kém” trong báo cáo.
Thay đổi lớn về phía người dùng (clients): Một lý do ít phổ biến hơn là sự thay đổi lớn về đặc điểm của người dùng truy cập website của bạn. Chẳng hạn, một bản cập nhật trình duyệt được nhiều người sử dụng có thể ảnh hưởng đến cách website được hiển thị, hoặc có một lượng lớn người dùng mới truy cập trang của bạn từ các mạng internet chậm hơn.

Tuy nhiên, Google không yêu cầu các website phải “hoàn hảo ngay từ đầu và luôn luôn hoàn thiện”. Thay vào đó, bạn hãy dành thời gian để tìm các giải pháp tốt cho website và người dùng của bạn. Việc cải thiện ở bất kỳ thời điểm nào cũng sẽ được phản ánh thông qua dữ liệu người dùng thực tế (real user metrics).

Điều này cũng được John Mueller đề cập tới trong video Google Search News (July ‘23):

4. Xác thực các bản sửa lỗi (Validate fixes)

Khi bạn đã dành thời gian để khắc phục các vấn đề về CWV (ví dụ: tối ưu hóa hình ảnh, giảm JavaScript), bạn có thể thông báo cho Google Search Console để xác nhận rằng bạn đã sửa lỗi.

Cách thực hiện: Trong báo cáo Core Web Vitals của Search Console, bạn sẽ tìm thấy nút “Bắt đầu theo dõi” (Start Tracking) cho một vấn đề cụ thể.

Quá trình theo dõi: Khi bạn nhấp vào nút đó, Google Search Console sẽ bắt đầu một phiên giám sát kéo dài 28 ngày để kiểm tra xem vấn đề đó còn tồn tại trên các URL của bạn hay không.

Không kích hoạt lập chỉ mục lại: Quan trọng là việc này không kích hoạt Google lập chỉ mục lại trang của bạn hay bất kỳ hành vi chủ động nào khác từ Google. Nó chỉ đơn thuần là “khởi động lại đồng hồ” cho giai đoạn giám sát dữ liệu CrUX trong 4 tuần cho website của bạn.

Trạng thái xác thực: Trong suốt quá trình này, bạn sẽ thấy các trạng thái xác thực khác nhau:

Chưa bắt đầu (Not started): Vấn đề chưa từng được yêu cầu xác thực.
Đã bắt đầu (Started): Bạn đã bắt đầu quá trình xác thực và chưa tìm thấy trường hợp nào còn lỗi.
Đang tốt (Looking good): Các trường hợp lỗi được kiểm tra cho đến nay đều đã được sửa.
Đã vượt qua (Passed): Tất cả các URL liên quan đều đã ở trạng thái “Đã vượt qua” (nghĩa là lỗi đã được sửa).
Không áp dụng (N/A): Google tự động nhận ra vấn đề đã được sửa trên tất cả các URL mà không cần bạn yêu cầu xác thực.
Thất bại (Failed): Một hoặc nhiều URL vẫn còn lỗi sau quá trình xác thực.

Trạng thái URL trong quá trình xác thực:

Đang chờ xử lý (Pending): Google đang chờ đủ dữ liệu để xác định xem URL đó còn bị ảnh hưởng bởi lỗi hay không.
Đã vượt qua (Passed): URL không còn bị ảnh hưởng bởi lỗi.
Thất bại (Failed): URL vẫn bị ảnh hưởng bởi lỗi.
Nếu một lỗi biến mất khỏi URL mà không thông qua quá trình xác thực, URL đó sẽ đơn giản là biến mất khỏi danh sách mà không có trạng thái cụ thể.

5. Chia sẻ và xuất dữ liệu báo cáo

Google Search Console cũng cung cấp các tính năng tiện lợi để bạn có thể chia sẻ thông tin về các vấn đề CWV hoặc xuất dữ liệu để phân tích chi tiết hơn:

Chia sẻ báo cáo: Bạn có thể chia sẻ chi tiết về một vấn đề cụ thể (ví dụ: vấn đề LCP kém) bằng cách nhấp vào nút “Chia sẻ”. Liên kết này chỉ cấp quyền truy cập vào trang chi tiết vấn đề đó và lịch sử xác thực của nó, chứ không phải toàn bộ tài sản Search Console của bạn. Điều này rất tiện lợi khi bạn muốn gửi thông tin cho nhà phát triển hoặc một thành viên trong nhóm mà không cần cấp quyền truy cập đầy đủ.
Xuất dữ liệu: Nhiều báo cáo trong Search Console có nút “Xuất” (Export) cho phép bạn tải xuống dữ liệu dạng bảng và biểu đồ. Các giá trị “không khả dụng” hoặc “-” trong báo cáo sẽ được xuất dưới dạng số không (0) trong tệp đã tải xuống.

6. Các chỉ số Web Vitals khác

Bộ ba Core Web Vitals (LCP, INP, CLS) là các chỉ số chính và quan trọng nhất mà Google sử dụng để đánh giá trải nghiệm người dùng. Tuy nhiên, vẫn có những chỉ số Web Vitals khác, được gọi là chỉ số bổ sung hoặc chỉ số proxy, không trực tiếp dùng để xếp hạng nhưng lại cực kỳ hữu ích trong việc chẩn đoán nguyên nhân của các vấn đề CWV.

Dưới đây là một số chỉ số bổ sung quan trọng:

1. First Contentful Paint (FCP)

First Contentful Paint đo lường thời gian từ khi trang bắt đầu tải cho đến khi bất kỳ phần nào của nội dung trang (văn bản, hình ảnh, hoặc các yếu tố không phải màu trắng) được hiển thị trên màn hình.

FCP cho bạn biết website của bạn bắt đầu “hiện hình” nhanh đến mức nào.

First Contentful Paint hữu ích cho việc chẩn đoán các vấn đề của LCP, đặc biệt là các tài nguyên gây chặn hiển thị (render-blocking resources) như CSS hoặc JavaScript quá lớn/không tối ưu. Nếu FCP kém, LCP cũng có khả năng kém.

Ngưỡng “Tốt”: Dưới 2 giây.

2. Time to First Byte (TTFB)

Time to First Byte là thời gian từ khi trình duyệt gửi yêu cầu đến máy chủ cho đến khi nhận được byte dữ liệu đầu tiên từ máy chủ. TTFB phản ánh tốc độ phản hồi của máy chủ.

Hữu ích cho việc chẩn đoán các vấn đề của LCP khi nguyên nhân là do thời gian phản hồi máy chủ chậm.

3. Total Blocking Time (TBT)

Total Blocking Time dùng để đo lường tổng thời gian mà website không thể phản hồi đầu vào của người dùng (như nhấp chuột hoặc gõ phím) do các tác vụ JavaScript dài đang chạy trên luồng chính của trình duyệt.

TBT cho thấy mức độ “bận rộn” của website và nó chặn người dùng tương tác trong bao lâu.

TBT là một chỉ số đo lường trong phòng thí nghiệm (lab metric) và thường được coi là chỉ số proxy (thay thế) cho INP, đặc biệt trong các công cụ như Lighthouse. Các tối ưu hóa giúp cải thiện TBT trong môi trường lab thường cũng sẽ cải thiện INP trong môi trường thực tế.

Ngưỡng “Tốt”: Dưới 300 mili giây.

4. Speed Index (SI)

Speed Index là một chỉ số tổng hợp cho thấy tốc độ trung bình mà nội dung của website hiển thị cho người dùng. Speed Index giúp bạn hình dung mức độ nhanh chóng mà các phần tử trên trang xuất hiện một cách trực quan.

Ngưỡng “Tốt”: Dưới 4.3 giây.

5. Time to Interactive (TTI)

Time to Interactive là lượng thời gian cần để nội dung trên một trang trở nên đầy đủ chức năng và tương tác được. TTI cho biết khi nào người dùng có thể bắt đầu tương tác hoàn toàn với trang mà không bị chậm trễ.

Ngưỡng “Tốt”: Dưới 3.8 giây.

7. Sự thay đổi của Core Web Vitals

Google không ngừng cải tiến các thuật toán và cách đo lường trải nghiệm người dùng. Điều này có nghĩa là, các chỉ số Core Web Vitals hiện tại và ngưỡng đánh giá của chúng có thể thay đổi theo thời gian.

Google có một quy trình công khai và minh bạch cho việc giới thiệu hoặc thay đổi các chỉ số Web Vitals như sau:

Giai đoạn Thử nghiệm (Experimental): Đây là các chỉ số mới đang được Google nghiên cứu và thử nghiệm. Chúng có thể trải qua nhiều thay đổi đáng kể dựa trên phản hồi của cộng đồng và dữ liệu thực tế.
Giai đoạn Đang chờ xử lý (Pending): Khi một chỉ số thử nghiệm đã chứng minh được hiệu quả và nhận đủ phản hồi, nó sẽ được nâng cấp lên trạng thái này. Google sẽ giữ chỉ số ở giai đoạn này tối thiểu 6 tháng để hệ sinh thái web có thời gian thích nghi và chuẩn bị. Đây cũng là lúc Google đưa ra các thông báo và tài liệu hướng dẫn chi tiết.
Giai đoạn Ổn định (Stable): Đây là trạng thái cuối cùng, khi chỉ số trở thành một phần chính thức của Core Web Vitals. Các chỉ số ổn định được hỗ trợ tích cực và sẽ không thay đổi quá một lần mỗi năm. Mọi thay đổi sẽ được thông báo rõ ràng trong tài liệu chính thức.

Minh chứng rõ ràng nhất cho sự thay đổi này là chỉ số Interaction to Next Paint (INP). Ban đầu, Google sử dụng First Input Delay (FID) để đo lường khả năng tương tác của website.

Tuy nhiên, sau một thời gian thử nghiệm và nhận thấy INP cung cấp cái nhìn toàn diện hơn về khả năng phản hồi của trang trong suốt vòng đời của người dùng, Google đã đưa INP qua các giai đoạn thử nghiệm và chờ xử lý.

Cuối cùng, vào ngày 12 tháng 3 năm 2024, INP đã chính thức thay thế FID trở thành chỉ số Core Web Vital chính thức về khả năng tương tác. Điều này cho thấy Google luôn nỗ lực để các chỉ số phản ánh chính xác nhất trải nghiệm thực tế của người dùng.

Kết luận

Bài viết trên đã cung cấp cho bạn một cái nhìn toàn diện về Core Web Vitals, từ định nghĩa, tầm quan trọng, các chỉ số chính, công cụ đo lường đến các phương pháp tối ưu hóa và tác động đến SEO, giúp bạn hiểu rõ và cải thiện hiệu suất website của mình.

Bài viết trên được mình nghiên cứu, phân tích và tổng hợp từ nhiều nguồn uy tín như Google Search Central, Search Console Help, WebDev, Search Engine Land, Ahrefs, Semrush, Backlinko,…. Cùng với hơn 7 năm làm SEO của mình. Nếu bạn còn điều gì thắc mắc thì hãy để lại thông tin ở phần comment để cùng nhau trao đổi nhé!

Nguồn bài viết tham khảo:

Hãy đánh giá nội dung

Nguyễn Thanh Trường

Founder @ SEO Center – nơi mình và team triển khai SEO & CRO giúp website tăng trưởng thật và ra đơn thật. Mình là người chịu trách nhiệm đảm bảo mọi nội dung ở đây đều... có ích thật sự.