PageSpeed Insights nên được đọc như thế nào?
Hãy đọc Google PageSpeed Insights theo ba lớp. Đầu tiên, xem Field Data để biết người dùng thật đã trải nghiệm trang ra sao trong 28 ngày gần nhất. Tiếp theo, dùng Lab Data để tìm nguyên nhân kỹ thuật trong một lần mô phỏng. Cuối cùng, nhóm các cảnh báo theo nguyên nhân và ưu tiên việc sửa theo tác động, phạm vi URL và công sức.
Bạn mở PageSpeed Insights và thấy mobile 48 điểm, desktop 95 điểm, còn người khác gửi ảnh chụp 82 điểm của đúng URL đó. Cả ba con số đều có thể đúng vì điều kiện đo khác nhau. Sai lầm nằm ở việc coi một lần chạy Lighthouse là kết luận cuối cùng cho toàn bộ website.
- Xác nhận đúng URL và đúng thiết bị.
- Đọc Field Data ở cấp URL hay cấp origin.
- Kiểm tra LCP, INP và CLS ở phân vị 75.
- Dùng Lab Data và mục Thông tin chi tiết để tìm nguyên nhân.
- Chuyển nguyên nhân thành backlog P0, P1, P2 rồi đo lại.
Google PageSpeed Insights là gì?
Google PageSpeed Insights, viết tắt là PSI, là công cụ miễn phí dùng để đánh giá hiệu suất của một URL trên mobile và desktop. PSI kết hợp dữ liệu người dùng thật từ Chrome UX Report với dữ liệu mô phỏng của Lighthouse, sau đó cung cấp chỉ số, thông tin chẩn đoán và gợi ý cải thiện.[1]
PSI không đo “tốc độ của cả website” chỉ bằng một lần nhập trang chủ. Mỗi lần phân tích bắt đầu từ một URL cụ thể, mà trang sản phẩm, bài blog và trang thanh toán lại dùng component, ảnh và script khác nhau.
| Loại dữ liệu | Phản ánh điều gì | Dùng khi nào | Giới hạn |
|---|---|---|---|
| Field Data | Trải nghiệm người dùng Chrome thật trong 28 ngày gần nhất | Đánh giá Core Web Vitals thực tế và theo dõi sau triển khai | Có thể không đủ mẫu ở cấp URL |
| Lab Data | Một lần tải trang trong môi trường Lighthouse mô phỏng | Tái hiện vấn đề, tìm request, component và tác vụ gây chậm | Dao động theo lần chạy và không đại diện mọi người dùng |
Field Data cho biết vấn đề có xảy ra với người dùng thật hay không, còn Lab Data giúp đội kỹ thuật tìm nơi nên bắt đầu sửa.
PageSpeed bao nhiêu điểm là tốt?
Điểm Performance của Lighthouse được chia thành ba vùng: 0–49 là kém, 50–89 là cần cải thiện và 90–100 là tốt. Đây là điểm tổng hợp của các chỉ số lab, không phải điểm Core Web Vitals của người dùng thật.[2]
Với Core Web Vitals, Google đánh giá LCP, INP và CLS ở phân vị 75. Có thể hiểu đơn giản rằng ít nhất 75% lượt xem trang cần đạt ngưỡng “tốt” để chỉ số đó được xếp loại tốt.[3]
| Chỉ số | Tốt | Cần cải thiện | Kém | Ý nghĩa |
|---|---|---|---|---|
| LCP | ≤ 2,5 giây | > 2,5 đến 4 giây | > 4 giây | Tốc độ hiển thị nội dung chính |
| INP | ≤ 200 ms | > 200 đến 500 ms | > 500 ms | Khả năng phản hồi khi tương tác |
| CLS | ≤ 0,1 | > 0,1 đến 0,25 | > 0,25 | Độ ổn định của bố cục |
Mục tiêu hợp lý là đạt Core Web Vitals tốt cho người dùng thật, không phải đẩy điểm từ 99 lên 100. Sửa một form chậm phản hồi hoặc một ảnh hero làm LCP xấu trên mobile đáng ưu tiên hơn nhiều.
Cách đọc PageSpeed Insights theo đúng thứ tự
1. Kiểm tra URL, mobile và desktop
Nhập URL canonical cuối cùng, không nhập một URL đang redirect. Nếu muốn audit một template, hãy chọn URL có traffic hoặc conversion.
Đọc mobile và desktop riêng. PSI mô phỏng thiết bị, CPU và mạng khác nhau nên hai kết quả có thể chênh lệch lớn. Desktop xanh không thể “bù điểm” cho mobile cam hoặc đỏ.
2. Xác định Field Data ở cấp URL hay origin
Phần “Khám phá nội dung người dùng thực tế của bạn đang trải nghiệm” dùng dữ liệu CrUX. Hãy kiểm tra dữ liệu đang áp dụng cho chính URL hay cho toàn origin. Khi một URL không đủ mẫu, PSI có thể hiển thị dữ liệu origin hoặc báo không có dữ liệu.
“Không có dữ liệu” không đồng nghĩa trang nhanh hay chậm, mà chỉ có nghĩa CrUX chưa đủ mẫu ở phạm vi đó. Khi gặp trường hợp này, hãy dùng Lab Data để chẩn đoán.
3. Đọc Core Web Vitals trước điểm Performance
Với chỉ số CLS, hãy xem riêng CLS là gì và cách giảm layout shift để biết cách tìm phần tử làm giao diện bị xê dịch.
Nếu có Field Data, hãy xem LCP, INP và CLS trước. Chỉ số nào không đạt sẽ cho biết loại trải nghiệm đang có vấn đề: LCP là tải nội dung chính, INP là phản hồi sau thao tác, CLS là những cú nhảy bố cục bất ngờ.
Bạn có thể đọc sâu hơn tại bài Core Web Vitals là gì và bài INP là gì. Điều quan trọng ở PSI là không đánh đồng TBT trong lab với INP của người dùng thật.
4. Dùng các chỉ số lab để khoanh vùng vấn đề
| Chỉ số lab | Câu hỏi cần trả lời | Nơi nên kiểm tra tiếp |
|---|---|---|
| FCP | Nội dung đầu tiên xuất hiện có muộn không? | TTFB, CSS chặn hiển thị, font và chuỗi request đầu trang |
| LCP | Nội dung chính xuất hiện có muộn không? | Phần tử LCP, thời điểm khám phá tài nguyên, dung lượng ảnh và phản hồi máy chủ |
| TBT | Main thread bị chặn trong quá trình tải bao lâu? | JavaScript, long task, script bên thứ ba và hydration |
| CLS | Bố cục có dịch chuyển khi tải không? | Kích thước ảnh, vùng quảng cáo, font và nội dung chèn muộn |
| Speed Index | Nội dung trong viewport được lấp đầy nhanh đến đâu? | Tài nguyên chặn hiển thị, ảnh và thứ tự ưu tiên tải |
Theo tài liệu Lighthouse, điểm Performance là trung bình có trọng số của các điểm metric. Opportunities và Diagnostics không cộng trừ điểm trực tiếp, chúng chỉ ra nguyên nhân có thể làm metric thay đổi.[2]
5. Mở “Thông tin chi tiết” và “Chẩn đoán”
Đây là nơi báo cáo chuyển từ một con số thành bằng chứng kỹ thuật. Hãy mở bảng chi tiết LCP, cây phụ thuộc mạng, request chặn hiển thị và tài nguyên bên thứ ba, rồi đối chiếu với Chrome DevTools.
Từ cảnh báo PageSpeed đến nguyên nhân cần sửa
| Cảnh báo hoặc chỉ số | Nguyên nhân thường gặp | Cách xác minh | Đầu việc phù hợp |
|---|---|---|---|
| LCP chậm | Ảnh hero nặng, tài nguyên được phát hiện muộn, TTFB cao | Xem phần tử LCP, Network waterfall và LCP breakdown | Tối ưu ảnh, srcset, priority, cache hoặc server |
| TBT cao | Bundle lớn, long task, script bên thứ ba | Ghi Performance trace và xem main thread | Code splitting, defer, giảm tag hoặc giảm hydration |
| CLS cao | Ảnh thiếu kích thước, font đổi muộn, vùng chèn không giữ chỗ | Xem Layout Shift và phần tử bị dịch chuyển | Khai báo kích thước, giữ chỗ và tối ưu font |
| Render-blocking requests | CSS hoặc font cần tải trước khi hiển thị | Đối chiếu request chain và Coverage | Critical CSS, preload có chọn lọc và dọn CSS |
| Improve image delivery | Ảnh sai kích thước, định dạng hoặc mức nén | So kích thước hiển thị với kích thước truyền | WebP hoặc AVIF, srcset và nén theo chất lượng thật |
| Third-party impact | Chat, heatmap, quảng cáo hoặc tag trùng | Lọc request theo domain và đo thời gian main thread | Giữ công cụ có giá trị, trì hoãn hoặc loại tag thừa |
Một nguyên nhân có thể tạo nhiều cảnh báo. Ảnh hero quá lớn ảnh hưởng cả LCP lẫn mức truyền dữ liệu, nên sửa ảnh một lần tốt hơn tạo ba ticket rời rạc. Bài Image SEO giải thích cách chọn định dạng và kích thước ảnh, còn quy trình chẩn đoán website chậm giúp khoanh vùng nút thắt ở server, ảnh hay JavaScript.
Xếp backlog P0, P1 và P2 thế nào?
| Mức | Khi nào áp dụng | Ví dụ đầu việc |
|---|---|---|
| P0 | Lỗi chặn người dùng hoặc conversion, trang không tải hoặc thao tác chính không dùng được | Form treo trên mobile, nội dung chính không hiển thị, script gây lỗi toàn trang |
| P1 | Core Web Vitals xấu trên nhóm URL quan trọng hoặc lỗi nằm ở component dùng rộng | Ảnh hero của toàn bộ landing page bị lazy-load, bundle chung tạo long task |
| P2 | Cải thiện có lợi nhưng tác động nhỏ, phạm vi hẹp hoặc chưa có bằng chứng người dùng | Giảm thêm ít CSS, tối ưu animation phụ, cải thiện điểm từ vùng tốt lên cao hơn |
Mỗi ticket nên có URL mẫu, thiết bị, bằng chứng, metric cần cải thiện và cách nghiệm thu.
Vì sao mobile, desktop, URL và origin khác nhau?
Ví dụ thật: cùng một URL, mobile 83 và desktop 99
Ngày 02/08/2026, Mạnh Digital đo chính bài viết này bằng PageSpeed Insights. PSI chưa đủ dữ liệu CrUX ở cấp URL vì bài mới xuất bản. Lab mobile đạt 83 điểm, desktop đạt 99 điểm.
| Chỉ số | Mobile | Desktop |
|---|---|---|
| Performance | 83 | 99 |
| FCP | 3,2 giây | 0,8 giây |
| LCP | 3,3 giây | 0,8 giây |
| TBT | 40 ms | 0 ms |
| CLS | 0 | 0 |
| Speed Index | 4,6 giây | 0,8 giây |
Trên mobile, TBT và CLS đều tốt trong lần chạy này, còn FCP và LCP chậm hơn rõ rệt. Vì vậy hướng điều tra hợp lý là chuỗi hiển thị đầu trang và phần tử LCP, không phải xóa mọi script chỉ vì báo cáo nhắc đến JavaScript thừa.
Mobile và desktop có điều kiện mô phỏng khác nhau
Mobile thường dùng CPU và mạng hạn chế hơn. Layout, ảnh được chọn từ srcset và code chạy theo breakpoint cũng có thể khác. Vì vậy, một URL đạt 99 desktop nhưng chỉ 83 mobile là điều hoàn toàn có thể xảy ra.
URL-level và origin-level không cùng phạm vi
Dữ liệu URL-level nói về đúng URL khi có đủ mẫu. Origin-level gom trải nghiệm của nhiều URL cùng origin. Dữ liệu origin giúp nhìn bức tranh rộng, nhưng không chứng minh một template cụ thể đã tốt.
Search Console còn gom URL thành nhóm
Báo cáo Core Web Vitals trong Search Console gom các URL có đặc điểm tương tự. PSI thường dùng để kiểm tra một URL cụ thể. Google cũng lưu ý hai báo cáo có thể không khớp hoàn toàn vì phạm vi và cách nhóm dữ liệu khác nhau.[4]
Với website responsive, hãy kiểm tra thêm tính tương đương nội dung và chức năng theo hướng dẫn Mobile-First Indexing, vì một trang nhanh nhưng thiếu nội dung chính trên mobile vẫn là trải nghiệm chưa hoàn chỉnh. Bài tốc độ website ảnh hưởng SEO như thế nào đặt các con số này vào bối cảnh chuyển đổi.
Câu hỏi thường gặp
Tại sao điểm PageSpeed thay đổi sau mỗi lần chạy?
Lighthouse chạy trong môi trường mô phỏng và chịu ảnh hưởng của máy chủ, mạng, script bên thứ ba và tác vụ nền. Hãy chạy 3–5 lần trong điều kiện tương tự, lưu median và so cùng phiên bản deploy thay vì chọn lần có điểm cao nhất.
PageSpeed Insights có kiểm tra toàn bộ website không?
Không. PSI bắt đầu từ URL bạn nhập và chỉ tạo báo cáo cho trang đó. Muốn audit toàn website, hãy chọn URL đại diện cho từng template và kết hợp báo cáo Core Web Vitals trong Search Console.
Điểm PageSpeed có ảnh hưởng trực tiếp đến SEO không?
Core Web Vitals được Google sử dụng trong các hệ thống xếp hạng cùng nhiều tín hiệu khác. Google xác nhận Core Web Vitals là một phần của page experience, nhưng điểm tốt không bảo đảm trang đứng đầu.[5]
Kết luận
Một báo cáo PageSpeed Insights tốt không kết thúc ở câu “mobile được bao nhiêu điểm”. Nó phải giúp đội ngũ hiểu người dùng thật đang gặp vấn đề gì, lần chạy lab đang chỉ về nguyên nhân nào và đầu việc nào đáng làm trước.
Hãy nhớ thứ tự: Field Data để xác nhận, Lab Data để chẩn đoán, backlog để triển khai và dữ liệu sau deploy để nghiệm thu. Nếu lỗi trải trên nhiều template hoặc chưa rõ đâu là nguyên nhân gốc, bạn có thể bắt đầu bằng một SEO Audit có phạm vi, bằng chứng và mức ưu tiên rõ ràng.
Nguồn tham khảo
- Google Developers: About PageSpeed Insights, truy cập ngày 02/08/2026.
- Chrome for Developers: Lighthouse performance scoring, truy cập ngày 02/08/2026.
- web.dev: How the Core Web Vitals thresholds were defined, cập nhật ngày 07/05/2025.
- Google Search Console: Báo cáo Core Web Vitals, truy cập ngày 02/08/2026.
- Google Search Central: Understanding page experience in Google Search results, cập nhật ngày 10/12/2025.