Ngày xuất bản: 11 tháng 2 năm 2025
Bản phát hành Báo cáo trải nghiệm người dùng trên Chrome (CrUX) tháng 2 năm 2025 bao gồm một số chỉ số mới (và đã thay đổi!) thú vị:
- Các thành phần phụ và loại tài nguyên hình ảnh Thời gian hiển thị nội dung lớn nhất (LCP)
- Thông tin chi tiết về Thời gian trọn vòng (RTT)
- Xoá phương diện Loại kết nối hiệu quả (ECT)
Mỗi chỉ số này cung cấp thông tin chi tiết hơn về các chỉ số hiệu suất của nguồn gốc và URL có trong CrUX. Trong bài đăng này, chúng tôi sẽ giải thích chi tiết lý do.
Thông tin chẩn đoán về LCP
Ban đầu, chúng tôi đã giới thiệu khái niệm về các thành phần phụ của LCP tại Google I/O 2022 như một kỹ thuật hiệu quả để chia nhỏ thời gian LCP cho các trang có LCP hình ảnh thành các thành phần nhỏ hơn nhằm đảm bảo bạn đang nỗ lực tối ưu hoá đúng(các) nguyên nhân gây ra LCP cao.
Phân tích dữ liệu của phòng thí nghiệm HTTP Archive trong buổi trò chuyện đó cho thấy thời gian tải hình ảnh thường là phần nhỏ nhất trong thời gian LCP. Nhiều công cụ trong phòng thí nghiệm (bao gồm cả Lighthouse của Google) thường tập trung vào việc đưa ra lời khuyên để tối ưu hoá định dạng và kích thước hình ảnh nhằm giảm thời gian tải xuống và cải thiện hiệu suất. Mặc dù vẫn chính xác, nhưng kết quả phân tích cho thấy rằng lời khuyên này có thể đã được nhấn mạnh quá mức và vấn đề lớn hơn là sự chậm trễ trước khi trình duyệt tìm thấy hình ảnh và bắt đầu tải xuống.
Mặc dù việc phân tích dữ liệu thử nghiệm có thể hữu ích, nhưng cách sử dụng web trong thực tế thường có thể khác nhau. Vì vậy, việc có thể xem các phần phụ này cho dữ liệu thực địa là rất quan trọng. Một bài đăng được xuất bản vào năm ngoái đã xác nhận nhầm lẫn thường gặp về cách tối ưu hoá LCP bằng dữ liệu thực địa.
Các phần phụ của hình ảnh LCP
Với bản phát hành này, chủ sở hữu trang web có thể kiểm tra các phần phụ của LCP hình ảnh trên trang web của họ ở cấp nguồn gốc hoặc cấp URL.
Các phần phụ chỉ có sẵn cho hình ảnh và không bao gồm hình ảnh khung video đầu tiên (phần này phức tạp hơn một chút vì chúng tôi không thể đo lường toàn bộ thời gian tải xuống). Các phần phụ văn bản cũng không được đưa vào vì chúng ít hữu ích hơn và sẽ làm méo số liệu LCP của hình ảnh. Đối với những trang web chủ yếu bao gồm LCP văn bản, các chỉ số TTFB tổng thể và FCP tổng thể là những thông tin chi tiết hữu ích. Tuy nhiên, xin lưu ý rằng các chỉ số này áp dụng cho tất cả LCP chứ không chỉ dành riêng cho LCP văn bản. Cuối cùng, các phần phụ của hình ảnh chỉ được thu thập khi tải toàn bộ trang, không giống như chỉ số LCP cũng được thu thập khi thao tác quay lại và chuyển tiếp cũng như các trang được kết xuất trước.
Dữ liệu này đã được thêm vào API CrUX và API Nhật ký CrUX kể từ tháng 2 năm 2025 (lưu ý: không phải BigQuery). API Nhật ký CrUX có dữ liệu trong 2 tuần khi ra mắt và dữ liệu này sẽ tăng lên theo thời gian thành nhật ký đầy đủ trong 25 tuần. Các API cung cấp dữ liệu dưới dạng phân vị thứ 75 của mỗi phần phụ được biểu thị bằng mili giây.
Ví dụ: để lấy các phần phụ của hình ảnh LCP cho https://web.dev/ cho lượt xem trang PHONE, bạn có thể sử dụng lệnh curl sau (thay thế API_KEY bằng khoá của riêng bạn):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": [
"largest_contentful_paint_image_time_to_first_byte",
"largest_contentful_paint_image_resource_load_delay",
"largest_contentful_paint_image_resource_load_duration",
"largest_contentful_paint_image_element_render_delay"]}'
Và bạn sẽ nhận được kết quả như sau:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_image_element_render_delay": {
"percentiles": {
"p75": 2088
}
},
"largest_contentful_paint_image_resource_load_delay": {
"percentiles": {
"p75": 828
}
},
"largest_contentful_paint_image_resource_load_duration": {
"percentiles": {
"p75": 417
}
},
"largest_contentful_paint_image_time_to_first_byte": {
"percentiles": {
"p75": 2385
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Chúng tôi đã cập nhật Công cụ CrUX Vis để đưa dữ liệu này vào và dự kiến các công cụ bên thứ ba khác sử dụng API CrUX cũng sẽ hiển thị dữ liệu có giá trị này:
Trong ví dụ này, chúng ta có thể thấy rằng đối với một trang web truyền thông phổ biến, thời lượng tải tài nguyên là thành phần nhỏ nhất. Cơ hội thực sự để cải thiện trang web này nằm ở TTFB và độ trễ khi tải tài nguyên, với cơ hội nhỏ hơn trong độ trễ khi hiển thị phần tử.
Giá trị cao trong mỗi phần phụ cho biết các vấn đề khác nhau:
- Thời gian tải byte đầu tiên (TTFB) cao thường cho thấy các vấn đề về máy chủ, mạng hoặc chuyển hướng như đã giải thích trong phần Tối ưu hoá TTFB.
- Độ trễ tải tài nguyên cao cho biết trình duyệt phát hiện muộn hình ảnh LCP, ví dụ: hình ảnh LCP được JavaScript phía máy khách chèn và mất một khoảng thời gian để chạy.
- Bạn nên xem xét việc giảm kích thước tải xuống hình ảnh khi thời lượng tải tài nguyên cao.
- Độ trễ kết xuất phần tử cao là khi hình ảnh có sẵn (có thể thông qua
<link rel=preload>nhưng không được sử dụng trong thời gian dài – thường là do JavaScript phía máy khách cần thiết để hiển thị hình ảnh.
Chúng tôi hy vọng việc cung cấp dữ liệu này trong CrUX ở cả cấp nguồn và cấp URL (tuân theo các tiêu chí đủ điều kiện thông thường) sẽ giúp các trang web dễ dàng tối ưu hoá chỉ số LCP hơn.
Các loại tài nguyên LCP
Vì các phần phụ là phần phù hợp nhất để xem LCP của hình ảnh, nên CrUX chỉ giới hạn dữ liệu này ở những trang có hình ảnh. Do đó, điều quan trọng là bạn phải biết có bao nhiêu LCP là LCP hình ảnh so với LCP văn bản (chẳng hạn như tiêu đề <h1> và các đoạn văn bản dài).
Ngoài các phần phụ hình ảnh LCP, API CrUX hiện cũng bao gồm bảng chi tiết tài nguyên cho biết mức phân tách lượt tải trang LCP giữa văn bản và hình ảnh.
Ví dụ: để nhận các loại tài nguyên LCP cho https://web.dev/ cho các lượt xem trang PHONE, bạn có thể sử dụng lệnh curl sau (thay thế API_KEY bằng khoá của riêng bạn):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["largest_contentful_paint_resource_type"]}'
Và bạn sẽ nhận được kết quả như sau:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_resource_type": {
"fractions": {
"image": 0.0155,
"text": 0.9845
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Chúng tôi cũng đã cập nhật CrUX Vis để hiển thị dữ liệu này:
Ví dụ: đối với trang chủ của web.dev, chúng ta có thể thấy rằng 98,5% LCP thực sự là LCP văn bản, vì vậy, các phần phụ hình ảnh LCP sẽ ít hữu ích hơn cho trang này. Trong trường hợp đó, chúng ta có thể sử dụng các chỉ số TTFB và FCP ban đầu để có được thông tin chẩn đoán chi tiết hơn.
Loại tài nguyên LCP là một công cụ chẩn đoán hữu ích khác để hiểu và cải thiện LCP, đặc biệt là để biết các phần phụ của hình ảnh LCP hữu ích như thế nào.
Thông tin chẩn đoán về RTT
Chúng tôi cũng đã mở rộng chỉ số RTT (được ra mắt lần đầu vào tháng 8 năm 2024).
Ba bộ chứa RTT
Chúng tôi đã thêm các bộ chứa ba vùng vào API CrUX để hiển thị ba nhóm mật độ RTT:
| Độ trễ mạng | Bắt đầu | Kết thúc |
|---|---|---|
| Thấp | 0 mili giây | Dưới 75 mili giây |
| Phương tiện | 75 mili giây | Dưới 275 mili giây |
| Cao | 275 mili giây | ∞ |
Các bộ chứa này cung cấp nhiều thông tin hơn so với các danh mục ECT trước đây, trong đó bao gồm mọi thứ dưới 270 mili giây trong danh mục 4g. Kể từ khi những danh mục đó ra mắt, nhờ sự tiến bộ của công nghệ kết nối mạng, hầu hết các trang web đều nhận thấy phần lớn lưu lượng truy cập của họ nằm trong danh mục đó, khiến cách phân loại này trở nên kém hữu ích.
Đó là lý do bạn nên sử dụng các nhãn phân phối thấp, trung bình và cao thay vì các nhãn tốt, cần cải thiện và kém thông thường. Đây không phải là những chỉ số mà chủ sở hữu trang web có thể tự cải thiện. Do đó, đây là những chỉ số chẩn đoán để hiểu các chỉ số khác và lý do các chỉ số đó có thể khác với dự kiến. Các chỉ số này cũng có thể giúp giải thích lý do các chỉ số khác thay đổi theo thời gian, mặc dù trang web không thay đổi nếu các chỉ số này cho thấy sự thay đổi trong cơ sở người dùng.
Các vùng chứa này có trong API CrUX, ví dụ: web.dev cho PHONE lượt xem trang (thay thế API_KEY bằng khoá của riêng bạn):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["round_trip_time"]}'
Hàm này sẽ trả về kết quả như sau:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"round_trip_time": {
"histogram": [
{
"start": 0,
"end": 75,
"density": 0.1524
},
{
"start": 75,
"end": 275,
"density": 0.6641
},
{
"start": 275,
"density": 0.1835
}
],
"percentiles": {
"p75": 230
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Các vùng chứa sẽ xuất hiện trong CrUX Vis khi bạn chọn phân phối:
RTT trong BigQuery
Ngoài việc mở rộng chỉ số RTT trong các API CrUX để bao gồm cả ba bộ chứa, chúng tôi cũng đã cung cấp dữ liệu trong tập dữ liệu BigQuery hằng tháng, bao gồm cả biểu đồ hoàn chỉnh trong các bộ chứa 25 mili giây trong các bảng thô và các bộ chứa ba và giá trị p75 trong các bảng được tạo bản sao.
Điều này giúp bạn hiểu rõ hơn về việc phân phối dữ liệu ngoài các bộ chứa ba trong API CrUX. Điều này cũng cho phép chúng tôi tạo lại bảng chi tiết về ECT đã bị xoá khỏi CrUX kể từ tháng này (sẽ nói thêm về điều đó sau), với thay đổi nhỏ về ngưỡng 275 mili giây cho 4g thay vì ngưỡng 270 mili giây trước đó. Bảng chi tiết về ECT (hiện lấy nguồn từ dữ liệu RTT) vẫn có trong các bảng được tạo bản sao BigQuery của CrUX để các công cụ như Bảng điều khiển CrUX có thể tiếp tục hiển thị bảng chi tiết này.
Tập dữ liệu BigQuery cũng bao gồm dữ liệu theo quốc gia (theo định nghĩa của ISO 3166-1). Điều này cho phép phân tích sâu hơn, có thể hữu ích để giải thích lý do một số người dùng có chỉ số hiệu suất kém hơn. Ví dụ: chúng ta có thể xem dữ liệu về người dùng Điện thoại Google bằng cách xem dữ liệu về https://www.google.com:
SELECT
`chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
least(500, p75_rtt) AS capped_p75_rtt,
p75_rtt
FROM
`chrome-ux-report.materialized.country_summary`
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202501 AND
device = 'phone'
ORDER BY
p75_rtt DESC,
country_code
Sau đó, chúng ta trực quan hoá dữ liệu trên bản đồ địa lý:
https://www.google.com(dữ liệu nguồn có biểu đồ tương tác).
Chúng ta có thể thấy rằng, mặc dù hầu hết các khu vực trên thế giới (đặc biệt là "phương Tây") có RTT rất tốt, nhưng khu vực Châu Phi hạ Sahara, một số khu vực ở Trung Đông và một số khu vực ở Châu Á lại gặp nhiều khó khăn hơn. Trên thực tế, biểu đồ này bị giới hạn ở RTT 500 mili giây vì việc sử dụng toàn bộ dữ liệu đã làm sai lệch màu sắc, đặc biệt là với Eritrea ở phân vị thứ 75 là 3.850 mili giây!
Điều này cũng có thể hữu ích khi các mẫu lưu lượng truy cập thay đổi. Ví dụ: tỷ lệ người dùng từ những quốc gia có RTT cao hơn có thể giải thích cho việc số liệu thống kê về các chỉ số Core Web Vitals kém hơn mặc dù trang web không thay đổi gì.
Mặc dù các trang web không thể trực tiếp cải thiện RTT, nhưng việc cung cấp dữ liệu này cho khách truy cập trang web sẽ giúp bạn hiểu rõ hơn về người dùng trang web trên toàn cầu. Điều này cũng tạo ra nhiều cơ hội phân tích trong tương lai và chúng tôi hy vọng các nhà nghiên cứu sẽ tìm thấy thông tin chi tiết thú vị từ tập dữ liệu này.
Xoá phương diện ECT
Thay đổi cuối cùng trong bản phát hành tháng 2 năm 2025 là ngừng sử dụng phương diện Loại kết nối hiệu quả (ECT) khỏi BigQuery (chúng tôi đã xoá RTT khỏi các API kể từ tháng 9 năm 2024 khi giới thiệu chỉ số RTT thay thế).
Như đã đề cập trước đó trong bài đăng này, chỉ số RTT cho phép xem chi tiết hơn về thông tin kết nối của khách truy cập trang web. Bạn thậm chí có thể tạo lại các bộ chứa ECT từ các biểu đồ đó. (Về mặt kỹ thuật, ECT phải là sự kết hợp giữa RTT và tốc độ đường truyền xuống, nhưng Chrome chỉ sử dụng RTT.)
Một điểm khác biệt quan trọng là ECT là một phương diện CrUX, nghĩa là các chỉ số khác có thể được phân đoạn theo ECT. RTT là một chỉ số CrUX thay vì một phương diện. Vì vậy, bạn không thể xem LCP theo RTT, mà chỉ có thể xem RTT theo các phương diện khác (loại thiết bị và quốc gia).
Điều này có vẻ hạn chế hơn, nhưng việc chuyển từ phương diện sang chỉ số thực sự giúp mở khoá nhiều dữ liệu hơn trong CrUX. Điều này là do CrUX có một số ngưỡng tối thiểu nhất định trước khi chúng tôi có thể hiển thị dữ liệu. Chúng tôi đã bỏ qua các phương diện không bắt buộc trong năm 2022, nghĩa là chúng tôi đã xoá ECT hoặc thiết bị nếu cần thiết để báo cáo ở cấp cao hơn, nhưng các chỉ số không có trên hầu hết các lượt tải trang (Số lượt tương tác đến lượt vẽ tiếp theo (INP), các loại thao tác điều hướng khác nhau và hiện là các phần phụ của hình ảnh LCP) thường không có sẵn cho các nguồn gốc trong BigQuery.
Bằng cách giảm số lượng phương diện, dữ liệu sẽ ít bị phân đoạn hơn, do đó, số lượng nguồn gốc đáp ứng các yêu cầu tối thiểu này sẽ tăng lên. Trong tháng 1, chúng tôi báo cáo INP cho 68,1% nguồn gốc, trong khi đối với tập dữ liệu tháng 12, chúng tôi chỉ báo cáo INP cho 64,5% nguồn gốc. Cơ chế này cũng áp dụng cho các Loại điều hướng, Phần phụ LCP và Loại tài nguyên trong bản phát hành này. Tất cả các loại này đều được hưởng lợi từ việc xoá phương diện ECT. Trong các API CrUX, phạm vi tăng cường đã có hiệu lực từ đầu tháng 2.
Các cột ECT sẽ vẫn nằm trong BigQuery để đảm bảo tính nhất quán với các tập dữ liệu trước đó và dữ liệu ECT trong chế độ xem được hiện thực hoá sẽ vẫn có sẵn, nhưng dựa trên thông tin RTT (có chênh lệch 5 mili giây đối với 3g và 4g như đã lưu ý trước đó) ngoài RTT p75 và ba vùng chứa mới.
Kết luận
Việc bổ sung thêm các chỉ số vào tập dữ liệu CrUX công khai sẽ cung cấp cho chủ sở hữu trang web và nhà nghiên cứu nhiều thông tin hơn để giúp chẩn đoán và cuối cùng là khắc phục các vấn đề về hiệu suất.
Là một tập dữ liệu công khai, CrUX có một số hạn chế nhất định về mức độ chi tiết mà chúng tôi có thể hiển thị. Ví dụ: bộ chọn phần tử riêng lẻ sẽ không bao giờ xuất hiện trong CrUX. Những chủ sở hữu trang web muốn có thông tin chi tiết ở mức này nên triển khai giải pháp RUM. Giải pháp này sẽ không bị hạn chế như vậy.
Tuy nhiên, dữ liệu tổng hợp cấp cao hơn (chẳng hạn như dữ liệu được nêu chi tiết trong bài đăng này) có thể giúp bạn biết được vấn đề và lý do gây ra vấn đề. Chúng tôi hy vọng dữ liệu bổ sung này sẽ hữu ích. Hãy cho chúng tôi biết trong nhóm thảo luận nếu bạn có ý kiến phản hồi hoặc câu hỏi!