KIếN THứC WEBSITE › PERFORMANCE

PageSpeed Insights hướng dẫn — 5 bước dùng PSI đo CWV

PageSpeed Insights hướng dẫn — 5 bước dùng PSI đo CWV 2026

PageSpeed Insights (PSI) là công cụ miễn phí của Google đo Core Web Vitals từ dữ liệu lab (Lighthouse) và dữ liệu thực tế (CrUX), kèm gợi ý fix cụ thể. Bài hướng dẫn 5 bước dùng PSI: chạy test, đọc điểm số, audit Opportunities, Diagnostics, và quy trình fix theo độ ưu tiên cho shop WordPress 2026.

PSI là gì — 2 loại dữ liệu

PageSpeed Insights — PSI là gì — 2 loại dữ liệu
PSI là gì — 2 loại dữ liệu

PSI miễn phí, không cần xác thực, chạy tại pagespeed.web.dev. Công cụ trả về 2 loại: dữ liệu thực tế CrUX 28 ngày (liên quan xếp hạng) và dữ liệu lab Lighthouse một lần chạy (phục vụ debug).

PSI tách 4 tab: Mobile/Desktop × Origin/URL — tổng 4 góc nhìn cho một lần test.

Dữ liệu thực tế (CrUX)

Dữ liệu thực tế lấy từ phân vị thứ 75 của người dùng Chrome thật trong 28 ngày. Đây là dữ liệu Google dùng làm tín hiệu xếp hạng tìm kiếm.

  • 3 chỉ số CWV: LCP, INP, CLS — kèm badge pass/fail.
  • Chỉ số phụ: TTFB, FCP.
  • “No data”: site mới hoặc lượng truy cập Chrome dưới ngưỡng.

Dữ liệu lab (Lighthouse)

Dữ liệu lab là kết quả một lần chạy mô phỏng Slow 4G và thiết bị mobile tầm trung. Phục vụ debug và so sánh trước/sau từng fix.

  • Điểm 0-100: chỉ dành cho dữ liệu lab, có trọng số theo từng chỉ số.
  • Xếp hạng không dùng điểm này: Google chỉ dùng pass/fail từng chỉ số CrUX.
  • Độ biến động: ±10-30 điểm giữa các lần chạy — cần chạy nhiều lần lấy trung vị.

Khi nào dùng tab nào?

Tab “Origin” cho thấy tổng hợp toàn tên miền. Tab “URL” cho thấy chỉ trang cụ thể đang test.

Dùng Origin để đánh giá tình trạng tổng thể. Dùng URL để debug một trang cụ thể như landing page hay trang sản phẩm quan trọng.

Bước 1 — Chạy PSI test

Bước 1 — Chạy PSI test
Sơ đồ minh hoạ — Bước 1 — Chạy PSI test

Nên chạy PSI sau mỗi thay đổi lớn về nội dung, code, hoặc plugin. Lập baseline trước khi fix, đo lại sau, so sánh chênh lệch.

Quy trình chạy test từng bước

  1. Mở pagespeed.web.dev trong trình duyệt.
  2. Dán URL cần test — ưu tiên URL trang sản phẩm hoặc landing page, không chỉ trang chủ.
  3. Bấm “Analyze” và chờ 30-60 giây.
  4. Mặc định hiển thị tab Mobile — Google ưu tiên đánh giá mobile-first.
  5. Chuyển tab Desktop để so sánh.
  6. Chuyển tab “Origin” xem tổng hợp cả site, “URL” xem chỉ trang đang test.

Mẹo: chạy 3 lần lấy trung vị

Dữ liệu lab Lighthouse có độ biến động ±10-30 điểm giữa các lần do mạng và CPU mô phỏng. Chạy 3 lần, lấy trung vị để tránh quyết định dựa trên kết quả bất thường.

Hoặc dùng Lighthouse CLI local với flag --throttling.cpuSlowdownMultiplier=4 để ổn định hơn PSI online.

Bước 2 — Đọc điểm số và các chỉ số

Bước 2 — Đọc điểm số và các chỉ số
Bước 2 — Đọc điểm số và các chỉ số

PSI hiển thị điểm 0-100 (dữ liệu lab) và 6 chỉ số chính: LCP, INP, CLS, FCP, TTFB, TBT. Điểm có trọng số: LCP 25%, INP 25%, CLS 25%, FCP 10%, TBT 30%, Speed Index 10%.

Điểm trên 90 hiển thị xanh, 50-90 vàng, dưới 50 đỏ.

Đọc phần dữ liệu thực tế — tín hiệu xếp hạng

  1. Phần “Discover what your real users are experiencing” nằm trên cùng.
  2. Hiển thị 3 chỉ số CWV (LCP, INP, CLS) cộng TTFB và FCP.
  3. Badge “Core Web Vitals Assessment” cho thấy pass/fail tổng thể.
  4. Tab Origin (tổng hợp toàn site) và URL (trang cụ thể đang test).

Đọc phần dữ liệu lab — debug

  1. Phần “Diagnose performance issues” nằm bên dưới phần dữ liệu thực tế.
  2. Điểm 0-100 và 6 chỉ số với giá trị cụ thể theo mili giây.
  3. Màu sắc: xanh = Good, vàng = Needs Improvement, đỏ = Poor.
  4. Bấm vào chỉ số để xem tooltip giải thích ý nghĩa.

Điểm 90+ nhưng CWV vẫn fail — bình thường không?

Bình thường. Điểm 90+ là dữ liệu lab — CWV xếp hạng dựa dữ liệu thực tế CrUX.

Site có điểm lab cao nhưng dữ liệu thực tế fail thường do INP hoặc mạng người dùng thật khác lab. Xem thêm trong bài CrUX — dữ liệu thực tế Google.

Bước 3 — Audit Opportunities

Phần “Opportunities” liệt kê các fix có tác động lớn nhất, sắp xếp theo “Estimated Savings” (mili giây). Mỗi mục có thể bấm “Show how to fix” để xem hướng dẫn chi tiết.

5 Opportunities phổ biến cho WordPress

  • Reduce unused JavaScript: tách code, trì hoãn script không quan trọng.
  • Properly size images: serve ảnh đúng độ phân giải viewport, không dùng ảnh 4000px cho mobile.
  • Defer offscreen images: lazy load ảnh phần dưới trang qua loading="lazy".
  • Eliminate render-blocking resources: inline CSS quan trọng, trì hoãn JS không cần thiết.
  • Serve images in next-gen formats: WebP hoặc AVIF thay PNG/JPG.

Cách đọc “Estimated Savings”

Con số này là ước tính — không phải giá trị chính xác sau khi fix. Dùng để so sánh độ ưu tiên giữa các fix, không dùng làm cam kết kết quả.

Reduce unused JavaScript     | Est. savings: 850ms
Properly size images         | Est. savings: 420ms
Eliminate render-blocking    | Est. savings: 320ms
Defer offscreen images       | Est. savings: 180ms

Độ ưu tiên khi nhiều Opportunities

Fix theo thứ tự Estimated Savings từ lớn đến nhỏ. Sau mỗi fix, chạy lại PSI để đo thực tế — ước tính đôi khi lệch nhiều so với kết quả thật.

Bước 4 — Audit Diagnostics

Phần “Diagnostics” liệt kê vấn đề tác động gián tiếp, không có fix tự động — cần hiểu nguyên nhân gốc rễ. Đây là bước cần đầu tư thời gian phân tích nhiều nhất.

Diagnostics thường gặp và hướng fix

Diagnostic Vấn đề Hướng fix
Avoid enormous network payloads Tổng tải > 1.6MB Nén + lazy load + bỏ những gì không dùng
Minimize main-thread work Script chiếm > 4 giây Tách code, trì hoãn, bỏ plugin nặng
Reduce JavaScript execution time JS chạy > 3.5 giây Tree-shake + nén + thay thư viện nặng
Avoid an excessive DOM size > 1500 node DOM Phân trang + đơn giản hoá markup
Serves static assets with efficient cache policy Cache-Control TTL ngắn Set max-age=31536000 cho tài sản tĩnh

Thứ tự ưu tiên khi có cả Opportunities và Diagnostics

Fix Opportunities trước — chúng có ước tính tiết kiệm cụ thể. Diagnostics giải quyết sau khi đã hết Opportunities trên 300ms.

Bước 5 — Quy trình fix theo độ ưu tiên

Fix theo thứ tự: dữ liệu thực tế fail trước (tác động xếp hạng) → Opportunities top 3 → Diagnostics gốc rễ. Không fix ngẫu nhiên — chọn fix có Estimated Savings lớn nhất, đo lại sau mỗi fix.

Vòng lặp fix từng bước

  1. Baseline: chạy PSI 3 lần lấy trung vị, chụp màn hình Opportunities và Diagnostics.
  2. Chọn fix #1: Opportunity có Estimated Savings lớn nhất.
  3. Triển khai fix lên bản thử hoặc sản phẩm.
  4. Đo lại sau 5-10 phút (xóa cache) — chạy PSI 3 lần.
  5. So sánh chênh lệch — fix có hiệu quả không?
  6. Lặp lại với fix tiếp theo theo độ ưu tiên.
  7. Dữ liệu thực tế: sau 14-28 ngày, kiểm tra Search Console “Core Web Vitals”.

Sai lầm phổ biến khi dùng PSI

  • Fix dữ liệu lab nhưng không theo dõi dữ liệu thực tế — site lab xanh, thực tế vẫn fail xếp hạng.
  • Chạy PSI 1 lần ra số kém, kết luận fail ngay — độ biến động cao, cần trung vị 3 lần.
  • Chỉ test trang chủ, bỏ qua landing page — CrUX origin-level có thể che lấp trang có vấn đề.
  • Tắt plugin để tăng điểm nhưng plugin đó xử lý nghiệp vụ — ảnh hưởng doanh thu.

Checklist dùng PSI cho shop VN

  1. Test URL trang sản phẩm bán chạy nhất, không chỉ trang chủ.
  2. Chạy 3 lần, lấy trung vị — không dùng kết quả 1 lần duy nhất.
  3. Xem tab Mobile trước — Google index mobile-first.
  4. Đọc dữ liệu thực tế (CrUX) trước dữ liệu lab khi đánh giá xếp hạng.
  5. Sort Opportunities theo Estimated Savings, fix từ lớn đến nhỏ.
  6. Sau mỗi fix, đo lại PSI rồi mới chuyển sang fix tiếp theo.
  7. Theo dõi dữ liệu thực tế qua Search Console sau 14-28 ngày.
  8. Tham chiếu chéo với WebPageTest khi cần phân tích waterfall chi tiết.

Bài liên quan trong cluster Performance

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

PSI điểm 90+ nhưng CWV vẫn fail — tại sao?

Điểm PSI là dữ liệu lab, còn CWV xếp hạng dựa dữ liệu thực tế CrUX. Site điểm lab tốt nhưng thực tế fail thường do INP hoặc mạng người dùng thật khác lab.

Luôn dùng dữ liệu thực tế để đánh giá xếp hạng. Dữ liệu lab chỉ phục vụ debug nguyên nhân.

Mỗi lần chạy PSI ra số khác nhau — làm sao tin?

Dữ liệu lab có độ biến động ±10-30 điểm do mạng và CPU mô phỏng thay đổi mỗi lần. Chạy 3-5 lần và lấy trung vị.

Hoặc dùng Lighthouse CLI local để kiểm soát môi trường tốt hơn. Dữ liệu thực tế CrUX ổn định hơn nhiều.

Site WordPress điểm 50-70 — fix gì trước?

Thứ tự ưu tiên cho WordPress điển hình:

  • 1: Loại bỏ tài nguyên chặn hiển thị (inline CSS quan trọng).
  • 2: Tối ưu hình ảnh đúng kích thước (WebP + srcset).
  • 3: Giảm JavaScript không dùng (trì hoãn plugin không cần thiết).
  • 4: Cải thiện TTFB (cache + hosting phù hợp).
Plugin “Site Kit by Google” có thay thế PSI không?

Không thay thế. Site Kit kéo dữ liệu PSI vào WordPress dashboard, tiện theo dõi tổng quan hàng ngày.

Vẫn cần vào PSI trực tiếp để audit Opportunities và Diagnostics chi tiết.

Có cần test cả Mobile lẫn Desktop không?

Cần cả hai nếu site có lượng truy cập desktop đáng kể. Google ưu tiên mobile-first khi đánh giá xếp hạng.

Fix mobile trước. Desktop dùng để kiểm tra thêm, không phải ưu tiên chính.

Cần hỗ trợ đọc kết quả PSI và lên kế hoạch fix Core Web Vitals? Xem dịch vụ tối ưu hiệu năng của Web22.