PageSpeed Insights: đọc báo cáo và chọn việc cần làm

Bạn chạy PageSpeed Insights. Trên báo cáo có số, màu, biểu đồ và nhiều gợi ý. Lần đầu đo được một điểm, lần sau đổi sang điểm khác dù mình chưa chỉnh gì.

Vội nhìn vào màu đỏ, bạn có thể muốn bật thêm một loạt tính năng tối ưu. Nhưng trước khi sửa, hãy hỏi: “Mình đang nhìn dữ liệu của trang nào, thiết bị nào và thời điểm nào?”.

PageSpeed Insights cung cấp thông tin trải nghiệm thực tế khi đủ dữ liệu và chẩn đoán từ một lần đo mô phỏng. Hai phần bổ sung cho nhau, nhưng cần đọc riêng phạm vi.

1. Đo đúng một URL trước

Mở PageSpeed Insights, nhập đầy đủ URL và chọn Analyze. Khi có kết quả, nhìn lại URL báo cáo, nhất là địa chỉ có chuyển hướng.

Chọn Mobile hoặc Desktop theo thiết bị cần xem. Ghi lựa chọn ấy để lần đối chiếu sau không lấy điểm desktop so với mobile.

Nên bắt đầu bằng một trang quan trọng có nội dung bạn hiểu rõ, chẳng hạn trang sản phẩm khách hay mở. Một báo cáo trang chủ không tự đại diện toàn bộ danh mục, sản phẩm và bài viết.

2. Đọc phần trải nghiệm người dùng thực tế nếu có

Dữ liệu thực tế trong PSI dựa trên Chrome User Experience Report, thường hiển thị khoảng thu thập 28 ngày gần nhất. Đọc cả mốc thời gian và phạm vi ghi trên báo cáo.

Nếu URL chưa có đủ mẫu, công cụ có thể hiển thị dữ liệu ở mức origin. Khi đó, không gán toàn bộ các chỉ số ấy cho riêng trang đang thử. Origin là phạm vi được công cụ ghi rõ, không nên tự hiểu là mọi tên miền hoặc phiên bản địa chỉ của doanh nghiệp.

Nếu cả trang và origin đều chưa đủ dữ liệu, phần này có thể không hiển thị kết quả. Không đủ dữ liệu không phải đồng nghĩa trang đã tốt hoặc đã kém. Giải thích chính thức về dữ liệu PSI.

Ảnh minh họa giúp nhận ra thanh phân bố trải nghiệm. Khi đọc báo cáo của mình, ghi giá trị, đơn vị và phạm vi dữ liệu; đừng chép những con số của ảnh mẫu vào ghi chú thực tế.

3. Xem kết luận Core Web Vitals trong đúng ngữ cảnh

Các chỉ số LCP, INP và CLS phản ánh những khía cạnh khác nhau. Nếu chưa quen, quay lại cách hiểu: nội dung lớn xuất hiện, tương tác phản hồi và bố cục ổn định.

Đọc kết luận công cụ kèm tình trạng dữ liệu. Không lấy một mục xanh để kết luận mọi chỉ số đều tốt; cũng không tự điền số 0 cho phần thiếu dữ liệu.

Dữ liệu thực tế là lịch sử đã ghi nhận. Vừa sửa ảnh rồi chạy lại không có nghĩa cả khoảng lịch sử được thay bằng trải nghiệm mới. Bạn có thể kiểm tra tác động ban đầu trong phần mô phỏng, đồng thời tiếp tục quan sát dữ liệu thực tế theo thời gian.

4. Chuyển sang phần chẩn đoán mô phỏng

Phần này dùng Lighthouse để đo URL trong môi trường thử nghiệm. Xem điểm Performance và các giá trị cụ thể, rồi tìm đầu mối liên quan trải nghiệm mình muốn cải thiện.

Hãy xem cả thông tin điều kiện chạy. Thiết bị, cách mô phỏng mạng, thời điểm và môi trường đo có thể ảnh hưởng kết quả. Không cần ghi nhớ tên một mẫu điện thoại cố định; đọc điều công cụ nêu cho lần chạy của mình.

Điểm SEO trong Lighthouse kiểm tra một số tiêu chí kỹ thuật của công cụ, không phải kết luận toàn bộ chiến lược SEO hoặc thứ hạng. Tương tự, điểm Performance là tóm tắt phép đo hiệu suất, không thay việc khách có mua hàng hay gửi yêu cầu được không.

5. Từ một gợi ý đến một việc có thể kiểm chứng

Mở mục liên quan và xem tài nguyên hoặc phần tử được nêu. Đừng chỉ đọc tên gợi ý rồi áp cùng một cách sửa cho mọi trang.

Đầu mối trong báo cáo	Câu hỏi cần xác minh	Việc vừa sức
Ảnh chưa phù hợp kích thước hoặc dung lượng.	Ảnh nào, được dùng ở đâu, cần giữ chi tiết gì?	Thử một phiên bản phù hợp và nhìn lại trên trang.
Phần tử liên quan LCP xuất hiện muộn.	Chờ máy chủ, tải tài nguyên hay chờ hiển thị?	Ghi phần tử và đầu mối để xử lý đúng phần.
JavaScript hoặc tác vụ chặn xử lý.	Thuộc chức năng nào, có cần trong thời điểm đó không?	Nhờ kiểm tra, không tự tắt toàn bộ mã tương tác.
Dịch chuyển bố cục.	Ảnh, font hoặc khối chèn thêm có đẩy nội dung không?	Thử xác nhận vị trí gây nhảy và cách giữ không gian.

Các dòng là hướng đặt câu hỏi, chưa phải nguyên nhân đã xác nhận trên website của bạn. Tên các mục chẩn đoán có thể thay đổi theo phiên bản Lighthouse.

Những con số “có thể tiết kiệm” có cộng lại được không?

Không nên cộng máy móc. Nhiều đầu mối có thể liên quan cùng tài nguyên hoặc cùng khoảng chờ. Ước tính trong báo cáo giúp tìm việc đáng xem, không phải hợp đồng cam kết trang sẽ nhanh hơn đúng từng ấy sau khi bật một ô.

Ưu tiên vấn đề có bằng chứng, tác động đến phần người dùng cần và nằm trong khả năng kiểm soát. Nếu nghi ngờ một thiết lập, ghi trạng thái ban đầu để có thể quay lại.

6. Đo lại và kiểm tra các chức năng quan trọng

1. Thay một nhóm việc có lý do rõ, ghi lại đã làm gì và thời điểm.
2. Đo lại cùng URL, cùng thiết bị; xem giá trị cụ thể và điều kiện chứ không chỉ điểm tổng.
3. Nếu kết quả dao động bất thường, chạy thêm để xác định xu hướng; không chọn riêng lần cao nhất.
4. Mở trang công khai và thử menu, ảnh, nút liên hệ, biến thể sản phẩm hoặc biểu mẫu liên quan.
5. Theo dõi thêm dữ liệu thực tế khi có đủ thời gian và mẫu.

web.dev giải thích khác biệt giữa dữ liệu mô phỏng và thực tế. Một bên là đầu mối chẩn đoán, bên kia giúp nhìn trải nghiệm đã ghi nhận; chúng không cần giống hệt nhau.

Thực hành: chốt một công việc sau báo cáo

Ngày, URL và thiết bị: …
Phần thực tế: URL hay origin, khoảng ngày, có đủ dữ liệu không: …
Phần mô phỏng: điều kiện và chỉ số quan tâm: …
Tài nguyên hoặc phần tử được nêu: …
Việc đã xác minh, phần còn giả thuyết: …
Một thay đổi / người cần nhờ: …
Kết quả đo lại và thử chức năng: …

Một ghi chú tốt có thể ngắn: “Ảnh chính trên trang A đang tải phiên bản quá lớn; thử bản phù hợp, giữ chất lượng và kiểm tra lại.” Nó giúp bắt tay vào việc rõ hơn câu “cần đạt 100 điểm”.

Mang về một việc có căn cứ từ báo cáo, rồi kiểm tra người dùng có đi dễ hơn sau lần sửa ấy không.

Phần tiếp theo sẽ nhìn lại vai trò plugin SEO: công cụ nhắc được gì và những quyết định nào vẫn cần người làm website.

Các chuyên đề Mùa 4 · Bản đồ Hiểu Google

Đối chiếu tài liệu Google, Chrome và web.dev ngày 20/10/2026. Các ảnh là tài liệu Google, không phải kết quả đo riêng của phamvanan.com. Bài này hướng dẫn cách đọc và ghi chép, chưa thay đổi cấu hình website.