PageSpeed Insights & Core Web Vitals

PageSpeed Insights là công cụ phổ biến nhất để đánh giá tốc độ website, và điểm số trên thang 100 thường được dùng như kết quả cuối cùng. Thực tế, con số đó chỉ là một lần đo giả lập. Cùng một báo cáo còn có một phần khác, ít được chú ý hơn nhưng gần với trải nghiệm thật hơn: dữ liệu từ người dùng Chrome đã truy cập website.

Bài viết này giải thích cách đọc một báo cáo PageSpeed, ý nghĩa của từng chỉ số, và ba trường hợp thật từ các website Perxel làm, trong đó có một trường hợp điểm số cao nhờ một mẹo mà Perxel ghi rõ ở đây. Phần cuối là cách Perxel tối ưu tốc độ cho WordPress và Next.js.

Một báo cáo PageSpeed có hai phần

Phần trên, "Discover what your real users are experiencing", là field data lấy từ Chrome User Experience Report (CrUX): số đo thật từ những người dùng Chrome đã truy cập trang trong 28 ngày gần nhất, tính ở mức 75% số lượt truy cập. Nếu trang chưa đủ lượt truy cập, PageSpeed lấy dữ liệu của cả domain (Origin). Nếu cả domain cũng chưa đủ, phần này hiện "No Data".

Phần dưới, "Diagnose performance issues", là lab data: Lighthouse tải trang một lần trên một điện thoại giả lập cấu hình thấp (Moto G Power) với mạng Slow 4G, như một lượt truy cập đầu tiên, rồi chấm điểm. Điểm Performance trên thang 100 nằm ở phần này.

Hai phần trả lời hai câu hỏi khác nhau. Lab data cho biết trang có vấn đề gì trong một điều kiện cố định, nên hữu ích khi tìm lỗi và so sánh trước và sau một thay đổi. Field data cho biết người xem thật đã trải nghiệm trang thế nào. Khi trang có dữ liệu CrUX, đây là con số nên xem trước.

Các chỉ số nghĩa là gì

Ba chỉ số đầu là Core Web Vitals. Một trang đạt Core Web Vitals khi cả ba ở mức tốt với 75% lượt truy cập.

• LCP (Largest Contentful Paint): phần nội dung lớn nhất hiện lên sau bao lâu. Tốt là dưới 2,5 giây. Thường là ảnh banner hoặc tiêu đề lớn. LCP chậm thường do ảnh banner tải muộn (lazy load, hoặc chờ script thay ảnh), hoặc tiêu đề chờ JavaScript hay font mới hiện.
• INP (Interaction to Next Paint): trang phản hồi thao tác nhanh đến đâu. Tốt là dưới 200 ms. Chỉ đo được từ người dùng thật. Trong lab, TBT (Total Blocking Time) là chỉ số gần nhất. INP chậm thường do JavaScript chạy quá lâu trên luồng chính.
• CLS (Cumulative Layout Shift): trang bị xê dịch bao nhiêu khi đang tải. Tốt là dưới 0,1. Thường do ảnh không khai báo kích thước, phần tử bị JavaScript dời chỗ sau khi trang đã hiện, hoặc animation thay đổi kích thước hay vị trí bằng width, top thay vì transform.
• FCP, TTFB và Speed Index là các chỉ số phụ. FCP là lúc nội dung đầu tiên hiện ra (tốt là dưới 1,8 giây). TTFB là thời gian chờ byte đầu tiên từ server (tốt là dưới 0,8 giây), phụ thuộc chủ yếu vào hosting và cache. Speed Index đo nội dung lấp đầy màn hình nhanh đến đâu.

Ba trường hợp thật

Ba website dưới đây do Perxel làm, đo cùng ngày 10/10/2026. Mỗi trường hợp cho thấy một kiểu chênh lệch giữa điểm lab và trải nghiệm thật.

Khatra Tile: điểm lab 73, người dùng thật đạt Core Web Vitals

Khatra Tile là website WordPress dùng WPBakery, đã chạy hơn 10 năm. Bản mobile chỉ được 73 điểm trong lab, với LCP 4,7 giây. Nhưng dữ liệu CrUX của cả domain trên mobile đạt Core Web Vitals: LCP 2,2 giây, INP 95 ms, CLS 0,02.

Khatra Tile bản mobile, ngày 10/10/2026: dữ liệu người dùng thật của cả domain đạt Core Web Vitals, trong khi lần đo lab được 73 điểm.

Lab đo một lượt truy cập đầu tiên trên điện thoại cấu hình thấp với mạng chậm. Người xem thật thì dùng nhiều loại máy và mạng, và có cả lượt quay lại với cache của trình duyệt. Vì vậy điểm lab có thể khắt khe hơn trải nghiệm thật. Một điểm 73 không có nghĩa là người xem đang gặp website chậm.

Bản mobile của Khatra vẫn còn chỗ để cải thiện, vì Perxel chưa tập trung tối ưu riêng cho mobile. Cụ thể:

• Ảnh banner chờ script mới hiện. Plugin WebP đang dùng chế độ đặt ảnh giữ chỗ trong HTML rồi thay bằng ảnh thật bằng JavaScript, nên ảnh LCP phải chờ script chạy.
• Quá nhiều ảnh được ưu tiên tải. Mọi slide của banner, cả bản desktop lẫn bản mobile, đều có fetchpriority="high", nên ảnh đầu tiên phải chia băng thông với khoảng 10 ảnh khác.
• TTFB của người dùng thật là 1,3 giây trên mobile. Trang đã có cache trả về sau khoảng 0,1 giây, trang chưa có cache mất khoảng 0,7 giây (đo bằng curl ngày 10/10/2026). Phần còn lại là thời gian kết nối trên mạng di động.

Sundmd: điểm lab 99, nhưng chưa phải trải nghiệm thật

Sundmd là website WordPress mới, dựng bằng NectarBlocks trên Gutenberg. Bản mobile được 99 điểm trong lab, và chưa có dữ liệu CrUX vì website còn mới.

Sundmd bản mobile, ngày 10/10/2026: 99 điểm trong lab, chưa có dữ liệu người dùng thật.

Điểm 99 này có một phần nhờ mẹo. Ở lượt truy cập đầu tiên trong mỗi phiên, Sundmd mở bằng một màn intro: logo thương hiệu trên nền tối trong khoảng 4,5 giây, rồi hai tấm màn trượt ra hai bên để lộ trang. Màn intro là một phần của trải nghiệm thương hiệu nên được giữ nguyên. Trong lab, nó làm điểm giảm mạnh: tấm màn thu hẹp bằng width nên bị tính là layout shift (CLS khoảng 0,18), và tiêu đề chính phải chờ màn intro xong mới hiện (riêng phần chờ hiển thị của LCP là 8,3 giây).

Vì vậy Perxel kiểm tra user agent của request. Khi request đến từ Lighthouse, PageSpeed Insights, WebPageTest hoặc Chrome headless, server trả về trang không có màn intro và tắt animation xuất hiện của tiêu đề. Người xem thật vẫn thấy màn intro như bình thường.

Đoạn code kiểm tra công cụ đo trên Sundmd (rút gọn). Filter cuối cùng rất quan trọng: nếu WP Rocket cache trang không có intro, người xem thật cũng sẽ nhận trang đó.

Mẹo này chỉ thay đổi điểm lab, không thay đổi trải nghiệm thật. Khi Sundmd có đủ lượt truy cập, CrUX sẽ tính cả màn intro, và Perxel dự đoán CLS của người dùng thật sẽ ở mức cần cải thiện (khoảng 0,18). Cách sửa thật là đổi animation của tấm màn từ width sang transform, giữ nguyên hình ảnh:

<!-- Trước: tấm màn thu hẹp chiều rộng, Chrome tính là layout shift -->
<div class="absolute inset-y-0 right-0 w-[60vw] transition-[width] duration-700
            is-page-overlay-hidden:w-0"></div>

<!-- Sau: cùng hình ảnh, tấm màn co lại bằng transform từ mép ngoài -->
<div class="absolute inset-y-0 right-0 w-[60vw] origin-right transition-transform duration-700
            is-page-overlay-hidden:scale-x-0"></div>

Cách sửa này chưa được áp dụng. Perxel sẽ cập nhật bài viết khi Sundmd có dữ liệu CrUX.

Website Perxel: cùng code, 68 và 95 điểm

Website Perxel chạy Next.js và cũng chưa có dữ liệu CrUX. Hai lần đo trên cùng một phiên bản code, cách nhau hơn 13 tiếng, cho 68 và 95 điểm.

Cùng một phiên bản code của trang chủ Perxel, hai lần đo PageSpeed bản mobile: 68 điểm và 95 điểm.

Website Perxel cũng có một chỗ làm điểm lab tốt hơn thực tế: Google Analytics chỉ tải khi người dùng có thao tác đầu tiên, hoặc sau 15 giây nếu không có thao tác nào. Lần đo giả lập không cuộn hay chạm vào trang và kết thúc trước 15 giây, nên không tính phần script này, trong khi người xem thật vẫn tải nó ngay khi cuộn trang.

Đọc kết quả thế nào cho đúng

• Khi có dữ liệu CrUX, xem phần này trước. Như Khatra, một điểm lab trung bình vẫn có thể đi kèm trải nghiệm thật đạt chuẩn.
• Khi chưa có CrUX, lấy trung vị của nhiều lần đo. Một lần đo có thể lệch tới 27 điểm như website Perxel.
• Một điểm lab rất cao chưa chắc là trải nghiệm thật. Hãy mở trang bằng trình duyệt thường và xem người xem thấy gì trong vài giây đầu. CrUX cũng có giới hạn: chỉ tính người dùng Chrome đã đồng ý chia sẻ dữ liệu, và chỉ hiện khi trang có đủ lượt truy cập.

Tối ưu website WordPress

CSS và JavaScript

• Tailwind CSS trong block Gutenberg. Perxel có một workflow riêng để dùng Tailwind CSS trong các block của Gutenberg, như trên Sundmd. Các class được dùng lại giữa các block, nên file CSS cuối cùng nhỏ.
• JavaScript theo từng component. Trên Khatra, mỗi component đăng ký file JavaScript riêng và chỉ enqueue khi component đó được render, nên trang không dùng component nào thì không tải script của nó. Với tương tác thông thường, Perxel viết JavaScript thuần thay vì thêm thư viện.
• Chỉ dùng plugin đã kiểm chứng. Nhiều plugin tải CSS và JavaScript của chúng lên mọi trang, kể cả trang không dùng. Perxel giữ một danh sách plugin an toàn và biết rõ file nào của từng plugin cần giữ hay bỏ.

Hình ảnh

• Chuyển ảnh sang WebP ngay trên server. Perxel Image Optimizer tạo bản WebP cho thư viện ảnh mà không gửi ảnh ra dịch vụ bên ngoài.
• Giới hạn số kích thước ảnh. WordPress tự sinh nhiều kích thước cho mỗi ảnh tải lên. Perxel chỉ giữ các kích thước khớp với breakpoint trong bản thiết kế, để srcset chọn đúng ảnh mà không sinh hàng chục file thừa.
• Ảnh LCP được tải ngay, ưu tiên cao và có sẵn kích thước. Trên Khatra, ảnh banner đầu trang đi qua một hàm riêng:

// Ảnh LCP (banner đầu trang): tải ngay, ưu tiên cao, có width/height để trang không xê dịch
function px_output_lcp_optimized_image($id, $size = 'full', $class = '') {
  $meta = wp_get_attachment_metadata($id);
  return sprintf(
    '<img src="%s" srcset="%s" sizes="%s" width="%d" height="%d" class="%s" alt="%s"
          fetchpriority="high" loading="eager" decoding="async">',
    esc_url(wp_get_attachment_image_url($id, $size)),
    esc_attr(wp_get_attachment_image_srcset($id, $size)),
    esc_attr(wp_get_attachment_image_sizes($id, $size)),
    $meta['width'] ?? 0,
    $meta['height'] ?? 0,
    esc_attr($class),
    esc_attr(get_post_meta($id, '_wp_attachment_image_alt', true))
  );
}

Hàm này chỉ nên dùng cho đúng một ảnh: ảnh đầu tiên của banner, ở bản hiện trên màn hình đó. Như đã nói ở trên, trang chủ Khatra hiện dùng nó cho mọi slide, nên các ảnh tranh nhau băng thông.

Script bên thứ ba

Google Tag Manager, Facebook Pixel hay chat widget không được tải ngay khi mở trang. Trên Khatra, GTM chỉ tải khi người dùng có thao tác đầu tiên, hoặc 3,5 giây sau khi trang tải xong:

// Tải GTM sau thao tác đầu tiên của người dùng, hoặc 3,5 giây sau khi trang tải xong
let loaded = false
function loadGTM() {
  if (loaded) return
  loaded = true
  window.dataLayer = window.dataLayer || []
  window.dataLayer.push({'gtm.start': Date.now(), event: 'gtm.js'})
  const script = document.createElement('script')
  script.async = true
  script.src = 'https://www.googletagmanager.com/gtm.js?id=' + GTM_ID
  document.head.appendChild(script)
}
window.addEventListener('load', () => setTimeout(loadGTM, 3500))
for (const event of ['scroll', 'mousemove', 'touchstart', 'keydown']) {
  window.addEventListener(event, loadGTM, {once: true, passive: true})
}

Thời gian chờ ngắn hay dài là một lựa chọn: chờ ngắn thì ghi nhận được nhiều lượt truy cập ngắn hơn, chờ dài thì script nằm xa thời điểm tải trang hơn. Khatra chờ 3,5 giây, website Perxel chờ 15 giây.

Máy chủ và cache

• Cache ở cả server và WordPress. Perxel kết hợp cache của server (như LiteSpeed trên Khatra) với WP Rocket, để trang được trả về như một bản HTML tĩnh mà không cần chạy PHP hay truy vấn cơ sở dữ liệu. Trên Khatra, trang đã có cache trả về sau khoảng 0,1 giây, trang chưa có cache mất khoảng 0,7 giây.
• Xóa cache đúng trang khi nội dung thay đổi. Khi người quản lý sửa hoặc thêm nội dung, cache của WP Rocket và của server được xóa cho trang đó và các trang liên quan, nên nội dung mới hiện ngay.
• Chạy được trên hosting phổ thông. Codebase custom gọn giúp website chạy tốt trên Nginx, Apache hay LiteSpeed, không bắt buộc một nhà cung cấp cụ thể.

Tối ưu website Next.js

Next.js có cách tối ưu khác hẳn WordPress: kiểm soát JavaScript mỗi trang tải, prefetch, font, và nếu chạy trên Cloudflare Workers thì cả cách server trả trang tĩnh. Perxel ghi lại toàn bộ cách làm và số đo trong bài Tối ưu tốc độ website Next.js.

Hai dự án Next.js khác của Perxel, Atlas Robotics và Foldables, được 84 và 92 điểm bản desktop ở lần đo dưới đây.

PageSpeed Insights của Atlas Robotics, bản desktop.

PageSpeed Insights của Foldables, bản desktop.

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

Điểm lab thấp nhưng dữ liệu người dùng thật đạt thì có cần sửa không?

Nên xem lab chỉ ra vấn đề gì trước khi quyết định. Với Khatra, ảnh banner chờ script và quá nhiều ảnh ưu tiên là những lỗi thật, sửa sẽ giúp người xem trên máy yếu và mạng chậm. Nhưng không cần vội vì con số 73, vì phần lớn người xem đang có trải nghiệm đạt chuẩn.

Vì sao Perxel không dùng mẹo user agent cho mọi website?

Vì nó không làm website nhanh hơn với ai cả. Trên Sundmd, mẹo này chỉ dùng để màn intro (một lựa chọn thiết kế có chủ đích) không che các vấn đề khác trong báo cáo lab. Dữ liệu CrUX vẫn tính đầy đủ trải nghiệm thật, và cách sửa đúng là đổi animation sang transform.

Ngoài Performance, điểm SEO trong báo cáo đo những gì?

Điểm SEO kiểm tra các lỗi kỹ thuật cơ bản: trang có cho Google lập chỉ mục không, có tiêu đề và mô tả không, đường dẫn canonical và hreflang có đúng không, ảnh có alt text và link có chữ rõ nghĩa không. Khác với Performance, điểm này không phụ thuộc vào máy đo hay tốc độ mạng, nên website làm đúng sẽ giữ được điểm tối đa ở mọi lần đo.

Kết quả PageSpeed Insights bản mobile của năm website do Perxel lập trình, đo ngày 13/10/2026.

Điểm tối đa chưa có nghĩa trang sẽ lên top Google. Cấu trúc trang theo từ khóa và dữ liệu cho các công cụ AI là phần việc tiếp theo, được trình bày tại SEO và GEO cho website.

Website mới chưa có dữ liệu CrUX thì nên xem gì?

Lấy trung vị của nhiều lần đo lab, và xem từng chỉ số thay vì chỉ xem điểm tổng. Search Console cũng hiện báo cáo Core Web Vitals khi website bắt đầu có đủ dữ liệu.

Footnotes

1. Google PageSpeed Insights
2. Google: About PageSpeed Insights
3. web.dev: Web Vitals
4. WP Rocket