發布日期：2025 年 2 月 11 日
2025 年 2 月發布的 Chrome 使用者體驗報告 (CrUX) 包含許多令人期待的新指標 (以及變更的指標！)：
- 最大內容繪製 (LCP) 圖片子部分和資源類型
- 封包往返時間 (RTT) 詳細資料
- 移除有效連線類型 (ECT) 維度
這兩項指標可進一步分析 CrUX 中可用的來源和網址的成效指標，本篇文章將詳細說明原因。
LCP 診斷資訊
我們最初在 Google I/O 2022 中介紹 LCP 子項的概念，這是一種有效的技術，可將有圖片 LCP 的網頁 LCP 時間細分為較小的元件，確保您能將心力花在正確的 LCP 高值原因上。
在該演講中，我們分析了 HTTP Archive 實驗室資料，結果顯示圖片下載時間通常是 LCP 時間中最短的部分。許多實驗室工具 (包括 Google 自家的 Lighthouse) 經常提供最佳化圖片格式和大小的建議，以縮短下載時間並提升效能。雖然這項建議仍正確，但分析結果顯示，這項建議可能過於強調，而更大的問題是瀏覽器在找到圖片並開始下載之前，會出現延遲。
雖然分析實驗室資料很有幫助，但實際上網頁的使用方式往往有所不同，因此能夠查看這些現場資料的子部分至關重要。我們去年發布的文章指出，使用欄位資料時，常見的 LCP 最佳化誤解。
LCP 圖片子項
在這個版本中，網站擁有者可以檢查自家網站的圖片 LCP 子項，包括來源或網址層級。
子部分只能用於圖片，但不包括第一個影片影格圖片 (因為我們無法測量完整的下載時間，因此這類圖片會比較複雜)。文字子部分也不包含在內，因為這些子部分較不實用，且會扭曲圖片 LCP 數字。如果網站主要由文字 LCP 組成，整體 TTFB 和整體 FCP 指標就很實用，但請注意，這些指標涵蓋所有 LCP，而非特定文字 LCP。最後，圖片子項只會在整個網頁載入時收集，這與 LCP 指標本身不同，後者也會在前進/後退導覽和預先算繪的網頁中收集。
自 2025 年 2 月起，這項資料已加入 CrUX API 和 CrUX History API (注意：不是 BigQuery)。CrUX History API 在推出時會提供兩週的資料，隨著時間推移，資料會累積到完整的 25 週歷史資料。API 會以毫秒為單位，提供各個子部分的第 75 百分位數。
舉例來說，如要取得 https://web.dev/ 的 LCP 圖片子項，以便針對 PHONE 網頁檢視畫面進行分析，您可以使用下列 curl 指令 (將 API_KEY 替換為您自己的鍵)：
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"]}'
您會收到類似以下的回應：
{
"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
}
}
}
}
我們已更新 CrUX Vis 工具，納入這項資料，並期待其他使用 CrUX API 的第三方工具也能提供這項寶貴的資料：
在這個範例中，我們可以看到對於熱門媒體網站而言，資源載入時間是時間最短的元件。這個網站的實際改善機會在於 TTFB 和 資源載入延遲，而 元素轉譯延遲的改善機會較小。
各個子部分中的高值代表不同的問題：
- 高「第 1 個位元組時間 (TTFB)」通常表示伺服器、網路或重新導向問題，請參閱「最佳化 TTFB」一文瞭解詳情。
- 高 資源載入延遲表示瀏覽器較晚才偵測到 LCP 圖片，例如由用戶端 JavaScript 插入的 LCP 圖片，需要一段時間才能執行。
- 如果資源載入時間過長，您就應該考慮縮減圖片下載大小。
- 高元素算繪延遲是指圖片可供使用 (可能透過
<link rel=preload>提供)，但長時間未使用，這通常是因為需要使用用戶端 JavaScript 才能顯示圖片。
我們希望在 CrUX 中提供來源和網址層級的資料 (須符合一般資格條件)，協助網站更輕鬆地改善 LCP 指標。
LCP 資源類型
由於子項最適合用於查看圖片 LCP，因此 CrUX 會將這項資料限制在含有圖片的網頁。因此，請務必瞭解有多少 LCP 是圖片 LCP，而非文字 LCP (例如 <h1> 標題和長段落)。
除了 LCP 圖片子部分，CrUX API 現在也包含資源細目，顯示 LCP 網頁載入的文字和圖片之間的差異。
舉例來說，如要取得 https://web.dev/ 的 LCP 資源類型，以便針對 PHONE 網頁檢視執行，您可以使用下列 curl 指令 (再次提醒，請將 API_KEY 替換為您自己的金鑰)：
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"]}'
您會收到類似以下的回應：
{
"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
}
}
}
}
CrUX Vis 也已更新，可顯示以下資料：
以 web.dev 首頁為例，我們可以看到 98.5% 的 LCP 其實是文字 LCP，因此 LCP 圖片子部分對這個網頁的幫助不大。在這種情況下，我們可以使用原始的 TTFB 和 FCP 指標，作為可能更適合的診斷細目。
LCP 資源類型是另一項實用的診斷工具，可用於瞭解及改善 LCP，特別是瞭解 LCP 圖片子項的實用性。
RTT 診斷資訊
我們也擴大了 2024 年 8 月首次推出的 RTT 指標。
RTT 三分類
我們已在 CrUX API 中新增三個分類，顯示三個 RTT 密度群組：
| 網路延遲 | 開始 | 結束 |
|---|---|---|
| 低 | 0 毫秒 | < 75 毫秒 |
| 中 | 75 毫秒 | < 275 毫秒 |
| 高 | 275 毫秒 | ∞ |
這些區塊比先前的 ECT 類別更能提供資訊，因為先前的類別將 4g 類別中所有小於 270 毫秒的時間都歸入「其他」類別。隨著網路技術的進步，大多數網站的流量都來自這個類別，因此這項分類就沒那麼實用。
因此，我們建議使用「低」、「中」和「高」分布標籤，而非平常使用的「良好」、「需要改善」和「不佳」標籤。這些指標並非網站管理員可以直接改善的指標，因此是用於瞭解其他指標，以及為何這些指標可能與預期不同。這些指標還可說明為何其他指標會隨時間變動，即使網站沒有變更，但使用者群可能會有所變動。
這些分類可在 CrUX API 中使用，例如 web.dev 和 PHONE 網頁瀏覽量 (再次提醒您，請將 API_KEY 替換成您自己的鍵)：
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"]}'
這會傳回類似以下的內容：
{
"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
}
}
}
}
選取「分布」後，CrUX Vis 會顯示這些區塊：
BigQuery 中的 RTT
除了在 CrUX API 中擴充 RTT 指標以納入三分位數，我們也將這項資料納入每月 BigQuery 資料集，包括原始資料表中的 25 毫秒桶的完整直方圖，以及具象化資料表中的三分位數和 p75 值。
這樣一來，您就能進一步瞭解資料的散布情形，而非僅限於 CrUX API 中的三分法。這也讓我們能夠重建自本月起從 CrUX 移除的 ECT 細目 (詳情請參閱後續說明)，其中 4g 的門檻值從 270 毫秒微幅調高至 275 毫秒。CrUX BigQuery 具象化資料表仍會提供 ECT 細目資料 (現在取自 RTT 資料)，因此 CrUX 資訊主頁等工具仍可繼續顯示這項細目資料。
BigQuery 資料集也包含依國家/地區劃分的資料 (依據 ISO 3166-1 定義)。這有助於深入分析，說明為何某些使用者的成效指標較差。舉例來說，我們可以查看 https://www.google.com 的資料，藉此瞭解 Google 手機使用者的資料：
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
接著，我們在地理地圖上以視覺化方式呈現資料：
https://www.google.com的 75 個百分位數 Phone RTT 依國家/地區劃分(含互動式圖表的來源資料)。
我們發現，雖然全球大部分地區 (尤其是「西方世界」) 的 RTT 都非常優異，但撒哈拉以南非洲、部分中東地區和部分亞洲地區的 RTT 則較為吃力。事實上，由於使用完整資料會導致顏色偏差，因此圖表的 RTT 上限為 500 毫秒，尤其是衣索比亞的 75 百分位數為 3,850 毫秒！
在流量模式變更時，這項功能也相當實用。舉例來說，如果使用者來自 RTT 較高的國家/地區，且比例較高，即使網站沒有任何變動，核心網站 Vitals 統計資料也可能會變差。
雖然網站無法直接改善 RTT，但讓網站訪客提供這項資料，有助於進一步瞭解全球使用者對網站的使用情形。這也為日後的分析帶來許多機會，希望研究人員能從這個資料集發現有趣的洞察資料。
移除 ECT 維度
2025 年 2 月版本的最後一項變更，是將有效連線類型 (ECT) 維度從 BigQuery 中淘汰 (我們在2024 年 9 月推出 RTT 指標時，就已將 RTT 從 API 中移除)。
如這篇文章先前所述，RTT 指標可讓您更精細地查看網站訪客的連線詳細資料。您甚至可以根據這些直方圖重建 ECT 桶。(從技術層面來說，ECT 應為 RTT 和下行連線速度的組合，但 Chrome 一向只使用 RTT)。
重要的差異在於 ECT 是 CrUX 維度，也就是說其他指標可以依 ECT 區隔。封包往返時間是 CrUX 指標，而非維度，因此無法依據封包往返時間查看 LCP，只能依據其他維度 (裝置類型和國家/地區) 查看封包往返時間。
這聽起來可能比較受限，但從維度轉換成指標，其實可在 CrUX 中解鎖更多資料。這是因為 CrUX 設有特定的最低門檻，系統必須達到這個門檻才能顯示資料。我們已在 2022 年將維度設為選用項目，也就是說，我們已移除 ECT，或在需要以更高層級回報的裝置上移除 ECT，但在大多數網頁載入作業中未顯示的指標 (Interaction to Next Paint (INP)、不同導覽類型，以及現在的 LCP 圖片子部分)，在 BigQuery 中的來源經常無法使用。
減少維度數量可減少資料區隔，因此符合這些最低要求的來源數量會增加。1 月時，我們回報的 INP 比率為 68.1%，而 12 月資料集的 INP 比率則為 64.5%。這項機制也適用於本版本中的導覽類型、LCP 子項和資源類型，這些類型都能從移除 ECT 維度中受益。在 CrUX API 中，擴大涵蓋範圍的做法已自 2 月初生效。
為了與先前的資料集保持一致，BigQuery 會保留 ECT 欄，而實體化檢視中的 ECT 資料也會繼續提供，但會以 RTT 資訊 (3g 和 4g 的差異為 5 毫秒，如先前所述) 和新的 RTT p75 和三分位欄為依據。
結論
在公開 CrUX 資料集中加入更多指標，可讓網站擁有者和研究人員取得更多資訊，協助診斷並最終修正效能問題。
由於 CrUX 是公開資料集，因此我們只能顯示特定程度的詳細資料，例如個別元素選取器永遠不會顯示在 CrUX 中。建議網站擁有者導入 RUM 解決方案，以便取得這類詳細資料，且不受限制。
不過，您可以透過這篇文章中詳述的更高層級的匯總資料，瞭解問題所在，並找出問題發生的原因。希望這些額外資料對您有所幫助。如有任何意見回饋或問題，歡迎在討論群組中與我們分享！