Google Chrome UX Report(CrUX)新增四項實驗性廣告指標,讓網站的廣告負載不再只能憑版位數量或實驗室測試推估,而能從彙總後的真實 Chrome 使用者瀏覽經驗觀察:畫面同時出現多少廣告、廣告佔了多少可視區域,以及廣告帶來多少網路與 CPU 資源消耗。
13
這對媒體發布商、廣告營運團隊與媒體買方很有參考價值,但要先釐清定位:它們是診斷用的欄位資料,不是廣告創意品質評分,也不是 Google 已宣布的自然搜尋直接排名因素。
13
四項指標各在量什麼?
| 指標 |
中文理解 |
衡量內容 |
| Ad Count |
廣告數量 |
可視區域(viewport)內平均同時出現的廣告數量 |
| Ad Density |
廣告密度 |
廣告佔可視區域面積的平均比例 |
| Ad Weight(Network Usage) |
廣告網路負載 |
廣告所消耗的資源量,以位元組(bytes)計算 |
| Ad Weight(CPU Usage) |
廣告 CPU 負載 |
廣告所消耗的處理資源,以毫秒(ms)計算 |
四者合看,才能避免只以「廣告版位有幾個」判斷體驗。
例如,頁面可見廣告數不多,但一個大型固定式廣告就可能讓廣告密度很高;另一個頁面看起來不算擁擠,卻可能因程式化廣告技術堆疊、第三方腳本或素材資源而有很高的網路與 CPU 負載。反過來說,許多尺寸小、資源輕量的廣告也可能拉高數量,卻未必造成同等程度的資源壓力。
CrUX 反映的是誰的資料?
CrUX 是 Google 公開的真實使用者體驗資料集,呈現真實世界 Chrome 使用者造訪熱門網站時的整體體驗。
6
因此,這不是某一支廣告素材、某一個廣告版位或某一次曝光的成績單。它會反映不同裝置性能、網路環境、頁面版本與實際廣告投放情境下,使用者整體遇到的廣告負載。
6
13
也正因如此,CrUX 的優勢是能發現持續存在的使用者體驗問題;限制則是不能直接拿來追查單一廣告請求或單筆競價結果。
此外,這些廣告指標仍屬實驗性功能。Google 明確表示,實驗性 CrUX 指標會隨演進而調整,團隊不應把目前的數值、定義或可用性視為永久規格。
12
到哪裡看得到資料?
CrUX API:查目前的彙總快照
CrUX API 提供來源(origin)與網頁 URL 層級的低延遲真實使用者彙總資料。查詢來源時,會彙整該來源下符合資格的網頁體驗;URL 層級則更具體,但前提是該頁有足夠資料可供報告。
5
若你需要建立網站目前的基準線,或把資料納入內部監控與報表,CrUX API 是較直接的選擇。
CrUX History API:看每週趨勢
CrUX History API 提供每週時間序列,可查看約 6 個月、共 40 個每週資料點,並支援來源與網頁層級查詢。
1
11
這是評估改版成效最實用的管道。發布商可以在減少同時可見版位、移除某個第三方需求合作夥伴、調整延遲載入策略,或限制高資源素材後,觀察廣告指標是否出現持續改善。
CrUX Vis:免寫程式的趨勢圖
CrUX Vis 將 CrUX History API 的每週資料視覺化,並設有 Ad Metrics 頁面。只要網站位於 CrUX 資料集內,就能快速查看歷史變化,不必自行串接 API。
3
Chrome DevTools:用於本機除錯,不可取代欄位資料
Chrome DevTools 適合在本機檢查與重現頁面的效能行為。Google 的更新說明也提到,DevTools Performance 面板已整合 CrUX 欄位資料,協助開發者把真實使用者問題放回本機除錯情境中理解。
4
但本機 trace 無法重現真實使用者裝置、連線、同意狀態、競價與素材變化的分布。正確流程是:先用 CrUX 找出持續性的體驗問題,再用 DevTools 調查可能原因。
哪些網站能取得報告?
CrUX 不會涵蓋所有網站或每一個 URL。網站要進入資料集,使用者、來源與網頁體驗都必須符合資格,包括網站須公開可被發現、具有足夠人氣與樣本量,以保障使用者隱私。Google 並未公開一個保證能入列的統一流量門檻。
2
10
至於新的廣告指標,報導指出,資料也僅涵蓋宣告授權賣方的合格網站,亦即具備 ads.txt 宣告的情況。
17
實務上有兩點要注意:
- 一個來源可能有 CrUX 資料,但個別 URL 的樣本不足,因而沒有頁面層級資料。
- 看不到廣告指標,不代表該頁沒有廣告、也不代表沒有廣告負擔;可能只是樣本不足或未符合報告資格。
這四個數字能幫你診斷什麼?
| 想回答的問題 |
優先看哪項指標 |
可反映的問題 |
| 使用者眼前同時有多少廣告在搶注意力? |
Ad Count |
可見廣告造成的擁擠程度 |
| 廣告吃掉多少螢幕空間? |
Ad Density |
可視區域中的視覺侵入程度 |
| 廣告下載與傳輸了多少資料? |
Ad Weight(Network) |
可歸因於廣告的網路資源成本 |
| 廣告讓瀏覽器多做了多少處理工作? |
Ad Weight(CPU) |
可歸因於廣告的瀏覽器運算負擔 |
對發布商而言,這能分辨「版面配置問題」與「廣告技術效率問題」。減少可見版位,通常更可能影響廣告數量與密度;精簡第三方腳本、需求路徑或高負載素材規則,則可能對網路與 CPU 負載更有幫助。
廣告買方與發布商可以怎麼用?
Google 將這些新數據定位為協助廣告買方與賣方評估受眾廣告負載體驗的工具。
15
短期內,最務實的用途是營運與測試:
- 發布商:把廣告負載趨勢與營收、Core Web Vitals、互動率等第一方指標一起追蹤。
- 廣告營運團隊:測試版位規則、需求路徑、延遲載入與高資源素材限制。
- 媒體買方:若投放目標重視低摩擦使用者體驗,可將指標作為評估供應來源或媒體品質的其中一項訊號。
不過,四項數字無法單獨替廣告庫存定價。它們並不衡量可視度、注意力、受眾契合度、無效流量、轉換率或品牌成效。目前也沒有足夠公開證據顯示,業界已普遍以它們建立出價調整因子、CPM 標準或強制採購規則。
對 SEO 與搜尋排名有何意義?
廣告過多或資源消耗過高,若造成載入變慢或互動反應變差,確實可能間接影響 SEO,因為它可能惡化使用者實際感受到的效能。CrUX 原本就可揭露真實使用者的效能條件,新指標則補充了廣告可能帶來的額外負擔。
6
13
但結論必須精準:Google 並未表示 Ad Count、Ad Density、Ad Weight(Network)或 Ad Weight(CPU)是 Google Search 的直接排名訊號。 不應以猜測中的排名門檻來優化這些數字。
建議的實作流程
- 先在 CrUX API 或 CrUX Vis 建立來源層級基準線。
- 若有資料,再查看 URL 層級,確認問題是否集中於特定頁面模板。
- 每次只做一項可控調整,例如減少可視區域的同時廣告數、限制大型固定式廣告,或移除非必要的第三方路徑。
- 透過每週 CrUX History 趨勢,同步觀察營收、Web Vitals 與第一方互動指標。
- 用 DevTools 本機驗證與除錯,但不要把單次本機結果當作真實使用者資料的替代品。
CrUX 廣告指標真正帶來的價值,是把過去只能從版位數或合成測試推估的問題,拆成「視覺擁擠」與「資源成本」兩個層面。由於它們仍是實驗性、且屬彙總資料,最適合用於有證據的持續測試,而非當成單一品質評級、競價依據或 SEO 規則。
12
13