Hiểu Google
PageSpeed Insights: đọc báo cáo trước khi vội sửa website
Th10
Hiểu Google · Mùa 4 · Chuyên đề 37
Người đồng hành vừa đo tốc độ trang chủ. Một điểm số màu cam xuất hiện. “Có cần thay giao diện luôn không?”
Anh Gồ chưa mở hộp dụng cụ. Ông hỏi trang nào khiến khách chờ, đang xem trên điện thoại hay máy tính, và điểm vừa thấy lấy từ người đã ghé hay một lần chạy thử. Chủ nhà dừng lại: hóa ra mình mới nhìn một con số.
Trong câu chuyện giả định này, điều cần làm trước là đọc đúng báo cáo. PageSpeed Insights giúp tìm dấu hiệu trải nghiệm chậm; quyết định sửa gì cần gắn với trang và vấn đề cụ thể.
Chọn trang đang có một công việc thật
Có thể bắt đầu từ trang sản phẩm khách thường mở, trang dịch vụ nhận nhiều lượt vào hoặc bài có ảnh lớn. Chỉ đo trang chủ rồi kết luận cả website nhanh hay chậm sẽ bỏ qua nhiều kiểu trang. Với mỗi kiểu, chọn một URL đại diện để xem trước.
Mở PageSpeed Insights, nhập URL công khai và chạy phân tích. Ghi ngày, URL, lựa chọn Mobile hay Desktop, rồi kiểm tra báo cáo có đang xét đúng địa chỉ sau chuyển hướng không. Đây là đầu vào để lần sau so lại cùng một việc.
Phần người dùng thực đang kể chuyện của ai?
Đọc ảnh: Mobile đang được chọn; phía trên có This URL và Origin. Ba chỉ số LCP, INP, CLS nằm trong nhóm Core Web Vitals, dưới cùng ghi kỳ thu thập 28 ngày. Ảnh còn hiển thị FID ở nhóm khác do thuộc giao diện cũ; đừng dùng FID thay INP khi đọc bộ chỉ số hiện nay.
Dữ liệu thực đến từ Chrome User Experience Report, khi có đủ mẫu phù hợp. Nó phản ánh trải nghiệm đã ghi nhận trong khoảng 28 ngày gần nhất. Sửa hôm nay rồi mở lại ngay không có nghĩa phần này phải đổi theo ngay. Google giải thích hai phần dữ liệu của PageSpeed Insights.
Nếu không đủ mẫu cho URL, công cụ có thể dùng dữ liệu của origin, tức phạm vi gốc như https://example.com. Nếu cả phạm vi đó thiếu mẫu, phần trải nghiệm thực có thể không có dữ liệu. Thiếu dữ liệu chưa cho biết trang nhanh hay chậm.
Đọc ảnh: This URL bị mờ và Origin được chọn; lời nhắc nói không đủ dữ liệu thực cho URL. Nếu đang kiểm tra một bài mới, không nên lấy các chỉ số gộp này rồi gọi chúng là trải nghiệm riêng của bài ấy. Tài liệu web.dev dùng ảnh này để giải thích sự chuyển phạm vi.
Ba chỉ số trả lời ba câu hỏi khác nhau
LCP liên quan thời điểm phần nội dung lớn nhất trong khung nhìn xuất hiện; INP liên quan độ đáp ứng khi người dùng tương tác; CLS liên quan những lần bố cục xê dịch bất ngờ. Cách gọi tên không quan trọng bằng việc hình dung khách đang chờ điều gì hoặc bấm nhầm vì điều gì di chuyển.
Theo hướng dẫn Core Web Vitals, các mức tốt tương ứng là LCP không quá 2,5 giây, INP không quá 200 mili giây và CLS không quá 0,1, được đánh giá ở phân vị 75. Có thể hiểu đơn giản đây là mốc đại diện mà khoảng 75% quan sát không vượt quá; nó không phải trung bình cộng mọi lượt ghé.
Trong ví dụ tự đặt về trang sản phẩm, ảnh chính hiện muộn khiến khách chưa biết mình đang xem mẫu nào. Ở trang khác, ảnh hiện nhanh nhưng nút mở tùy chọn phản hồi chậm. Hai khó chịu ấy dẫn đến hai hướng tìm hiểu khác nhau. Đừng gom chúng thành một lời khuyên “nén hết ảnh”.
Điểm màu ở phần mô phỏng dùng để tìm dấu hiệu
Phần chẩn đoán mô phỏng do Lighthouse chạy trong điều kiện được thiết lập. Nó hữu ích để xem vấn đề có thể tái hiện và mở chi tiết, nhưng không phải một cuộc khảo sát mọi khách ghé. Điều kiện chạy, tài nguyên bên ngoài hoặc trạng thái máy chủ có thể làm kết quả dao động.
Điểm Performance được tạo từ các chỉ số và cách tính của Lighthouse. Xem giải thích điểm hiệu suất trước khi biến nó thành mục tiêu duy nhất. Điểm SEO trong cùng báo cáo cũng không phải điểm thứ hạng của Google.
Nếu một lần đo khác hẳn những lần còn lại, kiểm tra URL và điều kiện rồi chạy lại vài lần để hiểu mức dao động. Ghi kết quả có bối cảnh; đừng chọn riêng lần đẹp nhất để báo cáo. Khi so trước và sau, giữ cùng lựa chọn thiết bị và cách kiểm tra.
Tìm một phần cần sửa, không mở mọi công tắc
Mở phần chỉ số có vấn đề và xem tài nguyên hoặc thành phần được nêu. Nếu ảnh lớn là phần LCP, cần biết nó tải nặng, được phát hiện muộn hay đã tải xong nhưng chưa hiện. Hướng dẫn cải thiện LCP của web.dev phân tích các phần thời gian này; giảm dung lượng ảnh chỉ giải quyết phần phù hợp của vấn đề.
Với người tự chăm website, đầu ra hữu ích có thể là một việc đủ rõ để giao: “Ở URL sản phẩm, ảnh chính hiện muộn trên lần chạy Mobile; cần kiểm tra ảnh nào được tải và lúc nào được yêu cầu”. Câu đó dễ kiểm tra hơn “hãy làm website đạt 100 điểm”.
Trước khi đổi cấu hình lưu đệm, tải ảnh hay mã chạy trên trang, lưu mốc và thử trên phạm vi nhỏ. Sau thay đổi, mở menu, ảnh sản phẩm và thao tác liên hệ để kiểm tra việc khách cần làm vẫn hoạt động. Một điểm tăng không bù cho nút đặt hàng bị hỏng.
Khi nào xem lại?
Dùng lần chạy mô phỏng để đối chiếu thay đổi kỹ thuật gần thời điểm sửa. Với dữ liệu người dùng thực, theo dõi dần khi các lượt ghé mới đi vào kỳ dữ liệu. Nếu muốn nói trải nghiệm cả website đã tốt lên, cần nhiều bằng chứng hơn một URL và một lần chạy.
À, trước khi sửa cánh cửa, mình cần biết người khách đang chờ cửa mở, chờ người trả lời hay đang vấp vì bậc thềm xê dịch. Báo cáo có ích khi nó giúp gọi đúng việc ấy.
Đọc tiếp trong Mùa 4
Chuyên đề 38: Nén ảnh, chọn kích thước và viết văn bản thay thế sao cho đúng việc.
Các chuyên đề Mùa 4 · Bản đồ Hiểu Google
Đối chiếu tài liệu gốc ngày 29/10/2026. Câu chuyện, số liệu và tình huống tự đặt được dùng để giải thích, không phải kết quả đã đo trên website người đồng hành. Ảnh có nguồn và giới hạn sử dụng ngay dưới hình; giao diện có thể khác theo phiên bản, ngôn ngữ hoặc tài khoản.
