Trả lời nhanh: PageSpeed Insights có hai phần hay bị đọc lẫn: field data (Core Web Vitals từ người dùng Chrome thật 28 ngày, thứ Google thật sự dùng đánh giá) và lab data (Lighthouse giả lập một lần chạy, sinh ra con điểm 0-100 nổi tiếng). Đọc đúng: ưu tiên field data đạt/không đạt ba chỉ số LCP, INP, CLS; điểm lab chỉ là la bàn gợi ý chỗ sửa. Điểm 70 mà field data xanh vẫn hơn điểm 95 mà field data đỏ.
PageSpeed Insights là công cụ bị hiểu sai nhiều nhất giới làm web: người người đua điểm 100, trong khi Google chưa từng xếp hạng bằng con điểm đó. Bài này dạy đọc báo cáo như người trong nghề: phần nào là dữ liệu thật, phần nào là giả lập, sửa gì trước để khách và Google cùng cảm nhận được, và khuyến nghị nào nên mỉm cười bỏ qua.
- Field data (CrUX, 28 ngày, người dùng thật) mới là thứ ảnh hưởng xếp hạng, không phải điểm Lighthouse
- Ba chỉ số cần đạt: LCP <2.5s · INP <200ms · CLS <0.1, nhìn màu xanh/cam/đỏ phần đầu báo cáo
- Thứ tự sửa ăn điểm thật: TTFB/máy chủ → ảnh LCP → script chặn render → font/layout
- Trang ít traffic không có field data, khi đó mới phải sống bằng lab, đo nhiều lần lấy xu hướng
Hai tầng dữ liệu - và tầng nào Google dùng
Mở kết quả PSI, phần trên cùng "Khám phá những gì người dùng thực tế của bạn đang trải nghiệm", đó là field data từ Chrome UX Report: người dùng Chrome thật, mạng thật, máy thật, gom 28 ngày. Google dùng đúng tầng này (theo URL hoặc nhóm trang) trong tín hiệu trải nghiệm trang. Phần dưới với con điểm to 0-100 là lab data: Lighthouse chạy giả lập một lần trên máy chủ của Google với cấu hình mạng cố định, công cụ chẩn đoán tốt, thước đo xếp hạng thì không. Hệ quả: đừng hoảng vì điểm lab dao động giữa hai lần bấm, giả lập vốn nhiễu; hãy nhìn field data theo tháng.
Ba chỉ số Core Web Vitals - hiểu bằng cảm giác người dùng
- LCP (Largest Contentful Paint, chuẩn <2.5s): "bao lâu thì thấy nội dung chính?", thường là ảnh hero hoặc khối chữ lớn đầu trang.
- INP (Interaction to Next Paint, <200ms): "bấm có sướng tay không?", đo độ trễ phản hồi mọi cú bấm/gõ trong suốt phiên.
- CLS (Cumulative Layout Shift, <0.1): "trang có nhảy lung tung không?", nút vừa định bấm bỗng trượt chỗ vì quảng cáo chen vào.
Ba con số này chính là ba lời phàn nàn phổ biến nhất của khách: chậm hiện, bấm đơ, giật cục.
Thứ tự sửa theo tác động thật
- Nền máy chủ (TTFB): LCP không thể đẹp trên TTFB xấu, byte đầu 800ms thì ảnh hero 2.5s là nhiệm vụ bất khả. Cache + máy khỏe + gần khách (toàn bộ bài TTFB áp vào đây), sửa móng trước khi sơn tường.
- Ảnh LCP: đúng kích cỡ hiển thị, WebP, KHÔNG lazy-load phần tử LCP, thêm fetchpriority=high, bốn thao tác cắt LCP nhiều nhất sau móng.
- Script chặn render: JS bên thứ ba (chat widget, tracking chồng chất) đẩy xuống defer/lazy sau tương tác, đòn chính cho INP.
- Font và layout: font-display: swap, khai width/height cho ảnh và khối quảng cáo, dứt điểm CLS.
Những khuyến nghị nên đọc bằng nụ cười
- "Giảm JavaScript không dùng" chỉ ra bundle của framework, cắt được thì tốt, nhưng đừng đập app để đổi 3 điểm lab.
- "Serve ảnh thế hệ mới" cho ảnh 4KB, tiết kiệm 1KB, bỏ qua.
- Cảnh báo cache bên thứ ba (script của chính Google Analytics), bạn không sửa được đồ của người khác.
- Đua điểm 100 lab trong khi field data đã xanh cả ba, thời gian đó đi bán hàng có lời hơn.
Quy trình thực dụng mỗi tháng 15 phút
- Chạy PSI cho 3-5 trang tiền tệ (chủ, sản phẩm, thanh toán), ghi field data ba chỉ số.
- Chỉ số nào cam/đỏ → sửa theo thứ tự mục trên, một thứ một lần.
- Đợi chu kỳ 28 ngày cập nhật, field data đổi chậm, đó là bình thường, đừng sửa dồn dập rồi không biết đòn nào ăn.
- Theo dõi tập trung trong Search Console mục Core Web Vitals, nhìn cả site một màn hình.
Ba ngưỡng chính xác của Core Web Vitals
| Chỉ số | Đạt | Cần cải thiện | Kém | Đo cái gì |
|---|---|---|---|---|
| LCP, thời gian hiện phần tử lớn nhất | dưới 2,5 giây | 2,5 tới 4 giây | trên 4 giây | Cảm giác trang đã tải xong |
| INP, độ trễ khi tương tác | dưới 200 ms | 200 tới 500 ms | trên 500 ms | Bấm nút bao lâu thì trang phản hồi |
| CLS, độ xê dịch bố cục | dưới 0,1 | 0,1 tới 0,25 | trên 0,25 | Nội dung có nhảy khi đang đọc không |
Google đánh giá theo phân vị thứ 75 của người dùng thật trong 28 ngày, nghĩa là 75% lượt truy cập phải đạt ngưỡng, không phải trung bình. Đây là lý do một vài lượt truy cập chậm từ mạng yếu không kéo cả trang xuống, nhưng nếu phần lớn khách dùng điện thoại và mạng di động thì con số của bạn sẽ khác hẳn khi đo bằng máy tính văn phòng.
Chỉ số INP thay thế FID từ tháng 3 năm 2024. INP khó đạt hơn FID nhiều vì nó đo toàn bộ độ trễ của mọi tương tác, không chỉ tương tác đầu tiên. Trang nào nặng JavaScript thường tụt hạng ở chỉ số này.
Sửa từ thời gian trả byte đầu tiên
- Thời gian máy chủ trả byte đầu tiên. Đây là nền của mọi thứ. Trên 600 ms là mọi tối ưu phía trình duyệt đều bị kéo lùi. Nguyên nhân thường gặp: máy chủ ở xa người dùng, truy vấn cơ sở dữ liệu chậm, không có bộ nhớ đệm trang.
- Ảnh của phần tử lớn nhất. Với đa số trang, đó là ảnh đầu trang. Ba việc: chuyển sang định dạng nén tốt, khai đúng kích thước, và thêm thuộc tính ưu tiên tải sớm cho riêng ảnh đó. Đừng đặt tải trễ cho ảnh đầu trang, đây là lỗi rất phổ biến.
- Mã chặn hiển thị. Các tệp mã và kiểu dáng nằm ở đầu trang làm trình duyệt phải dừng. Chuyển sang tải bất đồng bộ hoặc dời xuống cuối.
- Phông chữ và kích thước cố định. Khai sẵn kích thước cho ảnh và khung quảng cáo để trang không nhảy, và dùng thuộc tính hiển thị phông để chữ hiện ngay bằng phông dự phòng.
Trang chưa có dữ liệu người dùng thật thì làm sao
Trang mới hoặc ít khách sẽ hiện dòng thông báo không đủ dữ liệu. Khi đó:
- Dùng phần Lighthouse nhưng chạy ít nhất ba lần rồi lấy giá trị giữa, vì mỗi lần chạy dao động khá nhiều.
- Cài thư viện đo chỉ số ngay trên trang của bạn và gửi số liệu về nơi lưu trữ riêng. Cách này cho dữ liệu người dùng thật của chính bạn, không phải chờ đủ mẫu để lên báo cáo chung.
- Xem báo cáo Core Web Vitals trong Google Search Console. Nó gom nhóm các trang giống nhau nên có dữ liệu sớm hơn so với xem từng địa chỉ.
Quy trình mỗi tháng, mười lăm phút
- Mở báo cáo Core Web Vitals trong Search Console, xem số trang ở nhóm đạt có tăng không, tách riêng điện thoại và máy tính.
- Chọn một nhóm trang đang kém, lấy một địa chỉ đại diện đưa vào công cụ đo.
- Sửa đúng một thứ theo thứ tự ưu tiên ở trên. Đừng sửa năm thứ cùng lúc, sẽ không biết cái nào có tác dụng.
- Đợi 28 ngày rồi xem lại. Dữ liệu người dùng thật cần ngần đó thời gian để phản ánh thay đổi, nên đừng đo lại sau một ngày rồi kết luận.
Về những khuyến nghị nên bỏ qua: các mục về mã không dùng tới trong thư viện bên thứ ba, các mục về bộ nhớ đệm của tài nguyên do bên thứ ba phục vụ, và điểm số phần trợ năng nếu trang của bạn vốn đã kiểm bằng công cụ chuyên dụng. Chúng làm điểm xấu nhưng không ảnh hưởng tới ba chỉ số Google thật sự dùng.
Câu hỏi thường gặp
Điểm PageSpeed bao nhiêu là đủ?
Câu hỏi đúng là 'field data đạt chưa': LCP xanh, INP xanh, CLS xanh là đủ với Google. Điểm lab 70-80 với field data xanh hoàn toàn ổn; ám ảnh con 100 là trò chơi cho vui, không phải SEO.
Sao trang tôi không có field data?
Traffic chưa đủ để CrUX gom mẫu. Khi đó sống bằng lab: chạy 3-5 lần lấy xu hướng, và tự đo thêm TTFB bằng curl từ mạng Việt Nam, hai thứ đó đủ định hướng sửa.
Mobile và desktop chênh nhau nhiều, tin bên nào?
Mobile, Google đánh giá mobile-first và lab mobile giả lập máy yếu + mạng chậm nên luôn thấp hơn. Sửa cho mobile đạt là desktop tự đẹp.
Field data xanh rồi thì thôi tối ưu?
Giữ nhịp theo dõi tháng một lần là đủ, thêm plugin, thêm script quảng cáo là con số lại trôi. Tối ưu tốc độ là chế độ ăn, không phải đợt detox.
