Tối Ưu Core Web Vitals: 10 Kỹ Thuật Theo Dữ Liệu Người Dùng Thật

Tối ưu Core Web Vitals bắt đầu từ dữ liệu nào?

Tối ưu Core Web Vitals bắt đầu từ dữ liệu người dùng thật, gọi là field data, lấy từ Chrome UX Report (CrUX). Báo cáo Core Web Vitals trong Search Console và phần dữ liệu thật của PageSpeed Insights đều đọc từ CrUX, tính trong 28 ngày gần nhất ở phân vị 75. Lighthouse chỉ là dữ liệu thử nghiệm.

Tối ưu đúng chỗ đổi được số liệu, tối ưu sai chỗ chỉ đổi được cảm giác. Khóa Học SEO Master đi vào cách phân biệt hai loại.

Trang Web Vitals ghi ngưỡng nên đo ở "the 75th percentile of page loads, segmented across mobile and desktop devices." Nghĩa là 75% lượt tải trang phải đạt ngưỡng, tách riêng di động và máy tính. INP thay cho FID, web.dev ghi "INP is the successor metric to First Input Delay (FID)."

Về thứ hạng, tài liệu Understanding page experience của Google ghi "Core Web Vitals are used by our ranking systems", và cũng ghi không có một tín hiệu trải nghiệm trang duy nhất. Kết quả tốt trong báo cáo "doesn't guarantee that your pages will rank at the top of Google Search results". Trang Chrome UX Report ghi dữ liệu CrUX "is used by Google Search to inform the page experience ranking factor."

Định nghĩa ba chỉ số có ở bài Core Web Vitals là gì. Tốc độ trang nói chung, ngoài ba chỉ số, có ở bài Page Speed.

Sửa theo dữ liệu người dùng thật, kiểm lại bằng dữ liệu thử nghiệm. Đảo ngược hai việc đó dễ sửa nhầm chỗ.

Kỹ thuật 1: Ảnh LCP nên dùng định dạng và cách tải nào?

Ảnh LCP nên dùng WebP hoặc AVIF, nằm sẵn trong HTML, không lazy-load và được gắn fetchpriority="high". Nếu ảnh chỉ được gọi từ CSS hoặc JavaScript, bạn preload nó với độ ưu tiên cao. web.dev ghi không bao giờ lazy-load ảnh LCP, vì việc đó luôn làm trễ lúc tải ảnh.

Bốn việc với ảnh LCP

1. Tìm đúng phần tử LCP: PageSpeed Insights hoặc tab Performance của Chrome DevTools chỉ ra phần tử LCP của từng trang, có thể là ảnh hoặc khối chữ.
2. Đổi sang WebP hoặc AVIF: web.dev ghi hai định dạng này nén tốt hơn định dạng cũ. Giữ bản JPEG hoặc PNG làm dự phòng nếu cần.
3. Bỏ loading="lazy" khỏi ảnh LCP: lazy-load chỉ dành cho ảnh nằm dưới màn hình đầu tiên. Cách dùng đúng có ở bài Lazy Loading là gì.
4. Gắn fetchpriority="high" cho một ảnh: web.dev ghi gắn độ ưu tiên cao cho hơn một hoặc hai ảnh thì không còn giúp giảm LCP.

Trang Optimize Largest Contentful Paint ghi: "Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay". Trang Choose the right image format ghi WebP và AVIF "should be used where possible."

Không có ngưỡng dung lượng ảnh chính thức nào cho LCP. Việc cần làm là ảnh vừa đúng kích thước hiển thị, nén đúng định dạng, và bắt đầu tải sớm. Cách chuyển ảnh sang định dạng mới có ở WebP và AVIF là gì, các kỹ thuật LCP khác có ở LCP và Speed Optimization.

<!-- Ảnh LCP nằm trong HTML -->
<img src="/hero.avif" width="1200" height="630" fetchpriority="high" alt="...">

<!-- Ảnh LCP chỉ có trong CSS: preload -->
<link rel="preload" as="image" href="/hero.webp" type="image/webp" fetchpriority="high">

Ảnh LCP cần ba thứ: nhẹ, nằm sẵn trong HTML, được tải trước. Thiếu một thứ là LCP chậm.

Kỹ thuật 2: Vì sao mọi ảnh cần khai width và height?

Mọi ảnh cần khai width và height để trình duyệt giữ chỗ đúng kích thước trước khi ảnh tải xong, nhờ vậy nội dung bên dưới không bị đẩy xuống. web.dev ghi luôn khai hai thuộc tính này cho ảnh và video, hoặc giữ chỗ bằng CSS aspect-ratio. Đây là cách giảm CLS rẻ nhất.

Trang Optimize Cumulative Layout Shift ghi: "Always include width and height size attributes on your images and video elements. Alternatively, reserve the required space with CSS aspect-ratio or similar." Trình duyệt hiện nay tự tính tỷ lệ từ hai thuộc tính đó, nên ảnh vẫn co giãn theo màn hình.

Trên WordPress, ảnh chèn qua thư viện media thường đã có width và height. Lỗi hay nằm ở ảnh trong page builder, logo, ảnh đại diện tác giả và banner chèn bằng HTML tự viết. Cách tìm phần tử gây xê dịch có ở CLS và Layout Stability.

Ảnh nào cũng khai width và height. Khối nào tải sau cũng được giữ chỗ trước.

Kỹ thuật 3: font-display swap giúp hay hại Core Web Vitals?

font-display: swap giúp chữ hiện sớm, nhưng có thể gây xê dịch bố cục khi web font tải xong và thay font dự phòng. web.dev ghi swap làm chậm hiển thị chữ ít nhất, còn optional mới tránh được xê dịch do đổi font. Chọn giá trị nào tùy web font quan trọng tới đâu với thương hiệu.

Trang Best practices for fonts ghi trình duyệt Chromium và Firefox ẩn chữ tới 3 giây khi web font chưa tải, Safari ẩn cho tới khi font tải xong. Với swap, web.dev dặn "make sure to deliver the font early enough that it does not cause a layout shift."

Cách tôi làm: tự host font, chỉ giữ các kiểu chữ trang thật sự dùng, preload font của tiêu đề và đoạn đầu, rồi dùng swap. Nếu báo cáo vẫn ghi CLS cao vì font, tôi chỉnh font dự phòng bằng size-adjust cho gần kích thước web font, như web.dev gợi ý.

swap không phải công tắc giải quyết mọi thứ. Font phải tới sớm thì swap mới không gây xê dịch.

Kỹ thuật 4: Chia nhỏ long task bằng scheduler.yield thế nào?

Chia nhỏ long task bằng cách chèn await scheduler.yield() giữa các phần việc, để trình duyệt kịp xử lý thao tác của người dùng. web.dev định nghĩa long task là tác vụ chạy quá 50 mili giây trên luồng chính. Long task là nguyên nhân hay gặp của INP kém, vì trình duyệt không phản hồi khi tác vụ đang chạy.

Ba bước xử lý INP kém do long task

1. Tìm tương tác chậm: báo cáo Core Web Vitals chỉ ra nhóm URL có INP kém. Mở trang đó, ghi lại bằng tab Performance khi bấm nút, mở menu, gõ vào form.
2. Tách việc người dùng thấy ra trước: việc cập nhật giao diện chạy trước, việc gửi số liệu, lưu dữ liệu chạy sau lần nhường luồng.
3. Nhường luồng chính có dự phòng: scheduler.yield() chưa có ở mọi trình duyệt, nên kiểm tính năng trước và dùng setTimeout khi không có.

Trang Optimize long tasks ghi: "Any task that takes longer than 50 milliseconds is a long task." Cùng trang đó ghi "scheduler.yield() is not yet supported in all browsers, so a fallback is needed." setTimeout vẫn dùng được, nhưng phần việc sau sẽ xếp cuối hàng đợi.

function nhuong() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((r) => setTimeout(r, 0));
}

async function luuCaiDat() {
  capNhatGiaoDien();
  await nhuong();
  guiSoLieu();
}

Cách đo và sửa INP theo từng giai đoạn của một tương tác có ở INP (Interaction to Next Paint).

Người dùng phải thấy phản hồi trước. Việc nào người dùng không nhìn thấy thì để sau lần nhường luồng.

Kỹ thuật 5: Rút ngắn TTFB bằng cache và CDN ra sao?

Rút ngắn TTFB bằng ba lớp: hosting đủ sức, cache trang HTML ở máy chủ, và CDN đặt bản sao gần người dùng. web.dev ghi phần lớn website nên giữ TTFB từ 0,8 giây trở xuống, như một mốc tham khảo. TTFB không phải chỉ số Core Web Vitals, nhưng nó cộng thẳng vào LCP.

Ba lớp rút ngắn TTFB theo thứ tự

1. Hosting: web.dev đặt hosting lên đầu. Hosting dùng chung thường chậm hơn, ổn với site nhỏ phục vụ tệp tĩnh, không đủ với site có nhiều truy vấn cơ sở dữ liệu.
2. Cache trang ở máy chủ: trang WordPress dựng lại từ PHP và cơ sở dữ liệu mỗi lượt xem nếu không có cache. Plugin cache hoặc cache ở máy chủ web trả HTML dựng sẵn.
3. CDN: máy chủ biên đặt gần người dùng giữ bản sao tài nguyên, rút ngắn quãng đường. Với người đọc ở Việt Nam, chọn CDN có điểm biên gần Việt Nam.

Trang Time to First Byte ghi: "As a rough guide, most sites should strive to have a TTFB of 0.8 seconds or less." Trang Optimize Time to First Byte giải thích CDN dùng "a distributed network of servers that cache resources on servers that are physically closer to your users."

web.dev cũng ghi nên dựa vào dữ liệu thật để theo dõi TTFB, vì chuyển hướng làm TTFB thật dài hơn số đo trong Lighthouse. Cache phía trình duyệt cho lượt xem lại có ở Browser Caching là gì.

Tối ưu ảnh và CSS không bù được máy chủ chậm. Sửa TTFB trước khi sửa phần còn lại của LCP.

Kỹ thuật 6: Trì hoãn JavaScript bên thứ ba thế nào cho đúng?

Trì hoãn JavaScript bên thứ ba bằng async hoặc defer, trừ script cần cho lần hiển thị đầu tiên. web.dev ghi luôn dùng một trong hai thuộc tính này cho script bên thứ ba, và gỡ script không mang lại giá trị rõ ràng. Chat, pixel quảng cáo, video nhúng là ba nhóm hay làm chậm trang nhất.

Trang Efficiently load third-party JavaScript ghi: "Always use async or defer for third-party scripts, unless the script is necessary for the critical rendering path." Nếu máy chủ của bên thứ ba chậm, web.dev gợi ý tự host script, và dùng preconnect hoặc dns-prefetch cho tên miền của họ.

Việc đầu tiên tôi làm là liệt kê mọi script bên thứ ba đang tải, hỏi chủ website từng cái còn dùng không. Script nào không còn ai dùng thì gỡ. Gỡ hẳn một script là cách nhanh nhất để nó thôi ảnh hưởng cả INP lẫn LCP.

Mỗi script bên thứ ba phải trả lời được một câu: nó mang lại gì cho người đọc hay cho việc đo lường.

Kỹ thuật 7: Vùng chạm trên di động cần lớn bao nhiêu?

Vùng chạm trên di động nên rộng khoảng 48 x 48 pixel và cách nhau khoảng 8 pixel. web.dev ghi 48 pixel tương đương khoảng 9 mm, cỡ đầu ngón tay. Lighthouse báo lỗi vùng chạm nhỏ hơn 48 x 48 pixel bị chồng lên vùng khác. Vùng chạm không phải chỉ số Core Web Vitals.

Bốn chỗ vùng chạm hay quá nhỏ

• Link trong đoạn văn đứng sát nhau: hai link cạnh nhau trên một dòng dễ bấm nhầm, tách ra hoặc tăng khoảng cách dòng.
• Biểu tượng mạng xã hội, nút đóng: biểu tượng 24 pixel vẫn đạt nếu thêm padding cho đủ vùng 48 pixel.
• Menu và breadcrumb: chữ nhỏ, các mục sát nhau, nhất là ở footer.
• Nút trong form: ô chọn, nút radio, nút gửi đặt quá gần nhau.

Trang Accessible tap targets ghi: "A minimum recommended touch target size is around 48 device independent pixels". Tài liệu Tap targets are not sized appropriately của Lighthouse ghi: "Tap targets that are 48 px by 48 px never fail the audit." Con số 44 pixel hay gặp trên mạng không có trong tài liệu của web.dev hay Lighthouse.

Google ghi trong tài liệu Page experience rằng ngoài Core Web Vitals, các khía cạnh trải nghiệm khác không trực tiếp giúp xếp hạng cao hơn, nhưng làm website dễ dùng hơn. Tôi sửa vùng chạm cùng đợt với Core Web Vitals vì cùng một lượt kiểm trên di động. Cách đo vùng chạm có ở Tap Target là gì.

Vùng chạm 48 pixel không đổi điểm Core Web Vitals, nhưng giúp người dùng di động bấm đúng nút liên hệ.

Kỹ thuật 8: Bỏ CSS, JS thừa và nhúng CSS quan trọng ra sao?

Bỏ CSS, JS thừa bằng cách tìm mã không dùng trong tab Coverage của Chrome DevTools rồi gỡ hoặc tách theo trang. Nhúng CSS quan trọng là đặt CSS của màn hình đầu thẳng vào HTML, phần còn lại tải sau. Cả hai giúp trình duyệt vẽ trang sớm hơn, nên cải thiện LCP.

Bốn việc theo thứ tự

1. Đo mã thừa: Lighthouse liệt kê stylesheet có CSS không dùng, tab Coverage cho thấy dòng nào được dùng trên trang.
2. Tắt tài nguyên theo trang: plugin form, slider, bản đồ chỉ tải ở trang có dùng. Site page builder thường tải mọi thứ ở mọi trang.
3. Nhúng CSS màn hình đầu: web.dev khuyên giữ phần màn hình đầu dưới 14 KB sau nén để vẽ được trong lượt truyền đầu tiên.
4. Tải phần CSS còn lại sau: phần CSS cho nội dung bên dưới không chặn lần vẽ đầu tiên.

Tài liệu Remove unused CSS của Lighthouse giải thích trình duyệt phải tải và xử lý mọi stylesheet bên ngoài trước khi hiện nội dung. Trang Extract critical CSS ghi: "aim to keep above-the-fold content under 14 KB (compressed)." Cùng trang đó cảnh báo nhúng quá nhiều CSS làm chậm phần HTML còn lại.

Cách gỡ mã không dùng có ở Unused CSS, JavaScript là gì, cách nhúng CSS màn hình đầu có ở Critical CSS là gì. Site WordPress có hướng dẫn riêng ở SEO WordPress #13: Core Web Vitals.

Mã không ai dùng vẫn bắt trình duyệt tải và đọc. Gỡ trước, nhúng CSS quan trọng sau.

Kỹ thuật 9: Slider đầu trang làm chậm LCP và CLS thế nào?

Slider đầu trang làm chậm LCP khi ảnh trong slider là phần tử LCP nhưng được tải bằng JavaScript, và gây CLS khi hiệu ứng chuyển slide không dùng animation composited. web.dev ghi slider làm đúng gần như không ảnh hưởng hiệu năng. Thay slider bằng một ảnh tĩnh là cách làm của tôi khi slider không mang lại chuyển đổi.

Trang Best practices for carousels ghi: "Large, above-the-fold carousels often contain the page's LCP element", và gọi việc dùng JavaScript để bắt đầu tải nội dung slider là lỗi hiệu năng lớn nhất cần tránh. Với slider tự chạy, web.dev ghi animation không composited "has the potential to cause infinite CLS".

Tôi chọn ảnh tĩnh kèm một thông điệp và một nút liên hệ khi số liệu cho thấy ít ai bấm slide thứ hai trở đi. Đó là quyết định về chuyển đổi, đo bằng dữ liệu của chính website. Nếu slider có lý do để giữ, sửa theo bảng trên vẫn đạt được LCP tốt.

Slider không có lỗi tự thân. Slider tải bằng JavaScript và chuyển slide sai cách mới có lỗi.

Kỹ thuật 10: Theo dõi báo cáo Core Web Vitals ra sao?

Theo dõi Core Web Vitals trong Search Console bằng báo cáo Core Web Vitals: xem tách di động và máy tính, mở từng vấn đề, sửa nhóm URL rồi bấm xác thực bản sửa. Số liệu là dữ liệu CrUX của 28 ngày gần nhất, nên kết quả sửa hiện ra chậm. Google theo dõi bản sửa trong một phiên 28 ngày.

Cách đọc báo cáo Core Web Vitals

• Nhóm URL: báo cáo gom các trang giống nhau thành nhóm, mỗi dòng ví dụ đại diện cho một nhóm. Sửa khuôn trang là sửa cả nhóm.
• Trạng thái theo chỉ số kém nhất: nhóm có CLS kém nhưng INP tốt vẫn bị xếp Poor.
• Con số của nhóm: Group LCP là thời gian mà 75% lượt tải trong nhóm đạt hoặc nhanh hơn, tính trong 28 ngày.
• Validate fix: bấm Start Tracking để Google theo dõi 28 ngày. Không còn URL nào gặp lỗi trong 28 ngày thì vấn đề được tính là đã sửa.
• No data available: property mới, hoặc CrUX chưa đủ dữ liệu cho loại thiết bị đó. Khi đó dùng dữ liệu thử nghiệm của PageSpeed Insights để sửa trước.

Trang Core Web Vitals report ghi báo cáo dựa trên "real world usage data (sometimes called field data)" và "The data for the Core Web Vitals report comes from the CrUX report." Trang About PageSpeed Insights ghi dữ liệu thật tính "over the previous 28-day collection period".

Vì cửa sổ 28 ngày, tôi ghi ngày sửa vào nhật ký rồi đợi đủ bốn tuần mới kết luận. Cách đọc các báo cáo khác của công cụ có ở Google Search Console.

Sửa xong hôm nay, báo cáo đổi màu sau vài tuần. Đợi đủ 28 ngày rồi mới đánh giá kỹ thuật nào có tác dụng.

Người làm website hay hỏi gì về tối ưu Core Web Vitals?

Người làm website hay hỏi bốn câu khi tối ưu Core Web Vitals: điểm PageSpeed thấp có ảnh hưởng thứ hạng không, vì sao báo cáo không có dữ liệu, sửa xong bao lâu thì thấy kết quả, và nên sửa chỉ số nào trước. Câu trả lời ngắn cho từng câu nằm ngay bên dưới.

Điểm PageSpeed Insights thấp có làm tụt thứ hạng không?

Điểm hiệu năng từ 0 tới 100 là kết quả thử nghiệm của Lighthouse, Google không ghi đó là tín hiệu xếp hạng. Google ghi Core Web Vitals được hệ thống xếp hạng dùng, với dữ liệu người dùng thật từ CrUX. Google cũng ghi không có một tín hiệu trải nghiệm trang duy nhất, và nội dung liên quan vẫn được ưu tiên.

Vì sao báo cáo Core Web Vitals ghi không có dữ liệu?

Search Console ghi hai lý do: property mới được thêm, hoặc CrUX chưa có đủ dữ liệu cho loại thiết bị đó. CrUX chỉ gồm trang công khai có đủ lượt truy cập để số liệu có ý nghĩa thống kê. Website nhỏ thường rơi vào trường hợp này, khi đó dùng dữ liệu thử nghiệm để sửa.

Sửa xong bao lâu thì báo cáo Core Web Vitals đổi?

Số liệu trong báo cáo là phân vị 75 của 28 ngày gần nhất, nên bản sửa hiện ra dần trong khoảng bốn tuần. Bấm Validate fix thì Google mở phiên theo dõi 28 ngày. Kiểm tra nhanh hơn bằng PageSpeed Insights hoặc Lighthouse ngay sau khi sửa, rồi chờ dữ liệu thật xác nhận.

Nên sửa LCP, INP hay CLS trước?

Tôi sửa chỉ số đang kém ở nhóm URL nhiều lượt truy cập nhất trước, vì báo cáo xếp trạng thái theo chỉ số kém nhất. Nếu cả ba đều kém, tôi sửa TTFB và LCP trước vì chúng thường chung nguyên nhân máy chủ và ảnh, rồi tới CLS, cuối cùng là INP vì cần sửa mã JavaScript.

Nguồn chính thức nào nói về tối ưu Core Web Vitals?

Các ngưỡng và câu trích về Core Web Vitals ở đây lấy từ web.dev, Chrome for Developers, Search Console Help và Google Search Central. Tôi đọc lại toàn bộ ngày 03/10/2026. Một số trang hướng dẫn cũ vẫn đúng về cách làm, nhưng ngưỡng và tên chỉ số nên đối chiếu với trang Web Vitals mới nhất.

Mười sáu tài liệu gốc cho mười kỹ thuật

• Ngưỡng: Web Vitals
• INP: Interaction to Next Paint (INP)
• Thứ hạng: Understanding page experience in Google Search results
• CrUX: Overview of CrUX
• Kỹ thuật 1: Optimize Largest Contentful Paint
• Kỹ thuật 1: Choose the right image format
• Kỹ thuật 2: Optimize Cumulative Layout Shift
• Kỹ thuật 3: Best practices for fonts
• Kỹ thuật 4: Optimize long tasks
• Kỹ thuật 5: Optimize Time to First Byte
• Kỹ thuật 6: Efficiently load third-party JavaScript
• Kỹ thuật 7: Accessible tap targets
• Kỹ thuật 8: Remove unused CSS
• Kỹ thuật 8: Extract critical CSS
• Kỹ thuật 9: Best practices for carousels
• Kỹ thuật 10: Core Web Vitals report

Ngưỡng nào không có trên web.dev hay tài liệu của Google thì chỉ là cách làm của một người, cần ghi rõ như vậy.

Học tối ưu Core Web Vitals trên website thật ở đâu?

Bạn học tối ưu Core Web Vitals ở Khóa Học SEO Cơ Bản nếu cần nền Technical trước, hoặc Mentor SEO 1 kèm 1 nếu muốn sửa ngay trên website đang chạy. Cần người soi website trước khi chọn, Phân tích SEO và GEO là bước đầu, phí được trừ đủ khi đăng ký Mentor sau đó.

Mentor SEO 1 kèm 1 cho đầu ra 01 trang chủ lực và 10 bài hỗ trợ. Sau khóa có 30 ngày rà bài, 3 buổi xem dữ liệu và 6 tháng hỏi đáp. Đăng ký Mentor sau khi làm Phân tích SEO và GEO thì 5.000.000đ phí phân tích được trừ đủ vào học phí.

Trước khi sửa tốc độ, bạn nên chắc Google đang index đúng URL: mười bước kiểm có ở chẩn đoán Technical SEO. Core Web Vitals nằm trong trụ Technical của SQA-200™. Tự chấm nhanh trụ đó bằng chẩn đoán SQA-200™, công cụ tự chấm miễn phí 15 câu, thang 200 điểm. Tốc độ là một phần của trụ TOP-Ready, bậc nền trên Bản đồ DLN.

Chọn được hướng rồi thì Đăng ký học SEO để giữ lịch. Muốn hỏi trước, bạn nhắn Zalo cá nhân của Danh Nolan qua số 03 9999 5885.

Đọc báo cáo trước, sửa đúng nhóm URL, rồi đợi đủ 28 ngày để dữ liệu thật xác nhận.