PageSpeed Insights: đọc báo cáo để sửa đúng chỗ
PageSpeed Insights không phải bài thi mà website phải đạt 100 điểm. Báo cáo này là tập hợp của hai loại bằng chứng khác nhau: dữ liệu người dùng thực tế và kết quả mô phỏng trong phòng lab.
Nếu chỉ nhìn điểm Performance rồi sửa các đề xuất màu đỏ, đội SEO rất dễ tốn nhiều giờ tối ưu những chi tiết ít tác động, trong khi LCP, INP hoặc CLS của nhóm người dùng thật vẫn không cải thiện. Cách làm đúng là đọc từng lớp dữ liệu, xác định vấn đề có ảnh hưởng đến trải nghiệm và doanh thu hay không, sau đó mới chọn việc cần sửa.
PageSpeed Insights đang đo hai loại dữ liệu nào?
Dữ liệu thực địa: website đang chạy thế nào với người dùng thật?
Phần dữ liệu thực địa, thường hiển thị trong mục Chrome UX Report, phản ánh trải nghiệm của người dùng Chrome đã truy cập trang trong khoảng thời gian thu thập gần nhất. Đây là dữ liệu của nhiều thiết bị, mạng và vị trí khác nhau, không phải kết quả từ một lần bạn tự mở trang trên máy văn phòng.
Ba chỉ số Core Web Vitals cần chú ý gồm:
- LCP: thời gian phần nội dung lớn nhất trong vùng nhìn thấy được hiển thị. Mức tốt là không quá 2,5 giây.
- INP: độ trễ từ lúc người dùng tương tác đến khi giao diện phản hồi hoàn chỉnh. Mức tốt là không quá 200 mili giây.
- CLS: mức độ xê dịch bất ngờ của bố cục. Mức tốt là không quá 0,1.
Các ngưỡng trên là ngưỡng đánh giá Core Web Vitals do Chrome Developers công bố. Báo cáo thường phân loại theo tỷ lệ trải nghiệm tốt, cần cải thiện và kém ở phân vị thứ 75. Vì vậy, một số người dùng có thể tải trang rất nhanh nhưng website vẫn chưa đạt nếu một tỷ lệ đáng kể người dùng khác gặp trải nghiệm kém.
Điểm quan trọng: dữ liệu thực địa có độ trễ. Khi bạn triển khai bản sửa hôm nay, báo cáo không nhất thiết thay đổi ngay ngày mai. Dữ liệu CrUX được tổng hợp theo cửa sổ thời gian trượt, nên cần theo dõi thêm trong các lần cập nhật tiếp theo. Nếu website có ít lưu lượng hoặc không đủ dữ liệu, PSI có thể không hiển thị số liệu thực địa ở cấp URL.
Dữ liệu lab: một bài kiểm tra có điều kiện cố định
Dữ liệu lab do Lighthouse chạy trong môi trường mô phỏng. Nó dùng cấu hình thiết bị, tốc độ mạng và trạng thái tải trang được chuẩn hóa tương đối để tạo ra một lần kiểm tra có thể lặp lại. Lab hữu ích khi debug vì bạn có thể sửa mã, chạy lại và so sánh ngay.
Nhưng lab không trả lời đầy đủ câu hỏi “người dùng thật đang gặp gì?”. Kết quả có thể thay đổi theo máy chủ, thời điểm chạy, quảng cáo, CDN, cache, cookie, script bên thứ ba và tình trạng mạng tại lúc kiểm tra. Một URL có lab tốt vẫn có thể có dữ liệu thực địa kém nếu người dùng chủ yếu truy cập bằng điện thoại đời cũ hoặc mạng di động chậm.
Trong lab, bạn có thể gặp các chỉ số như First Contentful Paint, Largest Contentful Paint, Total Blocking Time và Cumulative Layout Shift. TBT đặc biệt hữu ích để tìm JavaScript làm nghẽn luồng chính, nhưng không nên dùng TBT để thay thế INP khi đánh giá trải nghiệm người dùng thật.
Thứ tự đọc báo cáo để không sửa theo cảm tính
- Đọc dữ liệu thực địa trước. Xem LCP, INP và CLS đang ở mức nào, tỷ lệ “tốt” là bao nhiêu và vấn đề xuất hiện ở URL cụ thể hay toàn bộ origin.
- Xác định loại trang bị ảnh hưởng. Trang sản phẩm, danh mục, bài viết, trang chủ và trang thanh toán thường có cấu trúc DOM, ảnh và script khác nhau. Đừng lấy một URL làm đại diện cho toàn bộ website nếu template không giống nhau.
- Đọc lab để tìm nguyên nhân. Dùng waterfall, phần tử LCP, thời gian chặn luồng chính và các tài nguyên chưa dùng để tìm điểm nghẽn có thể sửa được.
- Ưu tiên theo tác động kinh doanh. Một lỗi làm chậm trang có nhiều lượt truy cập hoặc nằm ngay trước bước chuyển đổi thường đáng sửa trước một cảnh báo chỉ ảnh hưởng đến vài trang ít traffic.
- Đo lại sau khi thay đổi. Lab dùng để kiểm tra nhanh sau triển khai; dữ liệu thực địa dùng để xác nhận trải nghiệm đã cải thiện trong thực tế.
Có thể dùng một cách chấm ưu tiên đơn giản: Ưu tiên = phạm vi ảnh hưởng x mức độ nghiêm trọng x khả năng sửa. Đây không phải công thức của PSI mà là cách lập backlog. Ví dụ, LCP kém trên 70% URL doanh thu cao đáng được xếp trước một cảnh báo tối ưu ảnh trên một bài viết cũ chỉ có vài lượt truy cập mỗi tháng.
Bảng cảnh báo phổ biến, nguyên nhân thật và cách sửa
| Cảnh báo trong PSI | Nguyên nhân thường gặp | Cách sửa đúng chỗ |
|---|---|---|
| Largest Contentful Paint cao | Ảnh hero quá lớn, máy chủ phản hồi chậm, CSS chặn hiển thị hoặc phần tử LCP bị tải muộn | Xác định đúng phần tử LCP; nén và đổi kích thước ảnh, dùng định dạng phù hợp, preload có chọn lọc, cải thiện TTFB và loại CSS chặn cần thiết |
| Reduce unused JavaScript | Gói mã chứa nhiều tính năng không dùng trên trang hoặc plugin tải script toàn site | Chia nhỏ bundle, chỉ tải theo template, trì hoãn script không cần cho màn hình đầu tiên; không xóa mù quáng thư viện đang phục vụ chức năng quan trọng |
| Minimize main-thread work hoặc TBT cao | JavaScript dài, tác vụ đồng bộ, thư viện theo dõi và widget bên thứ ba cùng chạy lúc đầu | Chia tác vụ dưới khoảng 50 mili giây, trì hoãn widget, loại mã thừa và giảm số lần re-render; kiểm tra lại INP sau triển khai |
| Image elements do not have explicit width and height | Thiếu thuộc tính kích thước hoặc CSS không giữ tỷ lệ khung hình | Khai báo width và height theo tỷ lệ thật, dùng aspect-ratio khi cần; kiểm tra cả ảnh chèn qua CMS |
| Eliminate render-blocking resources | CSS và JavaScript đồng bộ nằm trên đường hiển thị ban đầu | Inline phần CSS thiết yếu ở mức hợp lý, trì hoãn CSS không cần ngay và đặt script với defer khi tương thích |
| Layout shifts hoặc CLS cao | Ảnh, quảng cáo, iframe không có vùng giữ chỗ; font thay thế làm chữ đổi kích thước | Giữ không gian cố định, khai báo kích thước media, cấu hình font fallback và tránh chèn nội dung phía trên phần đang đọc |
Bảng trên cần được đọc cùng ngữ cảnh. “Reduce unused JavaScript” không có nghĩa là xóa mọi mã chưa chạy trong lần kiểm tra. Có những đoạn chỉ chạy sau khi người dùng mở bộ lọc, điền biểu mẫu hoặc thanh toán. Việc cần làm là không tải chúng quá sớm, không phải loại bỏ chức năng.
Đọc LCP, INP và CLS theo nguyên nhân chứ không theo màu
LCP: đừng chỉ nén ảnh
Khi LCP vượt 2,5 giây, hãy xác định phần tử nào được Lighthouse đánh dấu là LCP. Nếu đó là ảnh hero, cần xem đồng thời kích thước file, thời gian chờ máy chủ, thời điểm request bắt đầu và việc ảnh có bị lazy-load nhầm hay không. Ảnh nằm trong màn hình đầu tiên thường không nên đặt loading="lazy", vì trình duyệt sẽ trì hoãn một tài nguyên cần thiết.
Nếu LCP là tiêu đề hoặc khối văn bản, nguyên nhân có thể nằm ở CSS, font web hoặc HTML được máy chủ trả về chậm. Preload tất cả font và ảnh không phải cách mặc định đúng. Preload quá nhiều tài nguyên sẽ tranh băng thông với HTML và tài nguyên thiết yếu khác. Chỉ preload tài nguyên chắc chắn nằm trên đường hiển thị đầu tiên.
INP: tập trung vào thời điểm người dùng tương tác
INP trên 200 mili giây thường liên quan đến JavaScript xử lý sự kiện, không chỉ thời gian tải ban đầu. Hãy kiểm tra thao tác gây chậm: mở menu, nhập vào ô tìm kiếm, chọn bộ lọc hay thêm sản phẩm vào giỏ. Một trang có điểm lab cao nhưng INP thực địa thấp vẫn cần xử lý ở các luồng tương tác đó.
Các hướng sửa thực tế gồm chia nhỏ tác vụ dài, giảm số lượng phần tử phải cập nhật, tránh render lại toàn bộ danh sách và trì hoãn công việc không liên quan sau khi tương tác hoàn tất. Nếu widget chat hoặc công cụ cá nhân hóa chiếm nhiều thời gian, hãy thử tải sau khi nội dung chính sẵn sàng thay vì nạp ngay từ đầu.
CLS: sửa bố cục trước khi sửa hiệu ứng
CLS không chỉ đến từ quảng cáo. Ảnh sản phẩm không có kích thước, banner khuyến mãi được chèn sau khi tải, font web đổi chiều rộng chữ và component chưa có trạng thái loading đều có thể làm nội dung nhảy. Hãy ghi lại vị trí dịch chuyển và phần tử gây ra nó, thay vì chỉ thêm CSS ngẫu nhiên cho đến khi điểm giảm.
Điểm 100 không phải mục tiêu
Điểm Performance của Lighthouse là điểm tổng hợp từ nhiều chỉ số lab với trọng số và cách tính có thể thay đổi theo phiên bản công cụ. Nó hữu ích để phát hiện xu hướng trong cùng một điều kiện đo, nhưng không phải KPI kinh doanh và cũng không phải bằng chứng rằng mọi người dùng đều có trải nghiệm tốt.
Có những trường hợp không nên cố đạt 100:
- Website cần công cụ chat, cá nhân hóa, đo lường chuyển đổi hoặc thanh toán; xóa chúng chỉ để tăng điểm có thể làm hỏng chức năng hoặc mất dữ liệu quan trọng.
- Ảnh chất lượng cao là một phần của trải nghiệm bán hàng; giảm quá mức để đạt điểm có thể làm giảm khả năng đánh giá sản phẩm.
- Trang quản trị, trang đăng nhập nội bộ hoặc URL gần như không có traffic không nên được ưu tiên trước các landing page tạo doanh thu.
- Cảnh báo chỉ xuất hiện trong một lần lab, không liên quan đến Core Web Vitals và không có tác động quan sát được thì chưa chắc đáng bỏ nhiều ngày công để xử lý.
Mục tiêu hợp lý hơn là đưa phần lớn người dùng vào vùng trải nghiệm tốt: LCP không quá 2,5 giây, INP không quá 200 mili giây và CLS không quá 0,1; đồng thời bảo toàn khả năng chuyển đổi, khả năng thu thập dữ liệu và chức năng của website. Điểm số có thể là tín hiệu phụ, còn dữ liệu thực địa và tác động đến người dùng mới là căn cứ chính.
Lập kế hoạch sửa và đo lại sau triển khai
Với một website đang hoạt động, nên chia công việc thành ba lớp. Lớp thứ nhất là lỗi có tác động rộng và rủi ro thấp: khai báo kích thước ảnh, sửa lazy-load sai, bật cache phù hợp, giảm tài nguyên chặn hiển thị. Lớp thứ hai là thay đổi cần phối hợp với đội phát triển: tách bundle, thay đổi cách render, tối ưu truy vấn và cải thiện thời gian phản hồi máy chủ. Lớp thứ ba là quyết định sản phẩm: bỏ widget, thay công cụ theo dõi hoặc chấp nhận chi phí tải để giữ một chức năng.
Ước lượng ban đầu nên tính theo template thay vì theo số URL. Một lỗi ở module dùng chung có thể cần 0,5–1 ngày công để xác định và 1–3 ngày công để triển khai, kiểm thử trên thiết bị và theo dõi. Đây là cách lập kế hoạch nội bộ, không phải mức giá cố định cho mọi dự án. Nếu cần thay đổi kiến trúc JavaScript hoặc hệ thống máy chủ, thời gian có thể dài hơn đáng kể.
Sau mỗi đợt sửa, chạy lại lab trên cùng nhóm URL, cùng loại thiết bị và nhiều thời điểm khác nhau. Không kết luận từ một lần đo duy nhất. Với dữ liệu thực địa, ghi lại ngày triển khai, nhóm template, LCP, INP, CLS và tỷ lệ trải nghiệm tốt; sau đó chờ chu kỳ dữ liệu mới trước khi đánh giá hiệu quả.
Cuối cùng, hãy lưu cả phiên bản báo cáo trước và sau thay đổi. Nếu điểm tăng nhưng INP thực địa không cải thiện, vấn đề có thể nằm ở nhóm người dùng khác, script chỉ chạy sau tương tác hoặc dữ liệu chưa kịp phản ánh bản sửa. Đọc PageSpeed Insights đúng nghĩa là nối kết báo cáo với hành vi thật của người dùng, không phải chạy đua với một con số màu xanh.
Đọc thêm
- Audit website — triển khai trọn gói, có cam kết đo lường bằng số.
- Dịch vụ seo tổng thể — xem phạm vi công việc và mức đầu tư.
- Featured Snippet: Cách Chiếm Vị Trí Số 0 Trên Google
- Guest Post: Đặt Bài Đúng Cách Và Cách Nhận Diện Site Rác
Cần làm thật phần “pagespeed insights” này trên site của bạn?
Gửi tên miền, chúng tôi chạy audit và trả về danh sách việc theo thứ tự tác động — kèm số đo hiện trạng, không phải nhận định cảm tính.
