Kiểm tra tốc độ website: hiểu chỉ số trước khi sửa

Trang mở ra khá nhanh, nhưng bấm menu phải chờ. Trang khác hiện chữ sớm, rồi ảnh xuất hiện đẩy nút liên hệ xuống ngay lúc khách định chạm.

Cả hai đều có thể khiến người dùng khó chịu, dù người chăm website chỉ nói chung: “Trang hơi chậm”.

Tốc độ website không nằm trong một con số duy nhất. Mình cần biết nội dung quan trọng hiện lúc nào, thao tác có phản hồi kịp không và bố cục có ổn định không.

Bắt đầu bằng việc khách đang cố làm

Với một trang đèn, khách có thể muốn nhìn ảnh, xem kích thước, mở các mẫu khác hoặc gửi yêu cầu. Hãy chọn một việc như vậy rồi thử trên điện thoại.

Ghi điều thấy được: ảnh chính xuất hiện chậm, nút phản hồi trễ hay chữ bị đẩy nhảy. Ghi nhận này chưa xác định nguyên nhân, nhưng giúp mình biết cần đọc chỉ số nào.

Nếu bắt đầu từ một điểm tổng rồi bật hết tùy chọn “tăng tốc”, bạn có thể làm nhanh một chỗ nhưng khiến nút chọn mẫu hoặc biểu mẫu ngừng hoạt động.

Ba chỉ số nên hiểu trước

Core Web Vitals hiện gồm LCP, INP và CLS. Tổng quan Web Vitals giải thích đây là những khía cạnh liên quan trải nghiệm người dùng, không phải ba cách gọi cho cùng một phép đo.

LCP: phần nội dung lớn trong vùng nhìn thấy hiện ra lúc nào?

LCP ghi nhận thời điểm phần tử nội dung lớn nhất thuộc phạm vi đo được hiển thị trong vùng nhìn thấy. Nó có thể là ảnh lớn hoặc khối chữ, không nhất thiết luôn là banner.

Với trang sản phẩm, bạn có thể hình dung khách đang chờ vùng nội dung lớn xuất hiện để bắt đầu xem. Nhưng LCP không có nghĩa toàn bộ trang và mọi ảnh đã tải xong.

Mốc tốt được khuyến nghị là 2,5 giây trở xuống, đánh giá theo phân vị 75 của dữ liệu phù hợp. Tài liệu LCP.

INP: thao tác được phản hồi bằng hình ảnh kịp không?

Khách chạm nút, gõ hoặc nhấp. INP phản ánh độ trễ phản hồi tương tác qua vòng đời lượt xem trang theo cách tính của chỉ số, không chỉ riêng lần bấm đầu tiên.

Nó không phải đồng hồ đo toàn bộ thời gian máy chủ xử lý xong một đơn hàng. Khi bấm gửi biểu mẫu, phản hồi trực quan của giao diện và kết quả xử lý ở máy chủ là những việc cần phân biệt.

Mốc tốt được khuyến nghị là 200 mili giây trở xuống. Tài liệu INP.

CLS: nội dung có dịch chuyển bất ngờ không?

Đang đọc thì chữ nhảy xuống; định bấm xem mẫu thì một khối mới chen vào làm vị trí đổi. CLS đánh giá những dịch chuyển bố cục bất ngờ theo phạm vi và cách tính của chỉ số.

CLS là điểm không có đơn vị, không phải số giây. Mốc tốt được khuyến nghị là 0,1 trở xuống. Tài liệu CLS.

Phân vị 75 nên hiểu thế nào?

Hình dung có nhiều lượt đo rồi sắp kết quả từ nhỏ đến lớn. Mốc phân vị 75 cho biết khoảng 75% kết quả nằm ở mức đó hoặc tốt hơn. Đây là cách nhìn trải nghiệm của một phần lớn người dùng, không phải giá trị trung bình cộng.

Vì vậy, một lần mở rất nhanh trên máy của bạn chưa phản ánh hết trải nghiệm của người dùng trên thiết bị và mạng khác. Cũng không nên lấy ba số của một lần đo mô phỏng để khẳng định toàn bộ khách đều được phục vụ như vậy.

Điểm Performance có giống ba chỉ số này không?

Không hoàn toàn. Điểm Performance của Lighthouse được tính từ một nhóm chỉ số với trọng số. Nó hữu ích để tham khảo lần đo, nhưng không phải điểm SEO tổng thể, số khách hài lòng hay thứ hạng Google.

Tài liệu chấm điểm Lighthouse cũng giải thích điểm có thể dao động do điều kiện đo. Một lần tăng hoặc giảm vài điểm chưa tự chứng minh website vừa tốt lên hay hỏng đi.

Đừng cộng các con số có đơn vị khác nhau, và đừng nhầm điểm Lighthouse với kết luận Core Web Vitals từ dữ liệu người dùng thực tế.

Dữ liệu mô phỏng và thực tế giúp hai việc gì?

Nguồn dữ liệu	Giúp mình	Giới hạn cần nhớ
Mô phỏng trong công cụ.	Tìm đầu mối kỹ thuật và so thử một thay đổi trong điều kiện có ghi lại.	Một lần chạy, thiết bị và mạng mô phỏng không đại diện mọi người dùng.
Đo từ người dùng thực tế.	Nhìn trải nghiệm được ghi nhận trong khoảng thời gian và phạm vi báo cáo.	Cần đủ dữ liệu; kết quả lịch sử không phản ánh ngay một lần sửa vừa xong.

Hai nguồn khác nhau không có nghĩa một nguồn chắc chắn sai. Hãy đọc phạm vi và điều kiện trước khi so. Giải thích của web.dev về khác biệt dữ liệu.

Nhìn chỉ số, rồi mới chọn đầu mối cần kiểm tra

• LCP chưa tốt: xem phần tử liên quan, thời gian phản hồi và đường tải tài nguyên; không chỉ mặc định “ảnh nặng”.
• INP chưa tốt: ghi thao tác bị trễ và những xử lý liên quan; có thể cần người phụ trách kiểm tra JavaScript.
• CLS chưa tốt: xem ảnh, khối nội dung hoặc thành phần chèn thêm có làm đổi vị trí không.

Đây là hướng thu thập bằng chứng, chưa phải nguyên nhân đã xác nhận. Một thiết lập tối ưu dùng chung có thể ảnh hưởng nhiều trang, nên thử trong phạm vi kiểm soát và biết cách quay lại trạng thái trước.

Cải thiện tốc độ có bảo đảm lên hạng không?

Không. Google sử dụng Core Web Vitals trong các hệ thống xếp hạng, nhưng kết quả tốt ở những chỉ số này không bảo đảm trang lên đầu. Nội dung và nhiều yếu tố khác vẫn liên quan. Hướng dẫn Core Web Vitals và Google Search.

Mục tiêu gần nhất là khách xem được nội dung và làm được việc thuận hơn. Đó là điều mình có thể kiểm tra cụ thể sau một thay đổi.

Thực hành: mô tả một vấn đề đủ rõ để xử lý

Trang, thiết bị và hành động thử: …
Điều người dùng gặp: …
Chỉ số muốn xem: …
Nguồn, thời gian và phạm vi dữ liệu: …
Đầu mối đã có bằng chứng: …
Một thay đổi dự định làm / người cần nhờ: …
Cách đo lại và thử chức năng: …

Nếu chỉ ghi được “ảnh chính hiện trễ trên điện thoại, cần xem phần tử LCP”, bạn đã có câu hỏi rõ hơn nhiều so với “tăng tốc toàn website”.

Mỗi chỉ số nên dẫn mình về một trải nghiệm cụ thể của người dùng, rồi mới dẫn đến một việc cần sửa.

Ở bài tiếp theo, mình sẽ mở PageSpeed Insights để tìm những dữ liệu và đầu mối vừa làm quen.

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 mốc nêu trong bài là ngưỡng khuyến nghị của từng Core Web Vital; không phải cam kết thứ hạng hoặc kết luận đo cho phamvanan.com.