Muốn kiểm tra tốc độ website, hãy mở PageSpeed Insights, nhập địa chỉ trang cần đo, xem riêng kết quả điện thoại và máy tính, rồi đọc LCP, INP, CLS trước khi quyết định sửa. Một con số màu xanh không đủ để kết luận toàn bộ website nhanh, cũng như một điểm thấp chưa nói rõ nguyên nhân nằm ở đâu.
Chủ doanh nghiệp cần nhớ: Kiểm tra ít nhất trang chủ, trang dịch vụ hoặc sản phẩm quan trọng và trang liên hệ/đặt hàng nếu có. Ưu tiên dữ liệu người dùng thật khi đủ mẫu; dùng kết quả mô phỏng để tìm nguyên nhân. Sau khi sửa phải thử lại nút liên hệ, biểu mẫu và thanh toán thuộc phạm vi website, không chỉ xem điểm số.
Cách kiểm tra tốc độ website bằng PageSpeed Insights trong 5 bước
- 1. Mở PageSpeed Insights: dán URL cụ thể cần kiểm tra, ví dụ trang dịch vụ hoặc sản phẩm, rồi bấm phân tích. Không chỉ đo trang chủ.
- 2. Xem riêng Mobile và Desktop: điện thoại và máy tính có điều kiện dùng khác nhau. Nếu khách chủ yếu dùng điện thoại, hãy ưu tiên đọc kết quả điện thoại.
- 3. Kiểm tra phần trải nghiệm người dùng thật: nếu có, xem Core Web Vitals, ba chỉ số LCP, INP, CLS và báo cáo đang hiển thị dữ liệu URL này hay toàn bộ tên miền.
- 4. Đọc kết quả mô phỏng và phần chẩn đoán: xem ảnh lớn, tài nguyên tải chậm, mã JavaScript gây nghẽn, bố cục nhảy hoặc phản hồi máy chủ. Đây là gợi ý điều tra, không phải mọi mục đều phải sửa.
- 5. Ghi lại và bàn giao: lưu URL, ngày đo, chế độ thiết bị, chỉ số chưa đạt, kết quả chẩn đoán và chức năng quan trọng cần thử sau khi sửa.
Nếu PageSpeed chưa có dữ liệu người dùng thật của trang, không có nghĩa website nhanh hoặc chậm. Công cụ có thể dùng dữ liệu chung của tên miền nếu đủ mẫu; nếu vẫn thiếu, chỉ sử dụng kết quả mô phỏng để điều tra và ghi rõ giới hạn. Xem giải thích chính thức của Google về PageSpeed.
Dữ liệu người dùng thật khác kết quả mô phỏng như thế nào?
- Dữ liệu thực tế (field data): phản ánh trải nghiệm từ người dùng Chrome đủ điều kiện, thường tổng hợp trong 28 ngày gần nhất. Giá trị báo cáo là tổng hợp ở phân vị 75, không phải kết quả của lần bạn vừa bấm kiểm tra.
- Dữ liệu mô phỏng (lab data): Lighthouse chạy trong điều kiện giả lập tại thời điểm đo, giúp tìm phần nào làm trang chậm và thử nghiệm thay đổi.
- Điểm hiệu năng Lighthouse: điểm tổng hợp trong báo cáo mô phỏng. Theo tài liệu PageSpeed, 90–100 là mức tốt, 50–89 cần cải thiện, dưới 50 là kém trong cách chấm của công cụ; không phải điểm xếp hạng Google.
Hai nhóm số liệu có thể khác nhau vì người dùng thực tế sử dụng thiết bị, mạng và cách tương tác đa dạng. Hãy ghi rõ PageSpeed đang cho số liệu ở cấp URL hay cấp tên miền. Nếu dữ liệu người thật chưa xuất hiện hoặc chưa thay đổi ngay sau khi sửa, không nên kết luận công việc đã thất bại.
Ba chỉ số Core Web Vitals cần xem trước
- LCP — tải phần nội dung lớn: tốt khi không quá 2,5 giây. Nếu cao, kiểm tra ảnh chính, máy chủ, bộ nhớ đệm và thứ tự tải nội dung.
- INP — độ phản hồi sau thao tác: tốt khi không quá 200 mili giây. Nếu cao, kiểm tra mã xử lý khi bấm nút, mở menu, nhập biểu mẫu và mã của bên thứ ba.
- CLS — mức xê dịch bố cục ngoài ý muốn: tốt khi không quá 0,1. Nếu cao, kiểm tra ảnh chưa dành sẵn kích thước, quảng cáo, phông chữ hoặc nội dung được chèn muộn.
Lưu ý cách đọc: các ngưỡng Core Web Vitals dùng để đánh giá dữ liệu người dùng thật ở phân vị 75, xem riêng điện thoại và máy tính khi có đủ dữ liệu. Lighthouse chạy mô phỏng có thể đo LCP, CLS và các chỉ số chẩn đoán như TBT; không nên coi TBT là số INP thực tế. Ba chỉ số cần đọc cùng nhau, không chỉ lấy số tốt nhất.
Google khuyến nghị cải thiện Core Web Vitals, nhưng đạt điểm PageSpeed 100 hoặc ba chỉ số tốt không bảo đảm thứ hạng SEO. Nội dung, mức độ phù hợp và trải nghiệm tổng thể cũng quan trọng. Xem hướng dẫn của Google Search Central về trải nghiệm trang.
Kết quả xấu: xác định nhóm nguyên nhân trước khi sửa
- LCP chậm: tìm phần tử hiển thị lớn trong chẩn đoán; có thể là ảnh đầu trang, văn bản lớn, máy chủ hoặc tài nguyên chặn hiển thị. Chỉ tối ưu đúng thành phần sau khi xác định.
- INP kém: xem tác vụ JavaScript dài, tương tác chính và mã của bên thứ ba. Không xóa script một cách mù quáng vì có thể làm hỏng biểu mẫu hoặc đo lường.
- CLS cao: xem ảnh, video, quảng cáo, phông chữ và nội dung chèn sau khi trang hiển thị. Ưu tiên chỗ gây nhảy bố cục thực tế.
- TTFB cao (thời gian chờ phản hồi ban đầu): khoanh vùng máy chủ, cache, chuyển hướng, dữ liệu và mạng; không vội kết luận phải đổi hosting.
- Trang quá nặng: kiểm tra dung lượng ảnh, video tự tải, font và thư viện không dùng, nhưng vẫn phải giữ chức năng và nội dung quan trọng.
Đây là những giả thuyết cần kiểm chứng, không phải chẩn đoán chắc chắn chỉ từ màu đỏ của chỉ số. Một ảnh lớn trong báo cáo chưa chắc là nguyên nhân chính nếu tác vụ JavaScript mới gây chậm phần người dùng quan tâm.
Ví dụ: Trang dịch vụ bị tải chậm trên điện thoại
Ví dụ minh họa, không phải số đo thực tế của websitehcm.com: PageSpeed cho thấy LCP chưa tốt và gợi ý ảnh lớn ở đầu trang. Người phụ trách cần xác minh ảnh đó có phải phần tử LCP không, cách tải ảnh và việc ảnh bị trì hoãn; sau đó mới nén đúng kích thước, chọn định dạng phù hợp hoặc điều chỉnh ưu tiên tải.
Khi đo lại, cần kiểm tra ảnh vẫn rõ, nội dung không thiếu, nút liên hệ và biểu mẫu hoạt động. Không dùng một lần chạy nhanh hơn để kết luận mọi khách hàng đều đã thấy tốt hơn.
Cách sửa và kiểm tra lại mà không làm hỏng website
- Ghi nhận trước khi sửa: lưu URL, chỉ số, tình trạng thiết bị, bản theme/plugin và các chức năng phải được bảo toàn.
- Chọn nhóm nguyên nhân có bằng chứng: ví dụ ảnh chính, script, bố cục hoặc máy chủ. Không cài chồng nhiều plugin tăng tốc cùng lúc.
- Có phương án khôi phục: thử trên môi trường phù hợp hoặc chuẩn bị bản sao lưu; đặc biệt cẩn thận với giỏ hàng, thanh toán, đăng nhập và dữ liệu khách hàng.
- Đo lại trong điều kiện tương đương: chạy vài lần nếu kết quả mô phỏng biến động; đối chiếu cùng URL và chế độ thiết bị.
- Kiểm tra chức năng rồi theo dõi dữ liệu thực tế: điểm đẹp hơn nhưng form không gửi được là không đạt. Dữ liệu 28 ngày phản ánh dần trải nghiệm thực tế chứ không thay đổi tức thì.
Checklist giao việc cho kỹ thuật viên hoặc đơn vị hosting
- Trang cần sửa: URL cụ thể, vai trò kinh doanh (trang dịch vụ, sản phẩm, liên hệ) và thiết bị ưu tiên.
- Bằng chứng đo: liên kết báo cáo, ngày đo, chế độ Mobile/Desktop, số liệu URL hay toàn tên miền, dữ liệu thực tế hay mô phỏng.
- Vấn đề chính: chỉ số nào chưa đạt và ảnh, mã, máy chủ hoặc bố cục nào cần kiểm tra thêm.
- Phạm vi thay đổi: ai xử lý, rủi ro ảnh hưởng giao diện/chức năng, cách sao lưu và quay lại bản cũ.
- Kết quả nghiệm thu: đo lại, kiểm tra nút liên hệ, biểu mẫu, giao dịch nếu có và thời điểm đối chiếu dữ liệu người dùng thật.
Nếu biết nguyên nhân, xem 10 cách tăng tốc website để chọn hướng khắc phục. Nếu nghi máy chủ, tham khảo hosting ảnh hưởng đến SEO như thế nào; nếu tình trạng chậm lặp lại sau cập nhật hoặc giờ cao điểm, đọc quản lý hiệu năng và độ ổn định website. Hướng dẫn kiểm tra báo cáo này không thay thế quy trình xử lý kỹ thuật chi tiết.
Khi nào nên xem Search Console hoặc nhờ chuyên gia?
Với chủ website, báo cáo Core Web Vitals trong Google Search Console giúp theo dõi nhóm URL và vấn đề trải nghiệm theo thời gian, không thay cho chẩn đoán của PageSpeed cho từng trang. Nếu nhiều trang quan trọng có vấn đề, máy chủ thường chậm hoặc thay đổi tối ưu có thể ảnh hưởng thanh toán/dữ liệu, nên nhờ người kỹ thuật kiểm tra trước khi sửa.
Câu hỏi thường gặp
PageSpeed đạt 100 điểm có nghĩa website SEO tốt không?
Không. Đây là điểm đánh giá hiệu năng mô phỏng trong phạm vi công cụ, không bảo đảm Core Web Vitals thực tế, thứ hạng SEO hay doanh thu.
Vì sao không có dữ liệu người dùng thật trong PageSpeed?
Một URL hoặc tên miền có thể chưa đủ mẫu dữ liệu phù hợp. Nếu PageSpeed hiển thị dữ liệu toàn tên miền thì không nên xem đó là bằng chứng riêng cho trang vừa kiểm tra.
Vì sao tôi vừa tối ưu nhưng Core Web Vitals chưa đổi?
Dữ liệu người dùng thật được tổng hợp từ 28 ngày gần nhất; sau thay đổi, hãy dùng kết quả mô phỏng kiểm tra trước, rồi tiếp tục quan sát dữ liệu thực tế khi đủ mẫu.
Bao lâu nên kiểm tra tốc độ website?
Kiểm tra sau những thay đổi đáng kể như giao diện, plugin, máy chủ, mã quảng cáo; theo dõi định kỳ phù hợp website và những trang ảnh hưởng khách hàng. Không có một lịch cố định cho mọi doanh nghiệp.
Kết luận
Kiểm tra tốc độ website đúng cách là chọn trang quan trọng, đọc đúng loại dữ liệu, tìm nguyên nhân, sửa có kiểm soát và đo lại. Bắt đầu bằng PageSpeed Insights, phân biệt trải nghiệm người dùng thật với đo mô phỏng và ưu tiên chức năng khách cần hoàn thành. Mục tiêu không phải chỉ tạo điểm xanh, mà là website hoạt động nhanh, ổn định và dễ sử dụng.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.