本篇內容
CrUX Vis 是 Chrome 團隊推出的免費視覺化工具，網址是 cruxvis.withgoogle.com。你在首頁的輸入框打上網址，它就會把這個網站最多 40 週、來自真實 Chrome 使用者的體驗資料，畫成一張張折線圖：LCP 多快、INP 多靈敏、CLS 穩不穩，每週一個點，一路鋪到最近一次更新。打開就能查，不用登入、不用申請金鑰、不用寫程式；查完還能用右上角的 Copy Link 把整份報告的連結分享給同事。
它存在的理由要從一個斷層講起。Google 有一套叫 Chrome User Experience Report（CrUX）的資料集，收錄超過 1,500 萬個網站的真實使用者體驗，是 Core Web Vitals 實際體驗資料的重要來源。想看近期實際體驗與單次檢測診斷，PageSpeed Insights 很方便；想看「我的網站這半年到底有沒有變快」，過去常用的路徑是自己寫程式呼叫 CrUX History API，或去 BigQuery 跑每個月才發佈一次的資料集。中間缺一個打開就懂、以週為單位的圖形介面，CrUX Vis 補的就是這個位置。它 2024 年 10 月上線，接替已在 2025 年 11 月底除役的 CrUX Dashboard，現在是官方欽點的歷史走勢查看工具。
先記住兩個限制，免得期望落差。第一，CrUX Vis 只反映符合公開資料集收錄條件的網站；流量太小、樣本不足或未符合其他收錄條件的站，可能查不到資料。第二，官方把它放在 withgoogle 實驗網域，定位是實驗工具，功能與介面仍可能調整；要看超過 40 週或需要自己組分析的需求，出口是 BigQuery 資料集。下文以操作畫面與本站 seo.whoops.com.tw 的十個月實測走勢，說明六個頁面怎麼讀，以及如何搭配診斷工具判斷下一步。
重點先看：CrUX Vis 是 Chrome 團隊的免費網頁工具，把 CrUX History API 的每週歷史資料畫成 40 週走勢圖。輸入網址即可查，免登入、免金鑰，報告連結可以直接分享。
它跟 PageSpeed Insights 回答不同問題：PSI 同時給近期實際體驗、單次實驗室檢測與改善建議，CrUX Vis 給真實使用者最多 40 週的體驗變化。看趨勢用 CrUX Vis，找「哪裡慢、怎麼改」回 PSI 或現場檢測工具。
兩個限制先記：公開資料有收錄門檻，查不到資料不代表網站沒有訪客；工具本身是實驗定位。需要跨年度的 origin 月資料，可改用 BigQuery。
CrUX Vis 是什麼？把真實使用者體驗畫成 40 週走勢的免費工具
官方對這個工具的定位寫得很直白：CrUX Vis 是 Chrome 團隊的工具，用視覺化的方式探索 Chrome User Experience Report 的資料，針對特定網頁或整個網站，並附上延伸閱讀的文件連結。首頁的大標更具體：Visualize time series of real-world web performance data，把真實世界的網站效能資料畫成時間序列。這裡的 real-world 不是行銷詞，而是有明確技術含義的區分：這些數字來自真實 Chrome 使用者造訪時回傳的匿名化體驗資料，而不是工具自己在機房裡跑一次檢測的結果。
Lighthouse 的實驗室檢測，量的是一次模擬載入；PageSpeed Insights 同時呈現這份診斷，以及 CrUX 最近 28 天的實際使用者體驗。CrUX 則收錄符合設定與平台條件的 Chrome 造訪資料，經匿名化、聚合後呈現體驗分佈。依官方方法論，資料涵蓋符合條件的桌面 Chrome 與 Android Chrome，不含 iOS Chrome、Android WebView 或其他 Chromium 瀏覽器。Google 搜尋會使用 Core Web Vitals，但通過門檻不保證排名第一，origin 報告也不能代表每個頁面的體驗。想理解 LCP、INP、CLS 三項指標的定義與門檻，站上已有Core Web Vitals 的完整拆解，本文專注在工具這一層。
公開報告不提供個別使用者的識別資訊。每個歷史資料點涵蓋滾動的 28 天期間，未達收錄條件的組合就不發佈。報告預設畫的第 75 百分位（p75）不是平均值：LCP p75 為 2 秒，表示這個期間約 75% 的合格造訪經驗，LCP 不超過 2 秒，其餘約 25% 更慢；它不表示每位訪客都在 2 秒內看到最大內容。Core Web Vitals 使用 p75 評估，並將行動與桌面裝置分開判讀。
名字裡的 CrUX 是 Chrome User Experience Report 的縮寫，Vis 就是 visualization。常見的混淆是把這個網頁工具跟 CrUX API 想成同一件事，或以為它附帶獨立的 API。實際上 CrUX Vis 是網頁介面，資料來自 CrUX History API；你自己要程式化取用時，該用的是 CrUX API 或 CrUX History API 本身，文後的工具分工會再拆開。
這個工具是怎麼來的：從 BigQuery 的慢，到 CrUX Dashboard 的除役
要看懂 CrUX Vis 在官方工具版圖裡的位置，得先知道它前一輩的工具為什麼退場。CrUX 資料集最早公開的形態是 BigQuery：整包資料放在 Google Cloud 的 BigQuery 裡，每個月發佈一次，想查就得寫 SQL，查 long-tail 的歷史很好用，但每次都要跑查詢、等結果，拿它當隨手打開的儀表板太慢。2020 年 Core Web Vitals 掀起需求後，官方在 BigQuery 之上做了一個 Looker Studio 架構的 CrUX Dashboard，自動把每個月的資料整成圖表，一時之間成為大家看歷史走勢的標配。
問題出在規模。官方在除役公告裡承認，Dashboard 從來不是為大規模使用打造的技術，尤其每月第二個星期二的資料發佈日時常故障，原文的說法是 was not built on the right technology for wide-scale use。於是 2023 年官方改推 CrUX History API：查詢即時回傳、架構可以擴充，資料從每月一次變成每週一次，歷史窗從最初 25 週擴大到 40 週，對齊 Dashboard 的水準。API 上線一年多後，第三方視覺化工具陸續出現，官方決定自己也做一個，2024 年 10 月 1 日以實驗工具之姿推出 CrUX Vis，第一版由 2024 年夏季實習生 Jamison O’Keefe 起草。
從每月變成每週，對實際工作的影響比聽起來大。每月一個資料點的年代，月中上線的改版要等下一批月資料公布才有新的觀察值，而且單一個點分不清是改版造成，還是流量組成剛好變化；每週一個點、每點涵蓋 28 天的滾動設計，會平滑短期波動；相鄰兩點重疊 21 天，讀圖時不能把它們當成互相獨立的測量。40 週的歷史窗也夠把上一輪改版的痕跡和這一輪的改善放進同一張圖比對，這正是 Dashboard 時代大家最想要、後來由 History API 補上的能力。
We’re pleased to launch CrUX Vis – a new experimental CrUX tool to allow you to visualize CrUX History API data:
— Chrome UX Report (@ChromeUXReport) October 1, 2024
https://t.co/T14RdwlYrd
This experiment was first put together by Jamison O’Keefe, our 2024 summer intern. https://t.co/yw6soaJBy7
接棒的時間點值得記清楚。2025 年 9 月官方部落格正式宣佈 CrUX Dashboard 除役，2025 年 11 月底之後不再更新，公告裡直接推薦 CrUX Vis 作為替代品，原話是「一個視覺化 CrUX 歷史資料的新工具，比舊 Dashboard 有諸多優勢」，並附上鼓勵試用的字句。也就是說，如果你過去幾年習慣用 Looker Studio 那套 Dashboard 看走勢，現在的官方答案就是 CrUX Vis；如果你是在找 CrUX Dashboard 而找到這篇文章，結論先給你：Chrome 團隊已停止維護與支援原 Connector；若要沿用舊報表，可以自行改接 BigQuery。
CrUX Dashboard deprecation | Blog | Chrome for Developers – via @tunetheweb #seo https://t.co/6XHCm8L4sW
— Sitebulb (@sitebulb) October 2, 2025
BigQuery 那一條路則繼續活著，這是另一件容易搞混的事。除役的是 Dashboard 那層皮，不是底下的資料集：官方明講 BigQuery 資料集仍持續維護，供長期分析使用，只是它的強項本來就不是「快」。把三個世代的關係一句話收攏：BigQuery 是每月的原始資料倉儲，History API 是每週的即時查詢介面，CrUX Vis 是長在 History API 上的免費圖形介面，而 CrUX Dashboard 已經功成身退。想追這段歷史的原始紀錄，官方除役公告與Google Groups 上的上市公告都還在線上，全文可讀。
實際操作：從輸入網址到看懂報告，五分鐘上手
操作很簡單，簡單到官方說明文件多半用不著對照。首頁有 URL 輸入框與送出圖示，你可以貼上整個網址，例如某篇文章的完整 URL，也可以只輸入網站本身，例如 seo.whoops.com.tw，按下 Enter 或點送出圖示，報告就會載入。載入後左側出現六頁側欄，預設停在 Core Web Vitals 總覽；側欄可以收合，首頁的星號能把常查的站釘在最愛，方便下次直接回到最近的查詢。
輸入網址或輸入網站，看到的是兩種不同層級的資料，這是第一個要弄清楚的選擇。輸入 seo.whoops.com.tw 這種站點層級（origin），報告彙整整個網站所有頁面的體驗；輸入單一頁面的完整網址（URL 層級），報告只看那一頁。官方資料集收錄 1,500 萬個以上的站點，但站點有資料不代表站上每個頁面都有資料，流量集中在少數頁面的網站尤其明顯，這個落差在排查段會再展開。報告載入後，頁面上方的 Controls 面板可以隨時切換這兩種層級，也能切換 Phone、Desktop、Tablet 或全部裝置。
報告頁真正好用的地方是連結可以直接分享。右上角的 Copy Link 會複製整份報告的狀態，包含你看的頁面、網址、層級、裝置與顯示方式，貼給同事打開就是你看到的同一份畫面，也可以存成書籤當作例行檢查的入口。連結長相像這樣，看懂參數就能自己改：
https://cruxvis.withgoogle.com/#/?view=cwvsummary&url=https%3A%2F%2Fseo.whoops.com.tw%2F&identifier=origin&device=PHONE&periodStart=0&periodEnd=-1&display=p75s幾個參數拆開看：view 決定停留在哪一頁，cwvsummary 是 Core Web Vitals 總覽，換成 loadingperf 或 ads 就跳到載入效能或廣告指標頁；url 是查詢目標，會做 URL 編碼；identifier 區分 origin 與 URL 層級；device 可填 PHONE、DESKTOP 或 TABLET；periodStart 與 periodEnd 決定時間窗，0 到 -1 就是全部 40 週；display 的 p75s 指以第 75 百分位呈現，改成分佈模式則會顯示 good、needs improvement、poor 三個區塊的比例變化。不用背這些，知道連結會說話，排查別人傳來的報告時就看得懂對方在看什麼。
順手一個社群流傳的技巧：有人在 Chrome 網址列把 cruxvis 設成自訂搜尋引擎，之後打 cruxvis 按 Tab 再輸入網址，就能跳過首頁直接開報告。這是使用者自行設定的快捷方式，出自 SEO 工程師 Kevin Faust 的分享文，不是官方內建功能，嫌設定麻煩的話，照正規流程開首頁查詢也只多一次點擊。
六個頁面分別在看什麼：從三項總覽到廣告指標
側欄的六頁可以用一張表掌握，每頁回答的問題都不一樣：
| 頁面 | 主要指標 | 回答的問題 |
|---|---|---|
| Core Web Vitals | LCP、INP、CLS | 整體體驗現況如何，哪一項需要優先處理 |
| Loading Performance | LCP、FCP、TTFB、RTT、LCP 資源類型等 | 頁面載入慢在哪一段 |
| Interactivity | INP | 頁面回應輸入的速度 |
| Visual Stability | CLS | 版面是否穩定、會不會跳動 |
| Ad Metrics | Ad Count、Ad Density、Ad Weight CPU／Network | 廣告的數量與資源負擔 |
| All Metrics | 以上全部 | 一站式總覽，適合截圖存檔 |
Core Web Vitals 這頁是所有人該停留最久的一頁。它把 LCP、INP、CLS 三項指標各自的判定與走勢攤開，摘要文字直接告訴你現況屬於 good、needs improvement 還是 poor，以及方向是穩定、改善還是惡化，例如「Loading Performance is good and stable」這樣的句子。官方給這頁的建議用法就是看哪些指標低於建議值或正在變差，再循著連結進入後面三個分類頁深入。對照門檻：LCP 的 good 線是 2.5 秒，INP 是 200 毫秒，CLS 是 0.1。
Loading Performance 頁把載入這件事拆得更細。除了 LCP 本身，還有首次內容繪製的 FCP、伺服器回應時間的 TTFB、來回延遲的 RTT，以及 LCP resource type 與 LCP image subparts 這類下鑽資訊，告訴你最大內容元素是文字還是圖片、那張關鍵圖的載入拆成哪些階段。這幾條線的解讀有固定路徑：TTFB 偏高先查伺服器回應與快取層，FCP 與 LCP 之間的差距拉大，代表最大內容元素拖住了整體觀感，而最大元素常常是圖片，資源類型與圖片分解的資訊就是為了把這一步定位出來。Interactivity 頁與 Visual Stability 頁各自聚焦 INP 與 CLS，連同 Form Factors 一起看，能確認體驗問題是否集中在特定裝置類型。如果你的網站有放廣告，Ad Metrics 頁會給廣告數量、廣告密度與 CPU、網路兩種廣告負擔的走勢，官方的廣告工具指南也把 CrUX Vis 列為廣告量測的入口之一；本站實測這頁顯示 unavailable，後面會說明它與廣告量測收錄條件的關係。
顯示模式的切換值得自己動手試一次。p75 模式畫的是第 75 百分位那條線，適合追蹤多數造訪經驗是否達標，也是 Google 判定 Core Web Vitals 通過與否的口徑；分佈模式則把每個時期 good、needs improvement、poor 的比例疊成色帶，適合看結構變化，例如某次改版後 poor 佔比突然放大。兩種模式說的是同一批資料的兩個切面，交叉著看，比只盯單一數字更能還原真相。
實測：用 CrUX Vis 查 seo.whoops.com.tw 的十個月走勢
以下是我們在 2026 年 10 月 11 日實際查詢本站 seo.whoops.com.tw 的結果，裝置設在手機（phones），層級設在 origin。先講結論：三張摘要判定全部是 good，Loading Performance 標註 good and stable，Interactivity 與 Visual Stability 標註 good and improving，資料日期落在 2026-10-03。但摘要只是入口，真正的價值在折線圖：走勢會把摘要看不到的故事說出來。
LCP 的第 75 百分位走勢是完整的一段改善史。資料從 2025-12-07 那週起算，第一個點是 1346 毫秒；2026 年 1 月到 2 月明顯升高，落在約 1600 到 2059 毫秒之間，最差的一點出現在 2026-01-18 當週的 2059 毫秒；之後一路改善，2026-06-14 當週落到最低點 885 毫秒；7 月到 10 月穩定維持在約 950 到 1070 毫秒，距離 2.5 秒的 good 門檻有充足餘裕。同一張圖看下來，你能明確回答「網站有沒有變快」：年初約 2000 毫秒的水準，截至 10 月落在約 1000 毫秒上下，約為年初高點的一半。
INP 那條線示範了缺值的判讀。折線到 2026-05-10 當週才出現第一個點，數值 78 毫秒，之後穩定在約 75 到 79 毫秒；更早的週數全部顯示 N/A。這只能確認早期沒有可報告的 INP，可能與該指標的有效互動樣本及收錄條件有關，不能據此推斷當時沒有訪客，或確定是哪一項條件未達標。看見 N/A 時，先核對資料範圍與樣本條件，再查其他指標。
CLS 的走勢則是從 0.1 到 0.11 之間收斂到 0.00，時間點在 2026 年 6 月之後，與 LCP 的最低點同期。兩項指標在同段時間改善，適合回查當時的部署、外掛、主機與流量紀錄；聚合曲線本身無法確定由哪次調整造成。你自己的網站也可以把每次改版的上線日期記在報告旁，追蹤完整 28 天資料窗，再和部署紀錄交叉核對。想深入行動裝置速度為什麼值得這樣追，站上有行動裝置網站速度的完整指南。
把 40 週折線變成判斷，可以用三個步驟走。第一步看判定與方向：每個指標的摘要會標 good、needs improvement 或 poor，搭配 stable、improving 或 degrading，先找出需要深入檢查的項目。第二步找轉折點，再對照部署、外掛更新、主機遷移與流量組成的時間線，確認有哪些可能原因；時間重合不等於因果成立。第三步持續追蹤到改版後完整的 28 天資料窗，檢查改善有沒有回彈。相鄰資料點有 21 天重疊，連續幾點改善不能當作多次獨立驗證；需要即時排查時，補上 RUM 或 DevTools。
讀圖時還要記得 CrUX 的資料粒度限制。origin 層級的折線是全站混合，某一頁的劇烈變化可能被其他頁面稀釋；反之你在單頁看到的問題，也可能只是那一頁流量小、樣本震盪。養成交叉看的習慣：總覽頁下結論，單頁報告找證據，兩邊對得上再行動，對不上就先懷疑樣本，這比直接改網站省得多。
報告的互動細節也做得到位。折線圖可以用鍵盤左右方向鍵逐點導覽，焦點停在哪個點，就讀出那個點對應的 28 天資料區間與 LCP、INP、CLS 三個數值，寫報告引用數字時很好用，不需要自己對著圖猜刻度。順帶一提，我們查的是手機資料；同一個站在桌機上的走勢、樣本量與判定可能不同，裝置維度永遠分開看，這是 CrUX 的基本紀律。
Ad Metrics 頁在本站此次查詢中，Ad Count、Ad Density、Ad Weight: CPU、Ad Weight: Network 四項指標全部顯示 unavailable。本站沒有放廣告，但不能只從這個字樣判斷任何網站是否有廣告：官方廣告量測方法論另要求網站在 ads.txt 列出至少一個授權銷售商，才納入這類指標。未符合 ads.txt 條件或缺乏可報告資料，也可能沒有數字。若你的站靠廣告變現，可把廣告指標與 CWV 走勢並列，觀察廣告負擔與體驗變化；廣告指標本身沒有 CWV 的 good／poor 門檻。
跟 PageSpeed Insights、CrUX API、BigQuery 怎麼分工
CrUX 周邊的工具名字很像，職責其實切得很乾淨。官方在 CrUX 方法論文件裡有一頁工具總覽，把 CrUX Vis、CrUX API、History API、BigQuery 各自的位置講清楚；這裡用實際使用情境重講一遍，因為選錯工具比不會用工具更浪費時間。
| 工具 | 資料形態 | 最適合的事 | 門檻 |
|---|---|---|---|
| CrUX Vis | History API 每週資料的視覺化 | 看 40 週走勢、驗證改善、分享報告 | 零，開網頁即可 |
| PageSpeed Insights | 單次實驗室檢測＋CrUX 現況 | 診斷哪裡慢、拿具體改善建議 | 零 |
| CrUX API | 最近 28 天彙總 | 程式化查單一站點的現況 | 申請 API 金鑰 |
| CrUX History API | 每週歷史，40 週 | 程式化拉長期走勢、自建報表 | API 金鑰 |
| BigQuery | 每月發佈的 origin 資料集 | 跨站大規模分析、超長期歷史 | Google Cloud、SQL；免費額度外可能計費 |
跟 PageSpeed Insights 的分工最常被問。PSI 打開輸入網址，也會給你一段「實際使用者體驗」的判定，看起來跟 CrUX Vis 像，但定位不同：PSI 的實際體驗區塊給的是最近一個週期的靜態判定與分佈，重心放在它同時跑的 Lighthouse 實驗室檢測與逐項改善建議；CrUX Vis 不做檢測也不給建議，只把歷史資料畫成走勢。一句話選法：今天要動手改網站，去 PSI 拿診斷；要向同事展示過去一季的實際體驗變化，去 CrUX Vis 看 40 週折線。站上有PageSpeed Insights 整合 Lighthouse 的完整教學，檢測與建議那側的細節都在那篇。官方的web.dev 量測入門也是這樣分工的：CrUX Vis 被定位為架在 History API 上的歷史儀表板，與現場檢測工具分列不同層。
跟 API 家族的分工，就是「cruxvis api」這個查詢背後想釐清的事。CrUX Vis 沒有附帶 API，它只是消費 History API 資料的網頁工具；你也不需要它的 API，因為它畫的資料本來就出自公開的 CrUX History API。想要把 CrUX 資料接進自己的儀表板、對多個競品做自動追蹤、或追蹤部署後的長期體驗變化，正確做法是直接呼叫 CrUX History API，每週資料、40 週歷史，回傳 JSON 自己組。只想查單一站點最近 28 天的彙總，用 CrUX API 就夠。工具與 API 的選擇標準只有一條：要人看圖還是要程式吃資料。
BigQuery 負責跨年度與大範圍的分析。標準 CrUX BigQuery 資料是每月、origin 層級，適合跨站比較、國家與裝置分析，不是單一頁面超過 40 週的歷史替代品。需要 Google Cloud 與 SQL，官方提供每月免費查詢額度，超出後才可能計費，詳見CrUX BigQuery 文件。對多數網站管理者來說，日常節奏就是 CrUX Vis 看趨勢、PSI 做診斷；BigQuery 等真的有那種題目再開。Chrome 團隊 Rick Viscomi 的下方官方影片介紹 BigQuery 分析方法；這支是 2020 年的教學，適合了解分析思路，當前資料欄位與操作以文件為準。
查不到資料怎麼辦：四個常見原因與排查順序
輸入網址卻什麼都查不到，是新手最常見的挫折，官方說明文件特別為此寫了一段。先建立正確認知：CrUX 資料集收錄超過 1,500 萬個站點，但收錄有門檻，樣本不足的站不會出現，這是為了隱私與統計有效性，不是查詢方式錯了就永遠查不到。排查時可照這個順序縮小範圍：
- 確認查的是實際載入、重新導向後的協定與子網域。例如 http://example.com 若轉到 https://www.example.com，就查後者；CrUX 不會依 HTML 的 rel=canonical 把不同 origin 合併。
- 檢查子網域：www.example.com 與 example.com 在 CrUX 裡是兩個不同的站點，各收各的資料，查錯邊就會以為沒資料。
- 先用站點層級查，有資料再下鑽到單一頁面：站點層級把全站樣本集中，最容易過門檻；特定 URL 的流量不夠就會缺席，但不能只從缺值確定是哪一項收錄條件未達標。
- 換裝置再查一次：手機有資料、桌機沒有也可能發生，反之亦然。排查時至少把手機與桌機各查一輪，再下結論。
四步都走完仍無資料，再依CrUX 收錄方法論核對 URL／origin 是否回應 200、頁面是否可公開索引，以及合格 Chrome 樣本是否足夠。收錄門檻數字未公開，單憑查不到不能確定原因，也不能代表網站沒有訪客。等公開資料出現之前，可以先在網站安裝 web-vitals 等 RUM 程式，把真實訪客的 LCP、INP、CLS 回傳到自己的分析工具。PSI 的實驗室檢測也仍可用，但它不代表訪客體驗分佈。
誰該把 CrUX Vis 放進例行工作，誰不用
官方在 2026 年 9 月更新的廣告工具指南裡，給了 CrUX Vis 一個很少見的評語：不需要工程知識，非技術使用者也能上手。配上演進脈絡，這個工具的目標族群很清楚：網站管理者、行銷人員、內容站的站長，任何需要對網站體驗「交代趨勢」的角色。每週一更新、報告可分享、判定有門檻對照，剛好構成一個輕量的例行檢查節奏：每月花兩分鐘看三條線的方向，改版後持續追蹤完整 28 天資料窗，檢查是否退化。
它不適合的場景也很明確。CrUX 是 28 天滾動彙總，今天上線的問題要等資料窗累積才看得出惡化，拿它當即時警報系統會延遲好幾週，線上事故該靠自己的監控。它也不做診斷，折線告訴你 INP 變差了，為什麼變差要回 PSI、Lighthouse 或現場資料找答案，這兩層工作別混在一起。至於 Core Web Vitals 在搜尋排名裡的位置，站上網頁速度對 SEO 排名的影響與網站速度為什麼重要兩篇有完整討論，工具本身只負責把事實攤開，排名判斷是另一回事。
把 CrUX Vis 放回你的工具箱，我會這樣安排位置：在技術 SEO 的例行盤點裡，它是走勢層的第一站，每月看一次全站三項指標的方向；改版或主題大改後，持續追蹤至少完整 28 天資料窗，檢查 good 是否維持；需要動手改善時，再回 PSI 逐項查；如果改版後同時出現排名下降，可對照改版後排名下降的排查順序，分開檢查體驗、轉址與索引問題。不需要的投入就到此為止，多數網站用到這個深度已經足夠，更深的挖掘留給有明確問題要回答的時候。
CrUX Vis 常見問題
CrUX Vis 是免費的嗎？要登入或申請什麼嗎？
免費，不用登入 Google 帳號，不用申請 API 金鑰，打開 cruxvis.withgoogle.com 輸入網址就能查，報告連結也能直接分享。它讀的 CrUX 資料集本身就是公開資料，工具只是把資料畫成圖的介面。若你需要程式化取用，那才要申請 CrUX API 或 History API 的金鑰。
CrUX Vis 有 API 嗎？跟 CrUX API 是同一個東西嗎？
沒有附帶 API，兩者也不是同一個東西。CrUX Vis 是網頁工具，它視覺化的資料來自 CrUX History API；你要在自己程式裡拿同樣的資料，該呼叫的是 CrUX History API 本身，每週資料、40 週歷史、回傳 JSON。只想查最近 28 天彙總的話，用 CrUX API 就夠，不必經過 CrUX Vis。
CrUX Vis 跟 PageSpeed Insights 差在哪？
分工不同。PageSpeed Insights 跑單次 Lighthouse 檢測，給逐項診斷與改善建議，附帶最近一期的實際使用者體驗判定；CrUX Vis 不做檢測也不給建議，只把真實 Chrome 使用者過去 40 週的體驗畫成走勢圖。要動手改善網站用 PSI，要驗證長期趨勢或向別人展示改善成果用 CrUX Vis，兩者搭配比二選一好用。
為什麼我的網站在 CrUX Vis 查不到資料？
可能是合格 Chrome 樣本不足，也可能是查錯協定、子網域、層級或裝置，或頁面未符合公開資料的收錄條件。先查實際載入的最終網址，再查 origin 與不同裝置；仍無資料時核對回應 200、可索引性與官方收錄方法論。門檻數字未公開，不能只從缺值確定原因，可用 PSI 診斷與自有 RUM 補足。
資料多久更新一次？報告上的日期是什麼意思？
依CrUX History API 官方說明，每週一更新，每個資料點涵蓋 28 天的滾動資料；相鄰兩點重疊 21 天。報告標題的 as of 日期（例如 as of 2026-10-03）是最新一個資料點的結束日，不是「今天即時」的數字。這也表示今天發生的變化，要到幾週後才會完整反映在曲線上。
Ad Metrics 頁面誰該看？我的網站為什麼全是 unavailable？
這頁用來觀察廣告數量、密度，以及 CPU 與網路負擔。本站此次四項均顯示 unavailable；官方另要求 ads.txt 至少列有一個授權銷售商，才收錄廣告指標。沒有廣告、未符合收錄條件或缺少可報告資料都可能沒有數字，不能只從 unavailable 判斷是哪一種原因。
以前用的 CrUX Dashboard（Looker Studio）還能用嗎？
Chrome 團隊已停止維護與支援原 CrUX Connector，原連接方式自 2025 年 11 月底後停止更新。官方建議改用 CrUX Vis；如果要保留原 Looker Studio 報表，也可以自行改接仍維護中的 BigQuery 資料集。
想看超過 40 週的歷史資料怎麼辦？
CrUX Vis 對應 History API 最多 40 週的資料窗。更早的 origin 月資料可用 CrUX BigQuery 資料集，適合跨年度或跨站分析；它不提供相同的單頁歷史口徑。需要 Google Cloud 與 SQL，每月免費查詢額度外可能計費。
用 CrUX Vis 會影響 Google 排名嗎？
不會，查看報告只是讀取公開資料，與排名加分無關。Google 的排名系統會使用 Core Web Vitals，但仍綜合相關性等多種信號，通過門檻不保證高排名。CrUX Vis 可以協助追蹤實際體驗變化，origin 報告也不能代表每個頁面的狀況。
手機查得到、桌機查不到，正常嗎？
可能發生。CrUX 依裝置分開聚合，手機與桌機各自需要足夠的合格樣本；某一側有資料，不能推論另一側也能報告。Core Web Vitals 也按裝置判讀，手機 good 不代表桌機也過關。
站點查得到、單一頁面查不到，正常嗎？
正常。站點層級把全站樣本集中，最容易達到統計門檻；單一 URL 只有那一頁的訪客當樣本，流量分散的網站很多內頁都會缺席。遇到這種情況，先看站點層級掌握整體，再挑流量最大的幾個頁面單獨查，通常比逐一檢查每個網址更有效率。
CrUX Vis 是實驗工具，會不會哪天就關了？
官方仍將它定位為實驗工具，也在 CrUX Dashboard 停用公告中推薦它。官方沒有承諾何時離開實驗狀態或永久提供服務。Copy Link 保存的是查詢狀態，歷史資料會持續更新；要固定引用某一期數字，請另存當期畫面或 API 結果。目前的程式化資料入口包括 History API 與 BigQuery。
討論與提問