Ngôn ngữ

Trình kiểm tra tốc độ trang & Core Web Vitals

Free, no signup. Core Web Vitals reports are usually a wall of numbers before they tell you anything useful. This leads with one sentence: whether the page passes, and the single thing to fix first — real Chrome user data when it exists, a Lighthouse lab audit when it doesn't.

Built by Patrick Stox

field data first (CrUX) · lab fallback (Lighthouse) · mobile + desktop

Các lần kiểm tra chạy từ máy chủ của chúng tôi; chúng tôi tải URL bạn nhập và không lưu kết quả. Anonymous aggregate stats count a domain once via a rotating hash for research posts; URLs are never stored. Số đếm kết quả ẩn danh theo từng lần chạy có thể được dùng cho nghiên cứu tổng hợp; URL, tên miền, IP và mã định danh không bao giờ được bao gồm, và không công bố số liệu thống kê khi có dưới 100 lần chạy.

Phản hồi
Báo lỗi

Có gì đó không hoạt động trong Trình kiểm tra tốc độ trang & Core Web Vitals? Hãy cho chúng tôi biết điều gì đã xảy ra — báo cáo được gửi thẳng đến hàng đợi phân loại riêng tư, không phải danh sách công khai.

Thông tin sẽ được gửi 
 Dữ liệu nhập vào công cụ, tệp tải lên, nguồn đã dán, kết quả đầy đủ, tham số truy vấn và đoạn URL không được tự động đính kèm. Bạn có thể sửa hoặc xóa đoạn đã chọn ở trên. Siêu dữ liệu trình duyệt và chống lạm dụng được xử lý để ngăn spam. 
  
 
  
 
 
  
 
 
   
      
 
       
     
  
      

Field data is Google's Chrome UX Report — the same 28-day real-user dataset Search uses
        for the page-experience signal; it updates daily, so repeat checks within 24 hours are
        served from cache. Lab numbers come from Lighthouse with simulated throttling: expect them
        to differ from field data and to vary between runs. Lab audits can't measure INP (it needs
        real users).

   
 
   
        
Giới thiệu công cụ
Cho biết trong một câu liệu trang có đạt Core Web Vitals hay không và nên sửa điều gì trước. Công cụ ưu tiên dữ liệu thực địa `CrUX`, sau đó dùng chẩn đoán phòng thí nghiệm `Lighthouse` khi cần.
Tính năng
  • Đọc dữ liệu thực địa `CrUX` trước; nếu URL không có mẫu, công cụ tự động chuyển sang dữ liệu cấp nguồn gốc và kiểm tra phòng thí nghiệm `Lighthouse`.
  • Hiển thị thẻ di động và máy tính để bàn cạnh nhau, đồng thời đánh dấu rõ thẻ di động mà `Google` dùng để xếp hạng.
  • Đưa ra kết luận theo ngưỡng chính thức của ba chỉ số `Core Web Vitals` và danh sách sửa cụ thể, sắp từ chỉ số hoạt động kém nhất.
  • Liên kết chỉ số có vấn đề với các chẩn đoán `Lighthouse` thực sự đã chạy, kèm bảng điểm nguồn gốc cho tối đa 5 miền và xuất `CSV` ở chế độ toàn trang.
Cách hoạt động
Truy vấn dữ liệu `CrUX` trước; nếu URL cụ thể không có mẫu, thử lại dữ liệu thực địa cấp nguồn gốc rồi chỉ chạy kiểm tra phòng thí nghiệm `Lighthouse` khi cần. Mỗi thẻ ghi rõ nguồn đã dùng và so sánh `LCP`, `INP`, `CLS` với ngưỡng chính thức. Công cụ thu thập chẩn đoán từ lần kiểm tra `Lighthouse` thực sự chạy, rồi xếp thứ tự sửa theo chỉ số và thiết bị có vấn đề nhất. Không có gì bạn kiểm tra được lưu lại; kết quả có thể được dùng lại từ bộ nhớ đệm khi kiểm tra lại trong vòng 24 giờ.
Giới hạn
  • Dữ liệu thực địa `CrUX` dựa trên lượt truy cập thực của người dùng `Chrome`, nên thay đổi mới có thể mất đến 28 ngày mới xuất hiện.
  • Kết quả phòng thí nghiệm `Lighthouse` là lần chạy mô phỏng và không cung cấp vị trí kiểm tra theo khu vực. Không nên dùng kết quả này làm bằng chứng cho hiệu suất người dùng ở một thị trường cụ thể; hãy kiểm tra dữ liệu thực địa và nhà cung cấp theo khu vực.
Câu hỏi thường gặp
Ngưỡng Core Web Vitals là gì?
Một trang đạt yêu cầu khi điểm ở phân vị thứ 75 của cả ba chỉ số đều ở mức `good` (tốt): `Largest Contentful Paint` (LCP) không quá 2.5 giây, `Interaction to Next Paint` (INP) không quá 200 mili giây và `Cumulative Layout Shift` (CLS) không quá 0.1. LCP trên 4 giây, INP trên 500 mili giây hoặc CLS trên 0.25 là `poor` (kém); mọi giá trị nằm giữa hai ngưỡng là `needs improvement` (cần cải thiện). Công cụ sử dụng đúng các ngưỡng chính thức này.
Tại sao điểm Core Web Vitals của tôi khác PageSpeed Insights?
Hai bên sẽ khớp khi cùng đọc một nguồn dữ liệu. Công cụ này ưu tiên hiển thị dữ liệu thực địa từ Chrome UX Report (CrUX), cùng bộ dữ liệu người dùng thực mà Google `Search` sử dụng, và chỉ chuyển sang kiểm tra phòng thí nghiệm Lighthouse khi trang không có dữ liệu thực địa. Số liệu phòng thí nghiệm dùng giới hạn mô phỏng và thay đổi giữa các lần chạy, nên điểm phòng thí nghiệm sẽ không trùng với điểm thực địa. Nếu số liệu `PageSpeed` của bạn là điểm phòng thí nghiệm còn số liệu ở đây là dữ liệu thực địa, hoặc ngược lại, đó chính là nguyên nhân khác biệt.
Tại sao trình kiểm tra báo `no field data` cho URL của tôi?
CrUX chỉ báo cáo một URL khi URL đó có đủ lưu lượng Chrome để tạo mẫu ổn định về mặt thống kê trong 28 ngày gần nhất. Các trang ít lưu lượng hoặc mới hoàn toàn không đạt ngưỡng này. Khi đó, công cụ chuyển sang dữ liệu thực địa cấp nguồn gốc (toàn bộ trang web) hoặc một lần kiểm tra phòng thí nghiệm Lighthouse mô phỏng, đồng thời ghi rõ nguồn mà mỗi thẻ đang dùng để bạn không nhầm số liệu phòng thí nghiệm với dữ liệu người dùng thực.
Công cụ này có thể đo INP không?
Công cụ có thể báo cáo INP từ dữ liệu thực địa vì INP được đo từ tương tác thật của người dùng. Công cụ không thể tạo số liệu INP từ kiểm tra phòng thí nghiệm vì Lighthouse không có người dùng thực để tương tác với trang, nên kết quả chỉ có dữ liệu phòng thí nghiệm sẽ hiển thị `no lab INP` cho chỉ số này. Nếu bạn cần số liệu INP nhưng trang không có dữ liệu thực địa, bạn cần lưu lượng thật hoặc công cụ INP trong Chrome DevTools áp dụng cho chính các tương tác của mình.
Google dùng thiết bị nào để xếp hạng: di động hay máy tính?
Google đánh giá tín hiệu trải nghiệm trang trên thiết bị di động, vì vậy công cụ đánh dấu thẻ di động là `what Google ranks on` và khi một trang không đạt trên cả hai loại thiết bị, công cụ chỉ ra chỉ số di động đang là ràng buộc quyết định. Điểm máy tính được hiển thị để tham khảo nhưng không quyết định kết quả đánh giá xếp hạng trên di động.
 
Bước tiếp theoLịch sử Core Web Vitals & So sánh với đối thủ cạnh tranh — look up the exact spec and expected values.
Hướng dẫn có bằng tiếng Anh.
Mọi người cũng khám phá
Công cụLịch sử Core Web Vitals & So sánh với đối thủ cạnh tranhCông cụTrình kiểm tra tiêu đề HTTPCông cụTrình kiểm tra DNS
       
 
Các vấn đề thường gặp và cách khắc phục
 
     
  •  Lỗi LCP ở mức kém Cách khắc phục: Giảm LCP xuống dưới 2,5 giây bằng cách tối ưu phần tử LCP đã đo và đường phân phối trọng yếu của nó, rồi xác minh bằng dữ liệu thực địa mới. 
  •  Cảnh báo LCP cần cải thiện Cách khắc phục: Đưa LCP xuống dưới 2,5 giây bằng cách ưu tiên phần tử LCP đã đo và loại bỏ độ trễ trên đường phân phối. 
  •  Lỗi INP ở mức kém Cách khắc phục: Giảm INP xuống dưới 200 ms bằng cách rút ngắn các tác vụ tương tác dài nhất và giảm công việc JavaScript trên luồng chính. 
  •  Cảnh báo INP cần cải thiện Cách khắc phục: Đưa INP xuống dưới 200 ms bằng cách chia nhỏ trình xử lý tương tác dài và nhường công việc trên luồng chính. 
  •  Lỗi CLS ở mức kém Cách khắc phục: Giảm CLS xuống dưới 0,1 bằng cách dành sẵn không gian cho phần tử dịch chuyển và ngăn thay phông chữ hoặc nội dung muộn. 
  •  Cảnh báo CLS cần cải thiện Cách khắc phục: Đưa CLS xuống dưới 0,1 bằng cách thêm kích thước ổn định và chỗ giữ cho các phần tử di chuyển sau lần vẽ đầu. 
  •  Cảnh báo Tài nguyên chặn kết xuất có thể làm chậm LCP Cách khắc phục: Nội tuyến CSS trọng yếu và trì hoãn bảng kiểu hoặc tập lệnh không trọng yếu đang chặn tài nguyên LCP kết xuất. 
  •  Cảnh báo Phản hồi máy chủ có thể làm chậm LCP Cách khắc phục: Giảm thời gian phản hồi máy chủ ban đầu bằng bộ nhớ đệm, công việc phía sau nhanh hơn và CDN gần người dùng trước khi tối ưu tài nguyên LCP. 
  •  Cảnh báo Phân phối hình ảnh có thể làm chậm LCP Cách khắc phục: Đổi kích thước và nén hình ảnh LCP, phục vụ định dạng hiện đại bằng srcset và tải trước khi phát hiện muộn. 
  •  Thông tin Nguồn trọng yếu thiếu preconnect Cách khắc phục: Chỉ thêm preconnect cho nguồn bên thứ ba trọng yếu phục vụ tài nguyên LCP, gồm crossorigin khi bắt buộc. 
  •  Cảnh báo Mã bên thứ ba góp phần làm tăng INP Cách khắc phục: Trì hoãn trình quản lý thẻ, trò chuyện, phân tích và tập lệnh thử nghiệm không trọng yếu đến sau tương tác đầu, đồng thời xóa nhà cung cấp không dùng. 
  •  Cảnh báo Công việc luồng chính góp phần làm tăng INP Cách khắc phục: Chia tác vụ luồng chính dài thành phần nhỏ hơn, chuyển tính toán nặng sang luồng xử lý nền và giảm công việc bố cục đồng bộ. 
  •  Cảnh báo JavaScript không dùng góp phần làm tăng INP Cách khắc phục: Chia mã theo tuyến và thành phần để trang chỉ tải xuống, phân tích và thực thi JavaScript cần cho chế độ xem hiện tại. 
  •  Cảnh báo Các phần tử dịch chuyển bố cục góp phần làm tăng CLS Cách khắc phục: Đặt kích thước rõ ràng hoặc chỗ giữ sẵn cho hình ảnh, nội dung nhúng, quảng cáo và vùng chèn được báo cáo trước khi tải. 
  •  Cảnh báo Tải phông chữ góp phần làm tăng CLS Cách khắc phục: Tải trước phông chữ trọng yếu, dùng phông dự phòng tương thích số đo và chọn hành vi font-display tránh thay đổi bố cục muộn. 
  •  Cảnh báo Hiệu suất phòng thử nghiệm và thực địa không khớp Cách khắc phục: Dùng dấu vết Lighthouse để chẩn đoán nút thắt trong lần chạy mô phỏng, rồi theo dõi chỉ số CrUX tương ứng trước khi tuyên bố hoặc đóng hồi quy người dùng thực. 
    •