把同一個網站，在同一個下午測兩次速度，分數卻可能相差 20 分以上，網站本身什麼都沒有動過。多數人拿到這種測速報告，眼睛只黏著最上面那個總分，看到紅字就慌，看到綠字就放心，報告下面那一大串圖表跟建議清單，往往直接略過不看。
免費的測速工具，例如 Google 的 PageSpeed Insights，跑一次就能生成一份完整報告，裡面其實藏著分數為什麼會浮動的答案、三個核心指標各自在測什麼、時間軸攤開後的瀑布圖在畫什麼，以及建議清單又該從哪一條先修起。看懂這幾個區塊，才知道報告在說你的網站哪裡出了問題，而不是每次都只對著一個數字乾著急。
這篇要做的，就是示範怎麼操作免費測速工具跑出一份報告，再把報告從上到下拆開來看，對應報告裡寫的每一種問題，大概該往 WordPress 後台哪個方向去調整。如果你已經照著站上其他篇做過快取、圖片、主機這幾項工夫，這篇就是幫你看懂做完之後那份報告在講什麼的最後一關。先從分數為什麼忽高忽低講起。
為什麼同一個網站，測速分數會忽高忽低？
測速報告其實同時放了兩種完全不同性質的資料，這正是分數忽高忽低的真正原因。第一種是「現場資料」，來自 Chrome 使用者體驗報告（CrUX），彙整過去 28 天內真實訪客造訪這個網站時實際感受到的載入體驗，每天更新一次。第二種是「實驗室資料」，是測速工具當下模擬跑一次頁面載入所做的診斷，會因為廣告版本的 A/B 測試、網路流量的路由變化、測試裝置的運算效能落差、瀏覽器擴充功能插入的程式碼，甚至電腦上跑的防毒軟體，而每次跑出不同的數字。
同一個網址兩次測出不同分數，多半就是實驗室資料在浮動，不代表網站真的變差了。網路壅塞、電腦當下在跑其他程式、瀏覽器擴充功能插入了幾行 JavaScript，都足以讓同一頁的分數上下跳個幾分。真要看穩定的長期趨勢，現場資料才是那個比較不容易被單次測試干擾的指標。
順帶一提，規模較小或才剛上線沒多久的網站，測速工具很可能連「現場資料」這個區塊都顯示不出來。不是工具故障，是造訪的使用者數量還不夠多，無法累積出有意義的樣本，這在小型網站身上是正常現象，不必因此覺得網站有問題。
別急著衝到 100 分：分數是怎麼算出來的
效能總分不是把幾項指標的分數直接加起來平均，而是「加權平均」。影響體驗越關鍵的指標，權重設得越高，對總分的拉動也越大。而每一項指標本身，又是先透過對數常態曲線換算成 0 到 100 分，越接近滿分，要再往上擠進同樣的幾分，背後需要的實際改善幅度就越大。Google 官方給的例子很直白，從 99 分要進步到 100 分，所需要的載入速度改善量，其實跟從 90 分進步到 94 分差不多，分數越高，邊際效益越低。
這也是為什麼追著「所有指標一次全部衝到 100 分」不切實際，也不是報告真正要你在乎的重點。分數依區間分成三種顏色：0 到 49 分是紅色，代表不佳；50 到 89 分是橘色，代表需要改善；90 到 100 分才是綠色，代表良好。真正該盯的是下一節會講到的三項核心指標，能不能都落在良好區間，而不是逼近滿分那個位數。
另一個容易誤會的地方，是報告下方那一長串「改善建議」。每一條建議本身不能直接拿去改分數，它只是告訴你可能的問題出在哪裡；要真的落實建議，讓對應的指標數值變好，分數才會跟著往上提升。這也解釋了為什麼有時候剛照著建議調整完設定，分數卻沒有馬上跳到預期的數字，因為它要等下一次真的測出更好的載入表現，才會反映出來。
LCP、INP、CLS：三個核心指標各自在看什麼
Google 把使用者體驗拆成幾個看得到、量得出來的名字，合稱 Core Web Vitals（核心網頁指標），其中三項是最重要的核心指標。
LCP（Largest Contentful Paint，最大內容繪製）測的是網頁主要內容出現要等多久，白話一點，就是使用者盯著螢幕，等畫面主體（通常是最大的一張圖片或一段文字區塊）跳出來的那段等待時間。INP（Interaction to Next Paint，互動到下一次繪製）測的是點下去、滑一下之後，畫面回應快不快，反映的是操作當下有沒有明顯延遲。CLS（Cumulative Layout Shift，累計版面配置位移）測的則是頁面會不會一直跳動、讓人點錯東西，常見於圖片或廣告載入完才把版面擠開的情境。
除了這三項，報告裡還會列出 TTFB（Time to First Byte，首位元組時間），這是一項實驗性指標，測的是伺服器開始回應要花多久，間接反映主機與資料庫的效能。連同輔助指標 FCP，幾項門檻整理如下：
| 指標 | 良好 | 需要改善 | 不佳 |
|---|---|---|---|
| FCP（首次內容繪製） | 0–1800 毫秒 | 1800–3000 毫秒 | 超過 3000 毫秒 |
| LCP（最大內容繪製） | 0–2500 毫秒 | 2500–4000 毫秒 | 超過 4000 毫秒 |
| INP（互動到下一次繪製） | 0–200 毫秒 | 200–500 毫秒 | 超過 500 毫秒 |
| CLS（累計版面配置位移） | 0–0.1 | 0.1–0.25 | 超過 0.25 |
| TTFB（首位元組時間，實驗性） | 0–800 毫秒 | 800–1800 毫秒 | 超過 1800 毫秒 |
這幾項指標，Google 評分時用的是 75 百分位數，而不是所有訪客的平均值。原因不難理解，平均值容易被少數速度飛快的訪客拉高，掩蓋掉那些網路慢、手機舊的使用者真實碰到的狀況。用 75 百分位數，等於確保連條件最差的那群使用者，體驗也還在及格線之上，而不是只顧著多數人的感受。
時間軸攤開來看，瀑布圖在畫什麼？
要看到每個檔案什麼時候開始載入、花了多久，PageSpeed Insights 本身其實沒有完整的請求瀑布圖，只給了幾項分類建議跟一條縮圖時間軸。要看到完整的瀑布圖，得換一個同樣免費的工具，例如 GTmetrix。
瀑布圖的邏輯，其實就是把整個載入過程按時間軸由左到右攤開。每一列代表一個請求，HTML、CSS、JavaScript、圖片、字型檔各佔一列；橫軸是時間，長條越長，代表這個請求花的時間越久。長條本身還會依顏色拆成好幾段，對應到請求走過的每個環節：先是排隊等待（棕色）、接著查詢網域名稱（青色）、建立連線（綠色）、送出請求（紅色）、等待伺服器回應（紫色），最後才是下載回應內容（灰色）。看懂這幾段顏色，就能判斷同一個請求的時間，是花在連線慢、伺服器回應慢，還是下載慢。
有一個地方特別容易誤讀。瀑布圖是依照整個頁面的總載入時間等比例縮放出來的，同樣長度的一條長條，放在一個總共跑 20 秒的頁面，跟放在一個總共只跑 0.3 秒的頁面，代表的意義完全不一樣。所以看瀑布圖不能只看長條的視覺長短，一定要對照旁邊標出來的實際完成時間數字，才不會把小事看成大事，或把大事看成小事。
長條和空隙，哪些該多看兩眼
看瀑布圖不用逐條檢查，有幾個訊號值得優先抓出來看。長條只要超過 500 毫秒，原則上就值得追查（影片檔案例外，本來就會比較久）。長條偏長的時候，先看它是哪個顏色偏長：灰色（下載）偏長，通常是檔案本身太大，最常見的就是沒壓縮的圖片；紫色（等待）偏長，多半是伺服器端反應慢，跟主機或資料庫的效能有關；棕色（排隊）偏長，則常是 JavaScript 或 CSS 卡住了瀏覽器的執行緒，或是同時能開的連線數已經被塞滿。
還有兩種異狀，看到就該處理。第一種是紅色的 4xx、5xx 請求，代表這個檔案根本載入失敗，應該直接找出來修正或移除，不該讓瀏覽器一直嘗試載入一個載不到的東西。第二種是請求跟請求之間的空白，這代表瀏覽器正在執行某段程式，卡住了後面資源的載入；空白出現得越早，也就是畫面內容都還沒顯示多少的時候就卡住，對整體體驗的影響越大，如果空白出現在瀑布圖的尾端，通常影響有限，不必太緊張。
另外值得留意的是轉址鏈，例如一個網址先從 http 轉到 https，又從沒有 www 轉到有 www，一路轉個兩三層，每一層都要多花一輪來回時間才能到下一步。與其讓瀏覽器自己一層一層轉，不如把連結或設定直接指向最終那個網址，省掉這幾輪不必要的來回。
建議清單一長串，先修哪一項？
報告最下面那一長串改善建議，不是要你從第一條照順序做到最後一條。
先分清楚兩種東西：一種會直接影響分數，是報告真正要你優先處理的建議；另一種只是背景資訊，幫助理解問題出在哪裡，但本身不會直接牽動分數，屬於診斷資訊。分不清這兩種，常常會把力氣花在不會反映在分數上的細節。
排序上有三個原則可以照著走：第一、先看行動版（手機）的報告，再看桌面版。手機流量通常是多數網站的流量主力，Google 判斷排名時參考的也是行動版的表現，而且行動版做好了，桌面版往往會跟著一起變好。第二、先處理現場資料反映出來的真實使用者問題，再回頭處理實驗室資料裡比較細節的診斷項目。第三、先做全站性的調整，例如快取策略、壓縮設定，再處理只出現在單一頁面的個別問題，全站性的調整一次設定好，全站都受益，效益比修一個個頁面高得多。
報告寫的問題，對應 WordPress 後台哪裡改
報告下方最讓人頭痛的，通常是那一整排看起來很像工程術語的建議項目。這一節把最常出現的幾類建議，翻成白話說明這句話在講什麼問題，再指出 WordPress 後台大概該往哪個方向找設定。這裡不指名特定廠牌的外掛，也不是逐步操作教學，單純先讓你看懂報告在說什麼，知道問題該往哪個方向去找解法。
圖片相關建議
報告裡常見「改善圖片傳輸」、「使用新一代格式」、「延遲載入畫面外的圖片」這幾句，本質上都在講同一件事，圖片檔案太大、格式太舊，或是不該優先載入的圖片卻搶在前面載入。改善圖片傳輸通常有三個方向：換成檔案更小的新一代格式、依照畫面實際顯示的容器尺寸提供對應大小的圖片、選擇適當的壓縮品質，不要為了畫質犧牲太多檔案大小。
對應到 WordPress 後台，這類設定多半藏在媒體庫，或圖片最佳化相關的設定頁面裡，可以調整壓縮品質、輸出格式，以及是否延遲載入。但要注意一個常被忽略的例外，首屏（不用捲動就看得到）的主圖，反而不該被延遲載入，因為它是使用者一打開頁面就會看到的內容，延遲載入只會讓 LCP 這項指標的等待時間變得更長。
轉譯阻塞的 CSS／JS
有些 CSS 或 JavaScript 檔案，瀏覽器一定要等它們下載完，才願意開始畫出畫面。報告把這種狀況寫成「消弭轉譯阻擋資源」，講的正是這些檔案拖慢了畫面出現的速度。
落到 WordPress 後台，通常要去效能或最佳化類的外掛裡，找「延遲載入 JavaScript」、「移除未使用的 CSS」這類選項，把不是首屏必要的樣式或腳本延後執行。瀑布圖上如果看到早期出現的長空白，多半就是這類卡住執行緒的腳本造成的，把它們延後執行，那段空白通常就會跟著縮短。
快取與伺服器回應時間
同樣是等待，「使用有效的快取政策」跟「縮短伺服器初始回應時間」講的其實是兩種不同的等待。前者代表瀏覽器沒有被告知這個檔案可以先存起來，下次不用重新下載；後者代表拿到網頁的 HTML 本身就等了很久，跟主機效能、資料庫查詢效率比較有關。
在 WordPress 後台，快取設定多半要去快取相關外掛，或是主機層級的快取設定裡調整存留時間；伺服器回應太慢，則要往主機規格夠不夠、資料庫有沒有最佳化、外掛是不是裝太多拖慢查詢速度這幾個方向去找答案，不是靠前端的設定就能解決的問題。
CLS：版面忽然位移的問題
使用者明明還在看內容，畫面卻突然被推開，這就是報告裡「版面配置位移的元素」在講的狀況，最常見於圖片、廣告、嵌入影片這些東西，載入完成後才補上原本沒有預留的空間，結果使用者正準備點的地方，下一秒就被擠到別的位置去，容易點錯。
換成 WordPress 後台的動作，就是檢查佈景主題或頁面編輯器裡，圖片跟影片區塊有沒有設定明確的寬高比或尺寸；廣告與嵌入內容的區塊，也要先預留好版位空間，不要等內容真的載入了才把版面撐開。
第三方程式碼
分析工具、社群嵌入、線上客服、行銷追蹤，這類別人家寫的程式，正在搶佔頻寬、佔用瀏覽器的執行緒，報告把這件事寫成「減少第三方程式碼影響」。
WordPress 後台這端，這類程式碼通常是透過外掛，或是頁首、頁尾的程式碼管理功能加進去的。可以先盤點一輪，哪些第三方工具其實已經沒在用了，先移除；留下來的，盡量設定成延後載入，不要讓它們卡在首屏內容顯示之前就搶著執行。
回到一開始的謎，同一個網站兩次測出不同分數，不代表網站真的變差，只是實驗室資料本來就會因為當下條件而跳動。真正該在意的，從來不是把每一項指標都盯到滿分，而是看懂報告在講什麼，再照優先順序，把它對應到 WordPress 後台該調整的設定一項項處理掉。
比起把測速報告當成一次性的考試分數，更值得的做法是把它當成定期健檢，每次網站大更新之後，或是固定隔一段時間，重新測一次，拉長時間看現場資料裡真實使用者的體驗有沒有往好的方向走。這才是真正該在意的終點，不是某一次測出來的那個數字。
這篇也把整個效能系列做個收束，前面幾篇談的是怎麼動手做，快取怎麼設、圖片怎麼處理、主機怎麼選；這篇談的是做完之後，怎麼看懂那份報告在說什麼。