Nhiều người mở công cụ này lên, thấy điểm 62 màu cam là bắt đầu lo, rồi lao vào tối ưu lung tung để kéo con số lên 90. Đó là cách đọc sai phổ biến nhất. Báo cáo có hai lớp dữ liệu khác hẳn nhau về bản chất, và lớp quyết định trải nghiệm thật (cũng là lớp Google dùng để xếp hạng) lại không phải con số to nhất trên màn hình.
Hai lớp dữ liệu khác nhau hoàn toàn
Khi bạn nhập URL và chạy kiểm tra, báo cáo trả về hai khối: Discover what your real users are experiencing (field data) ở trên và Diagnose performance issues (lab data) ở dưới. Phân biệt được hai lớp này là 80% việc đọc đúng báo cáo.
Field data — dữ liệu người dùng thật (CrUX)
Đây là dữ liệu lấy từ CrUX (Chrome User Experience Report — báo cáo trải nghiệm người dùng Chrome): gom số liệu ẩn danh từ những người dùng Chrome thật đã vào trang của bạn, theo cửa sổ trượt 28 ngày. Đây mới là cái phản ánh tốc độ thật trên đủ loại máy, đủ loại mạng — và là dữ liệu Google thực sự dùng cho tín hiệu xếp hạng Core Web Vitals.
Field data báo cáo ở phân vị 75 (p75 — mốc mà 75% lượt truy cập có trải nghiệm tốt hơn hoặc bằng). Trang được xem là “đạt” khi cả ba chỉ số chính đều nằm trong ngưỡng tốt:
| Chỉ số | Ý nghĩa | Ngưỡng “Good” (p75) |
|---|---|---|
| LCP | Largest Contentful Paint — thời điểm phần tử lớn nhất hiện ra | ≤ 2,5 giây |
| INP | Interaction to Next Paint — độ trễ phản hồi tương tác | ≤ 200 mili giây |
| CLS | Cumulative Layout Shift — độ xê dịch bố cục | ≤ 0,1 |
Lưu ý INP đã chính thức thay FID làm Core Web Vital từ ngày 12/3/2024 — nếu tài liệu nào còn nhắc FID thì đã lỗi thời. Tính tới giữa năm 2026, theo dữ liệu CrUX chỉ khoảng 56% origin trên toàn cầu đạt cả ba chỉ số, nên nếu trang bạn chưa đạt thì cũng là chuyện rất phổ biến, không có gì bất thường.
Một điểm quan trọng: field data chỉ xuất hiện khi trang có đủ lượng truy cập để CrUX gom đủ mẫu. Trang mới hoặc ít người vào sẽ không có khối này — đó là lý do bạn cần đọc cả lab data.
Lab data — đo mô phỏng bằng Lighthouse
Khối dưới do Lighthouse chạy một lần ngay lúc bạn bấm: tải trang trên một thiết bị mô phỏng, một điều kiện mạng cố định (mặc định mô phỏng máy di động tầm trung, mạng chậm). Điểm 0-100 to đùng ở đầu báo cáo chính là điểm lab này.
Vì là một lần đo trong môi trường giả lập, lab data thường khắc nghiệt hơn field data. Một phân tích của DebugBear chỉ ra Lighthouse hay phản ánh nhóm 5-10% trải nghiệm tệ nhất, trong khi field data lấy mốc p75 (nhóm 25% tệ nhất). Vì vậy điểm lab thấp hơn cảm nhận thật là chuyện bình thường — đừng hoảng.
Điểm 0-100 nói lên điều gì (và không nói gì)
Điểm tổng là trung bình có trọng số của các chỉ số đo trong lab (chủ yếu LCP, TBT (Total Blocking Time — tổng thời gian luồng chính bị chặn), CLS, FCP, Speed Index). Màu sắc: 0-49 đỏ, 50-89 cam, 90-100 xanh.
Điều quan trọng cần khắc cốt: điểm lab KHÔNG phải tín hiệu xếp hạng. Google xếp hạng dựa trên field data (CrUX), không dựa trên con số 0-100 này. Điểm lab chỉ là công cụ chẩn đoán để gỡ lỗi. Một trang điểm lab 78 mà field data cả ba chỉ số đều xanh thì vẫn “đạt” trong mắt Google; ngược lại điểm lab 95 nhưng field data đỏ INP thì vẫn trượt.
Vì vậy đừng đốt cả tuần để kéo lab từ 88 lên 92. Việc đó hầu như không đổi gì cho người dùng lẫn thứ hạng. Hãy nhìn field data trước: chỉ số nào đang đỏ hoặc cam thì đó là việc.
Đọc phần chẩn đoán để ra việc cần làm
Phần dưới lab data là nơi PSI gợi ý hành động. Từ giữa năm 2025, Google đã gộp mục “Opportunities” (cơ hội) và “Diagnostics” (chẩn đoán) cũ thành các “Insights” audit mới (theo Chrome for Developers), nên giao diện gần đây bạn sẽ thấy danh sách Insights kèm phần Diagnostics còn lại. Dù tên đổi, cách dùng vẫn vậy:
- Mỗi mục ước lượng phần tiết kiệm — ví dụ “Improve image delivery — Est savings 1.2 s”. Đây là khoảng thời gian dự kiến cứu được nếu bạn sửa, sắp theo tác động giảm dần.
- Mỗi mục gắn với chỉ số nó ảnh hưởng — nhãn LCP, CLS hay TBT cho bạn biết sửa nó thì chỉ số nào cải thiện.
- Mở rộng từng mục để xem đúng tài nguyên (file, ảnh, script) gây vấn đề, kèm link tài liệu khắc phục.
Quy trình ra việc gọn nhất:
- Xem field data: chỉ số nào KHÔNG xanh? Đó là mục tiêu (ví dụ LCP đang 3,8s).
- Cuộn xuống lab, lọc các Insights gắn nhãn đúng chỉ số đó (lọc LCP).
- Sửa từ mục có “Est savings” lớn nhất xuống — đòn bẩy cao nhất trước.
- Đo lại bằng chính field data sau vài tuần, không phải bằng điểm lab ngay sau khi sửa.
Ví dụ thực tế khi vận hành web22.dev: nếu Insights chỉ ra ảnh hero chưa nén và chưa khai báo kích thước, sửa đúng hai cái đó thường gỡ được cả LCP (ảnh nặng) lẫn CLS (ảnh nhảy chỗ) cùng lúc — một mũi tên trúng hai chỉ số, đáng làm trước những thứ vụn vặt.
Những bẫy đọc báo cáo hay gặp
- Lab và field “cãi nhau”: bình thường. Field là sự thật về người dùng; lab là một lần đo giả lập. Khi cần quyết định, tin field.
- Mỗi lần chạy ra điểm lab khác nhau: Lighthouse có dao động (variance). Đừng so hai lần đo cách nhau vài phút rồi kết luận. Cần đo lặp nhiều lần thì dùng công cụ chuyên sâu như đo hiệu năng bằng WebPageTest.
- Test trang ít traffic rồi tưởng không có field data là lỗi: chỉ là chưa đủ mẫu CrUX. Muốn xem dữ liệu thật ở quy mô tập hợp, đọc thêm về dữ liệu CrUX của Google.
- Chạy một URL rồi nghĩ cả site đều vậy: mỗi mẫu trang (trang chủ, bài viết, sản phẩm) có vấn đề riêng. Test đại diện từng loại.
Câu hỏi thường gặp
PageSpeed Insights và Lighthouse khác gì nhau?
Lighthouse là động cơ đo lab. PSI ghép kết quả Lighthouse với field data CrUX và chạy trên máy chủ Google với điều kiện chuẩn hoá, nên dùng PSI để có cả hai lớp dữ liệu.
Bao nhiêu điểm là “đủ”?
Không có mốc điểm lab bắt buộc. Mục tiêu thật là field data đạt cả ba Core Web Vitals (LCP, INP, CLS) ở ngưỡng tốt. Điểm lab chỉ để dò việc.
Sao sửa xong điểm chưa lên?
Field data trễ vì tính trên cửa sổ 28 ngày người dùng thật; thường mất vài tuần mới phản ánh thay đổi. Lab thì lên ngay nhưng đừng coi đó là kết quả cuối.
Nếu báo cáo chỉ ra một loạt việc mà bạn không có thời gian tự xử, dịch vụ tối ưu Core Web Vitals của Web22 nhận audit và sửa theo đúng thứ tự đòn bẩy.