網站速度測試別只看分數：七步找出真正的瓶頸
網站速度測試不是收藏一張總分截圖：先用 Core Web Vitals 欄位資料確認 LCP、INP、CLS 是否越線，再用固定條件的受控量測找根因，將建議依傳輸、執行或回應屬性排先後，修一項驗一項；外部檢測報告的查核與投資停損，一併整理成判斷流程。
想像一個場景：星期一早上，客戶傳來一句「官網是不是變慢了」；下午的會議裡，有人把訂單下滑歸因給速度；傍晚，配合的廠商送來一份紅字滿滿的檢測報告，後面附著報價單。三個訊號指向同一個疑問，卻沒有一個告訴你：慢的是誰、慢在哪個環節、修了值不值得。
網站速度測試要回答的從來不是「網站有幾分」，而是三個可以被驗證的問題：使用者有沒有真的受影響、慢的原因出在哪一層、修了之後有沒有效。接下來的十個段落就是走完這三個問題的判斷順序，每一段對應你該做的一個決定，從定義症狀一路走到停損。
快速重點：先看真實使用者欄位資料有沒有越線，Core Web Vitals 以第 75 百分位判讀；紅了才進受控測試找原因，瓶頸歸成傳輸、執行、回應三類，修一項回測一項。欄位資料是 28 天彙整，要有耐心；及格之後，把資源移往更值得的地方。
開始測之前，先把「網站好像變慢」寫成可驗證的問題
先別開工具。「網站很慢」是印象，不是問題；問題要有頁面、有指標、有裝置，才能被測、被修、被驗證。花十分鐘把症狀寫清楚，比多跑十次測試更有用。
症狀有三種常見來源，各自需要不同的整理方式。分析數據出現異常，例如工作階段變短、行動裝置的轉換掉下來，先用裝置與流量來源維度切開再看，平均值會把問題稀釋掉，也可能把某一次活動的副作用算到速度頭上。客戶或同事的直覺回報，要換成可測的描述，問清楚是哪一頁、做什麼動作時、用什麼裝置感覺慢；「感覺慢」裡常藏著版面跳動或按鈕沒反應，對應的指標完全不同。外部廠商的檢測報告，先收著，後面有一整段教你逐項查核。把來源分清楚還有一個好處：之後驗證修改時，你知道該拿什麼證據回去交代，是客戶的回饋、報表的數字，還是廠商的重測。
裝置的優先順序很明確：先看手機。Statista 的流量占比統計追蹤多年，全球網站造訪約有六成發生在行動裝置上；web.dev 的官方文件也把載入速度與使用者滿意、留存放在同一個脈絡裡討論。六成訪客拿著網路與運算資源都比桌機差的裝置，你在桌機上覺得順，不代表他們在手機上等得到畫面。
頁面的優先順序由站型決定。內容站先挑流量最大的文章頁，它們承接搜尋來的訪客，欄位資料也最容易累積；電商先挑商品頁與結帳頁，結帳多等一秒，代價直接反映在訂單上；服務型網站先挑聯絡表單與預約頁，詢問就是這類站的營收入口。資源有限的時候，從商業價值最高的頁面測起，不要從「最好測的」開始，那是兩件事。
「速度影響排名」這件事，一句話交代就夠：Core Web Vitals 是頁面體驗裡的一小部分訊號，內容相關性的優先級更高，Google Search Central 的文件寫得很直白。速度與搜尋之間的完整關係，交給網頁速度與排名的深讀，判斷鏈不必背著它走。會議裡把排名下滑直接歸給速度，也先擋下來，看下一步的指標再說。
收斂成一張便利貼就夠：「某商品頁，行動裝置，LCP 與 INP 是否越線；來源，客戶回報結帳變慢。」有這一行字，後面每一步都知道自己在驗證什麼。
還有一種症狀來源容易被忽略：自己。網站是你熟悉的，你的瀏覽器有快取、你的連線是辦公室等級、你只看自己常去的那幾頁；你的「感覺變慢」和訪客的實際體驗之間，隔著一整層環境差異。把自己也當成第四種症狀來源，用同一張便利貼處理，判斷才不會被日常習慣綁架。
真實訪客慢，還是只有測試環境慢？
同一個網址，貼進兩個測速入口，一份給你綠燈，另一份滿頁紅字，這種事每天都在發生。兩份報告都沒有說謊，因為它們量的母體不一樣。測速的第一個判斷，先問「這個數字怎麼來的」，再問網站幾分；分數是儀器讀數，看讀數之前要先認識儀器量的是誰。
矛盾的來源可以攤開看。模擬測試替你假設了一位訪客：某個等級的裝置、某種網路速度、從某個地點出發，載入一次，得到一份乾淨但單薄的讀數。欄位資料則把幾十天、成千上萬次造訪的體驗分布攤開，告訴你偏慢的那四分之一落在哪裡。一個像顯微鏡，看得清楚；一個像普查，說得準誰受害。儀器沒有高下，問題是你現在需要哪一種。
測速數字分成兩種來源。Lab Data（實驗室資料）是工具在受控環境裡模擬載入：固定裝置條件、固定地點、單次或數次載入，把過程拆成可檢視的細節，DevTools 裡的 Lighthouse 與 WebPageTest 的核心分數都屬於這一類，強項是找根因。Field Data（欄位資料）把真實使用者的瀏覽經驗彙整成 CrUX 資料集，強項是確認影響。找原因看 Lab，判斷訪客是否真的受害看 Field，兩種數字回答不同的問題，不該拿對方的弱點否定對方的結論。
欄位資料的源頭值得認識。這種資料不是儀器測出來的，是瀏覽器回報出來的：符合資格的 Chrome 使用者造訪頁面時，實際體驗到的效能數字被匿名收集，累積成 Chrome UX Report 這個公開資料集，PageSpeed Insights 與 Search Console 的 Core Web Vitals 報表都以它為來源；彙整視窗是滾動 28 天，判讀基準是第 75 百分位，反映偏慢那一群人的體驗，不是平均值，也不是最差狀況（見 PageSpeed Insights 的官方說明與 Chrome UX Report 的官方文件）。同一份報表裡那個 0 到 100 的分數屬於實驗室評分，定位是診斷參考，不是排名分數；把兩種數字混成一個「快不快」，是速度討論裡最常見的張冠李戴。
PageSpeed Insights 順手的地方，在於它把兩種資料放進同一份報表：上半部的燈號來自欄位資料，回答「訪客是否受害」；下半部的模擬載入與逐項建議，回答「問題出在哪裡」。貼一次網址，兩個問題都有線索，這也是它適合當第一個入口的原因，缺的只是它不會替你決定下一步。
實務的起點是 Search Console 的 Core Web Vitals 報表：它把相似頁面分組呈現，直接告訴你「需要改善」的是哪一群網址，這份名單就是後續所有動作的靶心。分組的意義在於效率：同一組模板長出來的頁面，瓶頸多半相同，修一次模板，整組數字一起動。沒有 Search Console 資料的站，就從流量最大的幾頁自己建立清單，原理相同。
流量小的網站常遇到另一種情況：欄位資料是空的。沒有資料不等於沒有問題，只代表樣本還沒累積到門檻；替代路徑是固定條件的模擬測試，加上自有分析工具的行為資料交叉判讀，兩邊都指向同一頁有問題，信心就夠了。真的需要第一手數字，再考慮自建 RUM（真實使用者監控），但要連同導入與維運成本一起評估。
還有一個實務細節：欄位資料以網址為單位呈現，也看得到整站層級的數字；流量集中的首頁常有資料，深層的舊文頁常常沒有。查的時候先確認自己在看哪一層，用整站的綠燈安慰單頁的紅燈，是常見的自我安慰，使用者造訪的永遠是某一頁，不是整個站。
兩種資料打架時，依用途採信：判斷使用者是否受影響，聽欄位資料；判斷改動有沒有效，聽固定條件的模擬測試。Core Web Vitals 的組成與完整背景，可以再讀核心網頁體驗指標的完整拆解。
三個燈號對應三種抱怨：LCP、INP、CLS 的判讀
欄位資料裡的紅燈只有三個，每個都對應一種使用者的抱怨。先記體感，再記數字，判讀會快很多；判讀以欄位資料的第 75 百分位與分裝置數字為準，不是任何一次測試的結果。
LCP（最大內容繪製）對應的抱怨是「等好久，畫面還是空的」。它衡量頁面主要內容被畫出來的時間，主角通常落在還沒捲動就看得到的最大圖片，或占最大面積的文字內容；良好門檻 2.5 秒，超過 4 秒屬於差（三個指標的門檻都出自 web.dev 的指標文件）。這個燈紅了，先懷疑傳輸：首屏圖片多大、伺服器多快開始回應、有沒有資源擋在前面。手機上特別容易中招，同一張圖在桌機秒開，換到中階手機就是漫長的等待。判斷時先找出主要內容是哪個元素，再問它等在哪裡：等圖片下載、等伺服器開始回應，還是被前面的腳本擋住，三種等待對應三種修法，藥不對症，分數不會動。
INP（互動至下一次繪製）對應「點了沒反應」。它衡量單次造訪中，點擊、觸控與鍵盤輸入到畫面更新為止的延遲；一次造訪通常以最慢的一次互動代表該次，互動很多時會按規則忽略少數極端值，報表再取各次造訪指標的第 75 百分位數，並分行動裝置與桌機判讀，所以那個數字並不是把所有互動排在一起取百分位。良好門檻 200 毫秒，超過 500 毫秒屬於差。INP 在 2024 年取代 FID 成為核心指標，那段轉換的背景，可以搭配 FID 換成 INP 的完整說明。實務上最快的檢查是清點第三方：廣告、統計、聊天、同意管理，四類各留必要的，其他依序停用回測，通常一輪就有答案。
CLS（累積版面位移）對應「按鈕跑掉了」。它衡量頁面整個生命週期中的非預期版面位移，採最高分的位移時段（session window）計分，不只看初次載入；圖片與廣告沒預留空間、字型替換、載入後才插入的留言或推薦區，都會在頁面看得到之後繼續累積分數。良好門檻 0.1，超過 0.25 屬於差。把它限縮成「載入時會不會跳」，會漏掉一半的問題：使用者打開頁面十秒後要點的按鈕被擠走，一樣算。修復的方向也就單純：會晚到的東西，先把位置留給它，尺寸寫死、容器預留高度，比讓它自己撞進版面好。
分行動與桌機判讀，是欄位資料最實用的切法。手機紅、桌機綠是常態，兩者的運算資源與網路條件本來就有差距；只看桌機報告會以為沒事，只看手機又可能高估問題範圍，畢竟有些站的桌機流量仍占相當比例。修復也依此排序：先救人數多的那一側，再回頭處理另一側，而不是兩邊同時開工。
黃燈的處理原則也順道交代：「需要改善」不代表立即危險，代表分布已經偏向警戒區。它的優先級取決於頁面的商業角色：賺錢的頁面黃燈就排進待辦，長尾頁面的黃燈先記錄、下次重測再說。顏色是分類，不是刑期。
三個指標會互相牽制，這是取捨的常態。為了讓 LCP 變快而延後載入圖片，圖片後到把版面擠開，CLS 可能轉紅；為了救 INP 砍掉腳本，功能跟著縮水，交易頁面上未必划算。看得見、點得動、不亂跳，三句話一起顧，不要只盯一個數字衝刺，也不要期待三燈轉綠之後，排名或流量會立刻給你回報，速度指標從來不做這種承諾。取捨出現時，回到頁面的任務：閱讀型頁面先保看得見與不亂跳，操作型頁面先保點得動，沒有全能解，只有對這一頁最划算的組合。
固定條件回測，數字才有資格互相比較
單次數字會騙人，重複得出同樣判斷才可靠。做法是把測試變成一條可重跑的流程：固定同一個網址、同一種裝置、同一個地點與連線條件，跑出指標並記錄下來，照報告定位瓶頸，修改之後用完全相同的條件回測。把工具與指標串成這樣一條紀律，用意是不留盲點、也不把時間浪費在錯的數字上；條件一旦飄移，前後兩份報告就失去互相比較的資格。
要固定的變因，列出來比用記的可靠：
- 開無痕視窗、保持登出，測前先清掉快取，量到的結果才貼近初次來訪者的第一印象；登入狀態會多載管理工具列與腳本，數字跟著失真。
- 測試節點選離主要訪客最近的一個，而且整輪都用同一個；地點一換，往返時間就變，數字跟著漂。
- 連線速度與裝置模擬的設定保持同一組，工具改版時把參數變化記下來。
- 測試條件與每次修改的內容寫進同一份紀錄，之後才歸因得出哪個動作有效。
單次結果自帶雜訊：伺服器負載、網路波動、第三方服務的狀態都會摻一腳。重要的結論多跑幾輪取中間水準，或換個節點交叉印證。
流程裡最容易被跳過的一步是「一次只改一項」。著急的時候什麼都想一起上：壓圖、換外掛、調快取、砍腳本，一週後數字變好，卻沒有人知道是哪個動作的功勞，下一次遇到同樣問題，只能整包重做一遍。把修改當實驗設計：一項變因、一組對照、一份紀錄，看起來慢，實際上每一步都算數，而且累積得出經驗。
紀錄的格式不必講究，欄位固定就好：日期、頁面、裝置與節點、三個指標的數字、一行寫下這次動了什麼。用試算表或筆記都行，重點是六個月後回頭看，你說得出每個數字當時的條件；這份表同時是與同事、廠商溝通時的共同語言，比口頭印象可靠得多。
想在修改過程中反覆驗證，Chrome DevTools 裡的 Lighthouse 最順手：本地執行、不佔雲端額度（見 Chrome Developers 的 Lighthouse 概觀），開發者工具還能看的其他 SEO 線索，可以接著讀F12 開發者工具的實戰用法。
瓶頸只有三類：傳輸、執行、伺服器回應
報告落落長的建議清單，先別照單全收。把每一項建議歸進三類瓶頸之一，再在同類裡挑影響大、成本低的先做；分類錯了，努力就放錯地方，修了半天紅燈不動，因為動到的根本不是根因。三類的邊界偶有重疊，同一個症狀可能跨兩類，先歸主因，再處理次因，順序不對會白做工。
傳輸類的問題是「太多位元組在路上」：未壓縮或未轉現代格式的圖片、遠端字體、過大的 CSS 與 JavaScript。多半反映在 LCP 與整體載入時間，修的方向是減量與提前送達。檢查先看最大宗：一張沒壓過的首圖、一包遠端字體、一段快取規則設得太短的樣式表，通常抓前三大就涵蓋頁面體積的大半。圖片先確認尺寸與格式，再談載入策略；字型的替換時機同時牽動 CLS，跨指標的影響要一起記進紀錄。
執行類的問題是「主執行緒被佔住」：大型 JS 與第三方腳本（廣告、追蹤、聊天、同意管理）排隊執行，多半反映在 INP。第三方腳本是最常見的隱形大戶，單獨看都不大，疊起來就是主執行緒的常客；用載入時機與條件載入把它們錯開，比全部砍掉務實。WordPress 站常在這裡失血，但判斷重點不在外掛數量，在載到前台的體積；用 DevTools 的 Transfer Size 找出貢獻最多 JS 與 CSS 的少數項目，用體積思考取代數量焦慮，系統化的整理方式可以參考WordPress 速度優化的做法。
回應類的問題是「伺服器想太久」：TTFB 偏高，而且要跨地點、多次測試都偏高，才指向主機與資料庫。先排除快取未命中與網路延遲這兩個更常見的干擾，再依工作負載與資源規格比較代管環境，主機類型的選擇分析談的就是這一層。這一層的證據要累積：不同時段、不同地點各測幾次，曲線穩定地高才算數，偶爾抽高多半是流量尖峰或同機鄰居的干擾，先觀察再動作。資料庫的慢查詢與快取命中率，往往比直接升級主機更快看到效果，也便宜得多。任何品牌推薦，都應該建立在你能重現的實測數字上。
左右捲動檢視完整表格
| 報告裡的術語 | 瓶頸分類 | 修復方向 |
|---|---|---|
| Serve images in next-gen formats | 傳輸 | 壓縮、轉 WebP 或 AVIF、設定正確尺寸 |
| Reduce unused JavaScript | 執行 | 拆分程式碼、延後非必要腳本 |
| Reduce the impact of third-party code | 執行 | 調整載入時機、移除沒在用的追蹤碼 |
| Reduce initial server response time | 回應 | 查快取命中、資料庫查詢與主機資源 |
| Avoid large layout shifts | 傳輸（載入時序） | 為圖片與廣告預留空間 |
時序問題交給瀑布圖：哪個請求堵住後面、第三方腳本什麼時候插隊，WebPageTest 的逐步載入紀錄看得最清楚。看得懂時序，報告術語就不再是黑話。
三類之內怎麼挑順序？用兩個軸線想：影響面，這個瓶頸拖慢的是哪個指標、涵蓋多少頁面；成本，工時、風險、會不會動到功能。高影響低成本的先做，通常一輪就有感；低影響高成本的放進觀察名單，不必急著清空。修復的目標從來不是把建議清單打勾，是把紅燈變綠的最短路徑走出來。三類瓶頸的修復手法與完整對策，網站變慢的診斷與解法有系統性的整理，上面的表格先幫你把報告術語翻成自己的語言。
快取與 CDN 救得了什麼、救不了什麼
把快取或 CDN 當萬靈丹容易誤判，一概否定它們同樣容易誤判。瀏覽器快取偏向照顧重複造訪；CDN 的邊緣快取在節點已有副本時，連首次造訪的訪客都能受益，前提是該資源可以被邊緣快取。但兩者都救不了未快取 HTML 背後的慢後端、過大的首屏圖片與阻塞執行的腳本，這些要靠實測定位之後對症處理。
三層快取各有分工：瀏覽器快取服務回訪者，伺服器頁面快取服務未登入的訪客，CDN 邊緣快取縮短跨地理的第一哩。判斷該在哪一層出手，看訪客組成：回訪比例高，瀏覽器快取的投報最好；未登入的新訪客多，伺服器頁面快取先上；跨區流量明顯，邊緣快取才會真的有感。基礎觀念與設定細節，分別讀快取的運作原理與 CDN 的加速原理，這裡只談判斷。
什麼時候該認真考慮 CDN？訊號很具體：訪客的地理分布分散、靜態資源占頁面體積大宗、或實測看到跨區延遲明顯。訪客集中在單一地區、頁面又輕的站，先把圖片與腳本減量，效益可能比多加一層服務更直接；順序對了，投資才會落在瓶頸上，而不是落在帳單上。
邊緣快取的效果也要驗證，不要假設。同樣開了 CDN，資源的快取規則設錯，回源比例照樣高；用回應標頭看命中狀態，才知道這層投資有沒有落地。設定與驗證是同一件事的兩半。
驗證快取有沒有發揮，用首次檢視與重複檢視對照。兩者差距小，未必代表快取沒命中；更常見的解釋是，這一頁最重的成本本來就落在快取照顧不到的地方，例如動態組出的 HTML、每次都得回後端處理的接口；先確認瓶頸在不在可快取的範圍裡，再決定要不要投資這一層。差距大也先別開心，確認重複檢視真的吃到了快取；有些頁面連靜態資源都不在快取範圍，差距大自然有其原因，那正是要修的設定。
WordPress 站的注意力放在三件事：頁面快取要開對、物件快取要接上、靜態資源的過期標頭要設長。頁面快取交給同一套外掛全權處理就好；兩套並存時，快取規則會互相覆蓋，問題反而更難排查；怎麼挑、怎麼設，WordPress 快取外掛的實測比較整理過一輪，照自己的主機環境對號入座就好。設定完用同一組條件實測前後差異，比看外掛行銷頁上的截圖可靠。
修完之後，用兩種節奏驗證
修改上線後，隔天打開報表看到燈還是紅的，就以為白忙一場？這是用錯時間尺度看數字，兩種節奏要分開用。
節奏一，當天驗證：用同一組固定條件重跑模擬測試，與修改前的基準比對，確認指標往預期方向移動。這一步回答「方向對不對」，當天就有答案，不必等任何人。
節奏二，數週觀察：欄位資料是滾動 28 天的彙整，修改的效應會逐步摻進來，沒有人能承諾幾週後轉綠；比對時確認樣本與頁面群組相同，否則比較沒有意義。觀察期裡網站若又在變動，例如上了新活動頁、換了字型，這些事也要記在一起，解讀時才有依據。Search Console 的報表也會把頁面換組：某一頁這期還在「良好」，下期被歸進「需要改善」，換組通常比單一數字的起伏更早透露趨勢。
兩種節奏之外，還有一種事件驗證：大改版、換主機、上新的追蹤碼之前後，各加測一輪。這種節點最容易埋進新的重量，事後追查的難度也最高；養成「動手前先留基準」的習慣，等於幫未來的自己省下整套偵探工作。
通過門檻之後，維持最低成本的節奏：每月用同一組條件重測一輪。網站會慢慢變重：多一張沒壓過的圖、多一支外掛、多一組行銷要的追蹤碼，載入時間就被一點一點吃回去；固定量測是抓得住這種滑坡的唯一方式。重測紀錄不用複雜，頁面、條件、三個數字、一行備註就夠；一年下來，這張表會是你與任何對象討論速度時最硬的底氣，講得出基準，別人才知道你說的慢是真的慢。
判定修改無效時，正確的回頭路是換一個瓶頸分類重新歸因；在原處疊加更多修改，只會疊到沒有人知道哪個動作做了什麼。
收到紅字滿滿的檢測報告，先查五件事
外部報告不是敵人，但也不必照單全收。送報告的人未必有心算，多數時候只是用了預設條件，或挑了對自己有利的呈現方式；你不需要反駁誰，只要把查核當成核對報價單的例行動作。花十分鐘查五件事，通過了再把結論轉成待辦：
- 測了哪些頁面。只測首頁的報告代表性有限，首頁通常是被照顧最好的那一頁；真正的流量頁與轉換頁有沒有被測到，先問清楚。
- 用哪種裝置。行動與桌機的結果分開列了嗎？混在一起或只給桌機，都會低估真實體驗。
- 資料屬於 Lab 還是 Field。模擬測試的紅字是症狀提示；要主張「使用者受害」，得有欄位資料支持。
- 跑了幾次。單次結果自帶雜訊，把一次的數字當定論，信心建立在運氣上。
- 判準是門檻還是分數。用三指標門檻講得出具體問題；只端出一個總分嚇人的，多半還把實驗室評分講成了排名分數。
五項都對得上，報告裡的項目應該能映射回三類瓶頸，直接排進修復時程；對不上的部分，退回去要求補測，這是正常的專業往來。把五件事的回答寫進回覆，對方下一次送來的報告通常會自己變好，討論也會被拉到同一個事實基礎上，之後省力得多。查核不是不信任誰，是讓每一小時與每一筆預算都有依據；多數時候你會發現，報告有一部分可用，另一部分只是包裝得比較嚇人。
查核通過後，把報告項目翻成自己的工單：每項標上瓶頸分類、預估工時與風險，再依影響與成本排序。這一步做完，報告就從「別人的結論」變成「自己的排程」，廠商的建議可以採納，採納的理由與驗收的標準都在你手上。
及格就收手：速度投資的停損點
三個燈轉綠之後，繼續追分數的邊際效益掉得很快。把 85 分推到 95 分的工，拿去補內容缺口或修其他技術面，通常更有商業意義。
過度優化還會反噬（示意）：圖片壓到失真、把帶來詢問的表單或客服功能砍掉換分數，報表漂亮，生意變差。快是條件，不是成果；訪客願意走完的那個動作才是成果，這個判斷在停損的場合比在任何地方都成立。判斷的試金石很簡單：這個修改拿掉的東西，使用者會想念嗎？會，就再想想；不會，那多半是純粹的浪費，刪了剛好。
合理的目標可以參考宏觀資料：HTTP Archive 的公開報表彙整大量網站的頁面體積與資源分布，看得出業界整體落在哪個區間。這類資料不能判定單一網站夠不夠快，但能防止你把目標設成一個沒有必要的滿分；訪客的感受在門檻附近就有明顯差別，不在滿分線上。
另一個停損訊號是修復曲線的形狀：前幾項修改都有感，最近兩項都推不動數字，代表已經碰到這個站的天花板，剩下的改善要用架構級的投資換，例如換主機、重建模板，那已經是另一個決策規模的事，先算再動。
停損的判斷式很樸素：頁面的商業價值，乘上瓶頸修復的成本。門檻內的頁面維持月度重測就好；力氣留給越線最多、又最有生意的那幾頁。同一套邏輯放在頁面之間也成立：流量與營收集中的頁面值得反覆打磨，深處的舊內容頁通過門檻就好；把效能工程的心力花在沒人造訪的頁面上，是最安靜也最常見的浪費。這不是消極，是資源紀律。
下次再有人問「網站是不是慢」，照這個順序走
整條判斷鏈收攏成七步，每步附上要看哪個數字：
- 把症狀寫成可驗證的問題：哪一頁、哪個指標、哪種裝置。
- 看欄位資料：Search Console 的 Core Web Vitals 報表，三項指標是否越線，記下分組與裝置。
- 判讀三個燈號對應的抱怨，確認該救的是看得到、點得動，還是不亂跳。
- 固定條件回測：同網址、同裝置、同節點，重複量測取穩定讀數，建立修改前的基準。
- 報告項目歸進傳輸、執行、回應三類，挑影響大、成本低的一項動手，一次只改一項。
- 當天用同條件驗證方向，數週後看欄位資料的變化。
- 每月用同一組條件重跑一輪，數字異常才深入。
七步走完一輪，通常一個下午夠了；難的從來不是操作，是在每一步忍住不跳步。跳步的代價都長得一樣：修了不見效，或是見效了不知道為什麼。
自查兩輪仍定位不出瓶頸，或確認問題在主機架構與後端，再考慮找外部資源；此時你手上已經有症狀定義、基準數字與修改紀錄，溝通成本低得多，也不容易被一份漂亮的簡報牽著走。挑外部資源時，這十個判斷就是現成的面試題：對方願不願意先看欄位資料、講不講得清楚測試條件、能不能把建議映射回瓶頸分類，答得順的人，通常也交得出你要的東西。想把修復手法補齊，接著讀網站速度優化的完整路線；要把速度放回搜尋技術面的全貌裡看，技術性 SEO 的全貌導讀是下一站。
現在就打開 Search Console 的 Core Web Vitals 報表，從最紅的那一頁開始。不必等全部弄懂，第一個判斷今晚就做得完；多走幾輪，判斷會變成反射，速度就不再是別人拿來嚇你的題目。
