SEO WordPress #13: Core Web Vitals, cách đo và tối ưu đúng

1. Core Web Vitals là gì và đo điều gì?

Core Web Vitals là ba metric trải nghiệm người dùng thực, đại diện cho tốc độ tải nội dung chính, khả năng phản hồi và độ ổn định thị giác. LCP trả lời nội dung lớn nhất xuất hiện nhanh đến đâu. INP trả lời phần lớn tương tác phản hồi nhanh đến đâu. CLS trả lời bố cục có dịch chuyển ngoài dự kiến hay không.

Tài liệu Web Vitals xác định bộ ba hiện hành là LCP, INP và CLS. Mỗi metric có ngưỡng riêng và phải được đánh giá tại phân vị 75, tách mobile với desktop. Bộ metric có thể thay đổi theo thời gian, vì vậy checklist kỹ thuật cần bám tài liệu hiện hành thay vì ảnh chụp hoặc giáo trình cũ.

Bản đầy đủ của mục này có thêm: bảng 3 dòng (cột: Metric, Khía cạnh trải nghiệm, Câu hỏi chẩn đoán). Xem bản đầy đủ

Core Web Vitals không đo trực tiếp chất lượng nội dung, độ chính xác, khả năng crawl hay chuyển đổi. Google Search Central cũng nói kết quả Core Web Vitals tốt không bảo đảm vị trí cao. Hãy xem đây là một lớp trong trải nghiệm trang, không phải điểm SEO tổng hợp.

2. Bảng ngưỡng LCP, INP và CLS tại phân vị 75

Ba ngưỡng Tốt là LCP ≤ 2,5 giây, INP ≤ 200ms và CLS ≤ 0,1. Vùng Cần cải thiện kết thúc tại 4 giây với LCP, 500ms với INP và 0,25 với CLS. Giá trị cao hơn các mốc này thuộc mức Kém.

Bản đầy đủ của mục này có thêm: bảng 3 dòng (cột: Metric, Tốt, Cần cải thiện, Kém, Phân vị). Xem bản đầy đủ

Các ngưỡng này được giải thích trong tài liệu cách xác định ngưỡng Core Web Vitals. Phân vị 75 giúp đánh giá phần lớn lượt truy cập mà không để một số ít ngoại lệ cực đoan chi phối kết quả.

Không làm tròn theo hướng có lợi. LCP 2,51 giây đã nằm ngoài mức Tốt; INP 205ms cũng vậy. Dashboard có thể hiển thị số tròn để dễ đọc, nhưng dữ liệu gốc và điều kiện phân loại phải được giữ nguyên.

3. Tiêu chí 94: LCP, Largest Contentful Paint

LCP không quá 2,5 giây là Tốt, trên 2,5 đến 4 giây là Cần cải thiện và trên 4 giây là Kém, được đánh giá ở phân vị 75. LCP đánh dấu thời điểm phần tử nội dung lớn nhất trong viewport hoàn tất hiển thị, thường là ảnh hero, poster video, ảnh bài viết hoặc một khối chữ lớn.

LCP không chỉ là thời gian tải file ảnh. Nó gồm nhiều chặng: phản hồi tài liệu HTML, phát hiện tài nguyên, thời gian chờ tải và thời gian render. Vì vậy, nén ảnh có thể chưa đủ nếu TTFB cao, ảnh bị phát hiện muộn trong CSS, ảnh hero bị lazy-load hoặc main thread bận khiến trình duyệt chưa thể vẽ.

Bản đầy đủ của mục này có thêm: bảng 4 dòng (cột: Chặng LCP, Câu hỏi cần kiểm). Xem bản đầy đủ

Trọng số: Bắt buộc. Công cụ: Core Web Vitals Checker của Novaverb, PageSpeed Insights, CrUX và Google Search Console. Hãy lưu cả giá trị field, phần tử LCP và bốn chặng thời gian trước khi chọn cách sửa.

4. Cách chẩn đoán và tối ưu LCP trên WordPress

Tối ưu LCP bắt đầu bằng việc xác định đúng phần tử LCP trên từng template, không bắt đầu bằng cài thêm plugin cache. Trang chủ có thể dùng ảnh hero, bài viết dùng ảnh đại diện, trang sản phẩm dùng gallery, còn landing page có thể dùng khối chữ với web font.

Bản đầy đủ của mục này có thêm: danh sách 12 dòng. Xem bản đầy đủ

Một thay đổi đúng phải giảm chặng tương ứng mà không làm ảnh mờ, mất nội dung hoặc tăng CLS. Nếu ảnh đã nhẹ nhưng render delay vẫn cao, tiếp tục nén ảnh sẽ tạo ít tác động.

5. Tiêu chí 95: INP, Interaction to Next Paint

INP không quá 200ms là Tốt, trên 200 đến 500ms là Cần cải thiện và trên 500ms là Kém. INP quan sát độ trễ của các tương tác click, chạm và bàn phím trong vòng đời trang, rồi chọn một giá trị đại diện cho khả năng phản hồi tổng thể.

INP đã thay FID làm Core Web Vital ổn định trong năm 2024. FID chỉ đo độ trễ của lần tương tác đầu tiên trước khi event handler bắt đầu; INP bao quát tương tác trong suốt phiên và tính cả input delay, thời gian xử lý lẫn presentation delay. Vì vậy, site từng đạt FID vẫn có thể gặp INP kém.

Bản đầy đủ của mục này có thêm: bảng 3 dòng (cột: Thành phần INP, Nguyên nhân thường gặp). Xem bản đầy đủ

Trọng số: Bắt buộc. Công cụ: Core Web Vitals Checker của Novaverb, PageSpeed Insights, CrUX và Google Search Console. Cần ghi tương tác cụ thể, target element và ba thành phần độ trễ để biến INP thành đầu việc.

6. Cách tìm và sửa tương tác gây INP kém

Muốn sửa INP, cần biết người dùng đã tương tác với phần tử nào và main thread làm gì trong khoảng phản hồi. Một con số INP cấp origin không chỉ ra nút, plugin hay đoạn code. RUM có attribution và DevTools Performance giúp nối metric với hành vi thật.

Trên WordPress, nguồn phổ biến gồm menu mobile, popup, bộ lọc sản phẩm, form, trình dựng trang, slider, chat, analytics, quảng cáo và plugin gửi JavaScript trên mọi URL. Không mặc định rằng JavaScript của theme luôn là nguyên nhân; script bên thứ ba hoặc callback của tag manager cũng có thể tạo long task.

Bản đầy đủ của mục này có thêm: danh sách 7 dòng. Xem bản đầy đủ

Đừng thay INP bằng Total Blocking Time. TBT là metric lab hữu ích để tìm JavaScript chặn main thread trong lúc tải, nhưng không đo đầy đủ tương tác thật trong suốt phiên. Hai metric có thể liên quan nhưng không đồng nhất.

7. Tiêu chí 96: CLS, Cumulative Layout Shift

CLS không quá 0,1 là Tốt, trên 0,1 đến 0,25 là Cần cải thiện và trên 0,25 là Kém, được đánh giá ở phân vị 75. CLS cộng điểm các dịch chuyển bố cục ngoài dự kiến trong các session window, phản ánh mức độ nội dung visible thay đổi vị trí khi người dùng không chủ động gây ra.

CLS không có đơn vị thời gian. Một phần tử di chuyển càng xa và ảnh hưởng vùng viewport càng lớn thì điểm càng cao. Dịch chuyển sau thao tác người dùng có thể được loại trong một khoảng nhất định, nhưng nội dung chèn muộn, font đổi kích thước hoặc quảng cáo không giữ chỗ thường gây CLS thật.

Bản đầy đủ của mục này có thêm: danh sách 6 dòng. Xem bản đầy đủ

Trọng số: Bắt buộc. Công cụ: Core Web Vitals Checker của Novaverb, PageSpeed Insights, CrUX và Google Search Console. Cần lưu phần tử dịch chuyển, phần tử gây dịch chuyển và trạng thái giao diện khi lỗi xuất hiện.

8. Cách chẩn đoán và tối ưu CLS trên WordPress

Sửa CLS bằng cách dành sẵn không gian và kiểm soát thời điểm chèn nội dung, không phải khóa mọi chiều cao bằng một con số cố định. Kích thước cố định sai có thể tạo khoảng trắng hoặc cắt nội dung trên responsive.

Đầu tiên, bật track Layout Shifts trong DevTools Performance. Xem từng cluster, điểm shift và các node bị ảnh hưởng. Sau đó kiểm các trạng thái mà lab thường bỏ sót: banner consent lần đầu, menu mở, slider đổi slide, font chưa cache, quảng cáo có fill hoặc không fill, và nội dung sau khi người dùng cuộn.

Bản đầy đủ của mục này có thêm: bảng 5 dòng (cột: Nguồn CLS, Cách xử lý ưu tiên). Xem bản đầy đủ

Sau khi sửa, kiểm mobile và desktop ở viewport thật. Một khối giữ chỗ đúng trên desktop có thể quá cao trên mobile. Đồng thời kiểm CLS field vì dịch chuyển xảy ra sau tương tác hoặc sau cuộn không phải lúc nào cũng được một lab run ngắn ghi nhận.

9. Tiêu chí 97: TTFB hỗ trợ LCP

TTFB không quá 0,8 giây là hướng dẫn thực dụng của web.dev, nhưng TTFB không thuộc ba Core Web Vitals. TTFB đo từ lúc bắt đầu điều hướng đến khi byte đầu tiên của phản hồi đến, bao gồm redirect, DNS, kết nối, xử lý máy chủ và độ trễ mạng tùy công cụ.

Tài liệu Time to First Byte xem 0,8 giây là ngưỡng nên hướng tới cho phần lớn website. Đây là metric chẩn đoán quan trọng vì HTML đến muộn sẽ đẩy lùi thời điểm trình duyệt phát hiện ảnh, CSS, font và nội dung LCP.

Bản đầy đủ của mục này có thêm: danh sách 6 dòng. Xem bản đầy đủ

Trọng số: Quan trọng. Công cụ: Server Response Time Checker của Novaverb, WebPageTest và Chrome DevTools. Hãy dùng TTFB để giải thích một phần LCP, không dùng nó thay cho kết quả LCP.

10. Tiêu chí 98: Dữ liệu thực ở phân vị 75

Phân vị 75 là giá trị mà 75% lượt quan sát đạt bằng hoặc thấp hơn; ít nhất ba phần tư trải nghiệm phải nằm trong ngưỡng Tốt để metric được phân loại Tốt. Đây không phải trung bình cộng và cũng không phải chọn 75% mẫu đẹp.

Ví dụ, 100 lượt tải có LCP được sắp từ nhanh đến chậm. Giá trị ở vị trí phân vị 75 là 2,4 giây thì LCP Tốt, dù 25 lượt còn lại có thể chậm hơn. Nếu phân vị 75 là 2,8 giây, metric thuộc Cần cải thiện dù trung bình toàn bộ có thể thấp hơn 2,5 giây.

Bản đầy đủ của mục này có thêm: bảng 4 dòng (cột: Cách tổng hợp, Ý nghĩa, Có dùng để pass CWV?). Xem bản đầy đủ

Trọng số: Bắt buộc. Công cụ: Core Web Vitals Checker của Novaverb, CrUX, PageSpeed Insights và Google Search Console. Cần giữ phân phối theo thiết bị, quốc gia và template nếu hệ RUM có đủ mẫu.

11. Tiêu chí 99: Đạt đồng thời cả ba chỉ số

Trang hoặc nhóm URL chỉ pass Core Web Vitals khi LCP, INP và CLS đều ở mức Tốt tại phân vị 75. Không lấy trung bình ba metric và không dùng một chỉ số rất nhanh để bù cho chỉ số Kém.

Ví dụ, LCP 2,1 giây và CLS 0,05 đều Tốt nhưng INP 280ms thuộc Cần cải thiện. Kết quả tổng thể chưa pass. Search Console cũng gán trạng thái nhóm URL theo metric kém nhất, nên đội ngũ cần ưu tiên điểm nghẽn thay vì báo cáo tỷ lệ trung bình.

Bản đầy đủ của mục này có thêm: bảng 4 dòng (cột: LCP, INP, CLS, Kết luận). Xem bản đầy đủ

Trọng số: Bắt buộc. Công cụ: Core Web Vitals Checker của Novaverb, PageSpeed Insights và Google Search Console. Dashboard nên hiển thị từng metric và trạng thái tổng theo metric yếu nhất.

12. Tiêu chí 100: Phân biệt Field Data và Lab Data

CrUX và Search Console phản ánh trải nghiệm người dùng Chrome đủ điều kiện; Lighthouse tạo phép đo lab có kiểm soát để chẩn đoán. Hai nguồn bổ sung cho nhau nhưng không thể hoán đổi.

Bản đầy đủ của mục này có thêm: bảng 5 dòng (cột: Tiêu chí, Field Data, Lab Data). Xem bản đầy đủ

Khi field xấu nhưng lab tốt, kiểm thiết bị yếu, mạng thật, cache, trạng thái đăng nhập, consent, quảng cáo và tương tác sau tải. Khi lab xấu nhưng field tốt, cấu hình lab có thể nặng hơn tập người dùng chính hoặc trang đang được cache tốt trong thực tế. Không bỏ nguồn trái với kỳ vọng; hãy tìm lý do chênh lệch.

Trọng số: Bắt buộc. Công cụ: PageSpeed Checker của Novaverb, CrUX, Lighthouse và Chrome DevTools. Điểm Lighthouse hỗ trợ điều tra, không thay kết quả Field Data.

13. Tiêu chí 101: Tách Mobile và Desktop

Core Web Vitals phải được đọc riêng cho mobile và desktop vì thiết bị, mạng, viewport và hành vi khác nhau. Gộp hai nhóm có thể che một vấn đề nghiêm trọng trên thiết bị chiếm phần lớn traffic.

Search Console tách báo cáo mobile và desktop. CrUX cũng cung cấp phân phối theo form factor khi đủ dữ liệu. Một trang có mobile LCP 3,2 giây và desktop LCP 1,7 giây không thể được báo cáo chung là khoảng 2,4 giây rồi kết luận Tốt.

Bản đầy đủ của mục này có thêm: danh sách 5 dòng. Xem bản đầy đủ

Trọng số: Quan trọng. Công cụ: Core Web Vitals Checker của Novaverb, PageSpeed Insights và CrUX API. Mỗi ticket cần ghi thiết bị bị ảnh hưởng và thiết bị đối chứng.

14. Tiêu chí 102: Theo dõi cửa sổ CrUX 28 ngày

CrUX trong PageSpeed Insights tổng hợp 28 ngày gần nhất và cập nhật hằng ngày, nên thay đổi kỹ thuật không thể phản ánh đầy đủ ngay sau deploy. Mỗi ngày mới đi vào cửa sổ sẽ thay một ngày cũ, tạo chuyển động dần thay vì đổi trạng thái tức thì.

Tài liệu quy trình Core Web Vitals với công cụ Google mô tả dữ liệu PSI ở phân vị 75 trong 28 ngày. Search Console cũng dùng dữ liệu thực tế và nhóm URL, vì vậy quá trình xác thực cần thời gian thu thập đủ lượt truy cập.

Bản đầy đủ của mục này có thêm: bảng 4 dòng (cột: Thời điểm, Nguồn nên xem, Câu hỏi). Xem bản đầy đủ

Trọng số: Quan trọng. Công cụ: Core Web Vitals Checker của Novaverb, CrUX API, CrUX History API và Google Search Console. Hãy ghi mốc deploy lên dashboard để không nhầm dữ liệu trước sửa với dữ liệu sau sửa.

15. Cách đọc nhóm URL trong Google Search Console

Báo cáo Core Web Vitals trong Search Console dùng nhóm URL tương tự để giúp tìm vấn đề theo mẫu trang, không phải danh sách đo chính xác mọi URL. Một URL ví dụ đại diện cho nhiều trang có đặc điểm và hành vi gần nhau.

Tài liệu Core Web Vitals report cho biết trạng thái nhóm dựa trên metric kém nhất và dữ liệu được tách mobile, desktop. Số liệu nhóm trong Search Console có thể khác PageSpeed Insights của một URL cụ thể do cách nhóm và mức đủ dữ liệu.

Bản đầy đủ của mục này có thêm: danh sách 7 dòng. Xem bản đầy đủ

Không sửa riêng một URL mẫu rồi xem toàn nhóm đã xong. Nếu nhóm chứa nhiều biến thể, chia mẫu theo hero, plugin, loại nội dung, trạng thái cache và hành trình tương tác để tìm nguyên nhân thật.

16. Tiêu chí 103: Bổ sung RUM khi thiếu dữ liệu CrUX

URL mới hoặc ít traffic có thể không đủ Field Data cấp URL; RUM giúp thu thập metric từ chính người dùng của website theo template và hành trình. CrUX có ngưỡng đủ mẫu và chỉ gồm tập người dùng Chrome đủ điều kiện, nên không phải mọi URL công khai đều xuất hiện.

Thư viện chính thức web-vitals đo LCP, INP, CLS cùng metric hỗ trợ và có bản attribution để bổ sung chi tiết chẩn đoán. Có thể gửi dữ liệu tới endpoint riêng, nền tảng RUM hoặc sự kiện tùy chỉnh của GA4, nhưng cần kiểm sampling, consent và chi phí dữ liệu.

Bản đầy đủ của mục này có thêm: danh sách 7 dòng. Xem bản đầy đủ

Trọng số: Nên có. Công cụ: thư viện web-vitals, GA4 Custom Events hoặc nền tảng RUM. RUM là lớp bổ sung, không phải cách làm cho CrUX đổi ngay.

17. Mẫu triển khai web-vitals và thiết kế dữ liệu RUM

Một hệ RUM hữu ích phải giữ đủ ngữ cảnh để chuyển metric thành quyết định, nhưng không thu thập dữ liệu vượt nhu cầu. Chỉ gửi tên và giá trị metric sẽ cho dashboard đẹp nhưng khó tìm nguyên nhân.

Bản đầy đủ của mục này có thêm: bảng 6 dòng (cột: Chiều dữ liệu, Mục đích), mẫu để chép. Xem bản đầy đủ

Đoạn mã chỉ minh họa cấu trúc. Endpoint cần xác thực payload, giới hạn kích thước, loại bỏ dữ liệu nhạy cảm và tuân thủ consent. Với ứng dụng chuyển trang mềm, cần kiểm phiên bản thư viện và cách đo soft navigation thay vì gọi các hàm đo nhiều lần tùy ý.

Giữ dữ liệu thô đủ lâu để tính phân vị, nhưng đặt chính sách lưu trữ rõ ràng. Dashboard nên có p50, p75, p95, tỷ lệ Tốt và số mẫu để tránh kết luận từ tập quá nhỏ.

18. Quy trình kiểm tra Core Web Vitals từ tiêu chí 94 đến 103

Quy trình tốt đi từ phạm vi, field data, phân vị, lab trace, nguyên nhân, thay đổi đến xác nhận sau triển khai. Không cài nhiều plugin cùng lúc rồi chờ Search Console chuyển màu.

Bản đầy đủ của mục này có thêm: bảng 10 dòng (cột: Tiêu chí, Điều kiện đạt, Trọng số), danh sách 10 dòng. Xem bản đầy đủ

Điểm dừng là khi field đạt mục tiêu, lab không có regression, chức năng ổn định và dữ liệu đủ để kết luận. Nếu chưa đủ 28 ngày, báo trạng thái đang theo dõi thay vì tuyên bố đã pass.

19. Công cụ, tài liệu và lộ trình học tiếp

Dùng công cụ nhanh để sàng lọc, sau đó quay về báo cáo gốc và DevTools để xác nhận metric, phần tử cùng tài nguyên. Không tối ưu chỉ từ một màu hoặc tên audit.

Công cụ kiểm tra nhanh

• Core Web Vitals Checker của Novaverb: kiểm nhanh LCP, INP và CLS theo URL.
• PageSpeed Checker của Novaverb: xem dữ liệu hiệu năng và nhóm cảnh báo.
• Server Response Time Checker của Novaverb: kiểm lớp phản hồi máy chủ hỗ trợ chẩn đoán TTFB.

Tài liệu và công cụ gốc

• Google PageSpeed Insights
• Web Vitals
• Core Web Vitals thresholds
• CrUX methodology
• Search Console Core Web Vitals report
• Thư viện web-vitals
• Google Search Central về trải nghiệm trang

Đọc tiếp SEO WordPress #14 về điểm PageSpeed để hiểu cách chạy nhiều lần, dùng trung vị và đặt performance budget; sau đó xem SEO WordPress #15 về hình ảnh và code để xử lý các nguyên nhân tải và main thread phổ biến.

Nếu cần học theo lộ trình trên website thật, có thể xem chương trình đào tạo SEO, trang tổng hợp khóa học SEO và nội dung chuyên sâu của khóa học SEO Master. Các trang trình bày phạm vi, đầu ra và cách học để người đọc tự đối chiếu nhu cầu.

Chuỗi thực hành: đo field, xác định p75, tái hiện bằng lab, sửa đúng nguyên nhân, kiểm RUM và xác nhận lại sau đủ cửa sổ.

20. Câu hỏi thường gặp và kết luận

Phần hỏi đáp sau chốt các nhầm lẫn thường gặp về Core Web Vitals trên WordPress. Mỗi câu trả lời phân biệt ngưỡng, nguồn dữ liệu và phạm vi kết luận để người đọc có thể trích riêng mà không mất ngữ cảnh.

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

Bộ chỉ số hiện hành gồm LCP đo tốc độ tải nội dung chính, INP đo khả năng phản hồi và CLS đo độ ổn định thị giác. FID không còn là Core Web Vital và đã được INP thay thế.

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

Tại phân vị 75, LCP cần không quá 2,5 giây, INP không quá 200ms và CLS không quá 0,1. Cả ba phải đồng thời đạt ngưỡng Tốt.

Điểm PageSpeed 100 có nghĩa Core Web Vitals đã pass không?

Không. Điểm PageSpeed là kết quả lab của một lần hoặc tập lần đo; Core Web Vitals pass dựa trên field data ở phân vị 75 cho LCP, INP và CLS.

Vì sao sửa xong nhưng Search Console chưa đổi trạng thái?

Dữ liệu thực dùng cửa sổ tổng hợp và cần đủ mẫu. CrUX phản ánh 28 ngày gần nhất nên tác động mới đi vào dần; Search Console còn nhóm các URL tương tự và có quy trình xác thực riêng.

TTFB có phải Core Web Vital không?

Không. TTFB là metric chẩn đoán hỗ trợ tải trang và LCP. Web.dev đưa ra hướng dẫn thực dụng là không quá 0,8 giây cho phần lớn website.

URL không có dữ liệu CrUX thì kiểm bằng cách nào?

Dùng lab để chẩn đoán, xem dữ liệu origin với nhãn phạm vi rõ ràng và triển khai RUM bằng thư viện web-vitals hoặc nền tảng phù hợp để thu thập dữ liệu theo template.

Core Web Vitals tốt có giúp lên top Google không?

Core Web Vitals tốt hỗ trợ trải nghiệm trang, nhưng không bảo đảm thứ hạng. Google vẫn xem mức độ hữu ích và liên quan của nội dung cùng nhiều tín hiệu khác.

SEO WordPress ở lớp Core Web Vitals không phải cuộc đua làm đẹp một báo cáo. Hãy đánh giá LCP, INP và CLS riêng tại p75, tách mobile với desktop, dùng field để kết luận, lab để tìm nguyên nhân và RUM để quan sát phần CrUX chưa cho thấy. Khi mỗi thay đổi được nối với metric, template, release và dữ liệu sau triển khai, đội ngũ mới biết website thực sự nhanh hơn ở đâu và với ai.