假設一家補習班的行銷人員，把官網丟進 PageSpeed Insights，行動版跑出 38 分、一整排紅色三角形，隔天就跟老闆提案整個網站重做。38 分看起來很嚴重，但它回答的是「在一支中階手機、慢速 4G 網路下，模擬載入一次會怎樣」。真正的訪客體驗在報表的另一個區塊，小網站的那一塊常常是空的。
我們自己的首頁，行動版也只有 55 分。這篇用 ethorx.com 在 2026 年 10 月 11 日的實測，走一遍報表怎麼讀、三個指標的標準在哪，以及分數低的時候該先修什麼。網站速度是 SEO 基本功裡最容易被分數嚇到的一項，先把數字讀對，再決定要不要動工。
PageSpeed Insights 的兩個區塊：真實使用者和模擬測試
輸入網址按下分析，報表會分成上下兩塊，兩塊的資料來源完全不同：
| 上方「瞭解實際使用者體驗」 | 下方「診斷效能問題」 | |
|---|---|---|
| 資料從哪來 | Chrome 使用者體驗報告（CrUX），真人造訪時回傳的資料 | Lighthouse 在 Google 的機器上模擬載入一次 |
| 期間 | 近 28 天 | 按下分析的那一次 |
| 呈現方式 | 三個 Core Web Vitals 是否通過，看第 75 百分位數 | 0–100 的效能分數與五個指標 |
| 適合回答 | 訪客實際上覺得快不快 | 慢在哪裡、該從哪裡修 |
| 小網站常見狀況 | 樣本不夠時顯示「沒有資料」 | 每次都有結果，但每次略有差異 |
上方的資料不夠時，PageSpeed Insights 會先退回整個網域的資料；整個網域也不夠，就只會顯示「沒有資料」。ethorx.com 的首頁和文章頁都是這樣。這種情況下，Search Console 的 Core Web Vitals 報表多半也是空的，兩邊用的是同一份 CrUX。
ethorx.com 首頁的行動版報告（2026 年 10 月 11 日）。上方沒有真實使用者資料，下方 55 分是單次模擬的結果。
Google 定義 Core Web Vitals 用的是真實使用者的資料，下方的分數是拿來找原因的工具。所以讀報表的順序是：先看上方有沒有資料、有沒有通過；有通過，下方分數再低都不急。沒有資料或沒通過，才往下看是哪個指標出問題。
Core Web Vitals 三個指標，各自在量什麼
Core Web Vitals 目前是三個指標，Search Console 用同一套門檻分成三級：
| 指標 | 量什麼 | 良好 | 需要改善 | 不佳 | 常見原因 |
|---|---|---|---|---|---|
| LCP（最大內容繪製） | 畫面上最大的那塊內容多久出現 | ≤ 2.5 秒 | ≤ 4 秒 | > 4 秒 | 首屏大圖太重、CSS 或字型擋住渲染、主機回應慢 |
| INP（與下一個畫面的互動） | 點按鈕、展開選單之後，畫面多久有反應 | ≤ 200 毫秒 | ≤ 500 毫秒 | > 500 毫秒 | 第三方腳本、聊天視窗、太多 JavaScript |
| CLS（累計版面配置位移） | 畫面在載入時跳動多少 | ≤ 0.1 | ≤ 0.25 | > 0.25 | 圖片沒寫尺寸、廣告或橫幅晚出現把內容往下推 |
門檻看的是第 75 百分位數。白話講，100 次造訪排一排，第 75 慢的那一次要在標準內才算通過，手機和電腦分開算。
CLS 最容易在報名頁出事。訪客正要按「立即報名」，上方一張晚載入的活動橫幅把按鈕往下推了 200 像素，手指點到的是旁邊的電話號碼。這種跳動在電腦上幾乎看不出來，手機上就很明顯。
INP 是 2024 年 3 月 12 日取代 FID 成為正式指標的，網路上還在講 FID 的文章，資訊已經過期。還有一點：下方的模擬測試沒有真人點擊，量不到 INP，報表用 TBT（總封鎖時間）當參考。TBT 低通常 INP 也不差，但真正的 INP 還是要看上方的真實資料。
55 分是怎麼算出來的
效能分數是五個模擬指標加權後的結果，目前的權重是 TBT 30%、LCP 25%、CLS 25%、FCP 10%、Speed Index 10%。這個權重解釋了我們首頁的分數：
| 頁面（2026-10-11 單次測試） | 裝置 | 效能分數 | LCP | TBT | CLS |
|---|---|---|---|---|---|
| 首頁 | 行動 | 55 | 27.1 秒 | 0 毫秒 | 0 |
| 首頁 | 電腦 | 66 | 4.5 秒 | 0 毫秒 | 0 |
| 文章頁（SEO 工具怎麼選） | 行動 | 56 | 11.9 秒 | 0 毫秒 | 0.003 |
| 文章頁（SEO 工具怎麼選） | 電腦 | 88 | 1.6 秒 | 0 毫秒 | 0.001 |
首頁行動版的 55 分，幾乎全部來自 TBT 和 CLS：兩項都是滿分，剛好 30 加 25。FCP 和 LCP 是 0 分，Speed Index 也接近 0 分，LCP 在模擬裡要 27.1 秒才出現。同樣是 50 幾分，可能是整體普通，也可能是主要內容要等很久。所以看分數之前先看五個指標，紅色三角形標在哪一項，問題就在哪一項。
這也是補習班那個 38 分該先做的事。把五個指標抄下來，通常會發現只有一兩項特別差，修那一兩項就好。另外，同一個網址每次測的分數會差幾分，網路路由、廣告、A/B 測試都會造成波動，比較前後成效時，用同一個網址、同一種裝置多測幾次。
拆開來看：我們的頁面慢在哪裡
報表往下捲，「深入分析」會列出每個問題預估能省多少時間或流量。我們照著兩個最大的項目回頭查檔案：
首頁的「提升圖片傳送效能」預估可省下 1,955 KiB。查下去，首屏背景是一張 2048×953 的 PNG，大小 1.38 MB，是我們建立圖片流程之前放上去的。現在文章用的圖都會轉成 AVIF 和 WebP，720 像素寬的版本抓 80 KB、大圖抓 250 KB 左右當預算，這張舊圖剛好沒走過這道流程。
文章頁的問題在別處。「LCP 細目」顯示，文章頁的最大內容是開頭「先說結論」那段文字，不是首圖，主機回應只花 10 毫秒，時間都卡在畫面渲染。擋住渲染的是三份樣式表，傳輸量合計 93 KiB。最大的一份解壓縮後有 260 KB，其中 222 KB 是中文字型的 144 組 @font-face 宣告。中文字型字數多，網頁字型通常會切成很多小檔，光是宣告這些小檔的 CSS 就這麼大。
LCP 是圖片還是文字，修的方向完全不同。如果要我排順序，首頁先把那張 PNG 換成 AVIF／WebP，文章頁再把字型宣告從會擋住畫面的樣式表裡拆出來。主機回應已經夠快，網站本來就放在 Cloudflare 的邊緣網路上，換主機排不上。內容要靠 JavaScript 才顯示的網站，LCP 也會被拖慢，初始 HTML 該先放什麼，在 JavaScript rendering 會影響 AI Search 嗎有整理。
分數低的時候，先修哪幾件
我會照這個順序處理，每做完一項就用同一個網址、同一種裝置重測：
- 先挑頁面：在 Search Console 的成效報表找出有曝光、有點擊的頁面，通常是文章、服務頁和首頁。沒有人從搜尋進來的頁面，分數再低都可以排後面。
- LCP 太慢：先看「LCP 細目」裡最大內容是什麼。是圖片，就壓縮、換成 WebP 或 AVIF、輸出符合版面的尺寸，加上
fetchpriority="high"，而且首屏那張圖不要設延遲載入。是文字，就往會擋住畫面的 CSS、JavaScript 和字型找。 - CLS 偏高：圖片和影片寫上
width、height，廣告、嵌入內容和公告列先留好空間，晚出現的東西盡量放在頁面下方。 - TBT 或 INP 偏高：清點第三方腳本，客服聊天視窗、追蹤碼、輪播套件是常見來源。用不到的移除，非必要的延後載入。
- 最後才看主機：主機回應（TTFB）慢到佔掉 LCP 一大半，才考慮換主機或加 CDN。
回到補習班的 38 分。假設查下來是首頁一組 3 MB 的輪播大圖，加上一個客服聊天外掛，就先處理這兩項，重測時看 LCP 和 TBT 降了多少。分數只是參考，指標進到綠色區間才是目標。
也有不必急著修的情況。登入後才看得到的頁面、沒有搜尋流量的頁面，分數低影響有限。Google 也說明會優先顯示最相關的內容，即使網頁體驗不夠好；反過來，Core Web Vitals 全部良好也不保證排到第一名。速度是基本功，內容回答得好不好仍然擺在前面。
測速工具怎麼搭配
| 工具 | 適合做什麼 | 要注意 |
|---|---|---|
| PageSpeed Insights | 一次看單一網址的真實資料和模擬測試 | 真實資料要有足夠流量才會出現 |
| Search Console 的 Core Web Vitals 報表 | 看整站哪一類網址沒通過，修完後驗證 | 只有真實資料，小網站常常是空的 |
| Chrome 開發人員工具（Lighthouse、效能面板） | 上線前在自己電腦上重現、找出卡住的資源 | 結果受自己的電腦和網路影響 |
| WebPageTest | 指定地點與網路條件，看逐格載入畫面 | 適合深入除錯，設定較多 |
順帶一提，搜尋「網站速度」會出現 fast.com 這類測網路速度的工具。它量的是你家的網路有多快，跟網站本身的速度是兩回事。
整體 SEO 工具該怎麼配，可以看 SEO 工具怎麼選。Core Web Vitals 報表在 Search Console 的哪裡、其他報表怎麼讀，在 Search Console 教學。網站正好要改版或搬家的話，速度和網址可以一起規劃，見 301 轉址與網址對照表。
我們能協助的部分
我們的官網與電商開發在建置時就把手機瀏覽體驗、程式碼與資源的輕量化一起規劃。已經上線的網站，可以先照這篇的順序自己測一輪。例如把首頁和流量最高的三篇文章各測一次手機版，記下五個指標和「深入分析」的前兩項，就知道問題出在圖片、樣式表還是第三方腳本。
常見問題
手機版分數比電腦版低很多，正常嗎？
正常。行動版模擬的是中階手機加慢速 4G，處理器和網路條件都比電腦版的測試差很多。我們的文章頁電腦版 88 分、手機版 56 分，就是同一個頁面在兩種條件下的差距。訪客多半用手機瀏覽的話，手機版的指標比較值得追。
為什麼每次測出來的分數都不一樣？
模擬測試每次都是重新載入一次，網路路由、伺服器負載、頁面上的廣告或 A/B 測試都會讓數字浮動幾分。比較改版前後時，固定網址和裝置、多測幾次，看五個指標的變化，不要只比一次的分數。
PageSpeed Insights 的分數會直接影響排名嗎？
Google 的排名系統會參考 Core Web Vitals，那是真實使用者的資料；下方的模擬分數是給你除錯用的。網頁體驗也只是眾多訊號之一，內容和搜尋意圖對不上，速度再快也補不回來。
報表顯示「沒有資料」怎麼辦？
代表 Chrome 使用者體驗報告裡，這個網址和整個網域的真實造訪數都還不夠。這時先用下方的模擬測試找問題，等流量累積後，上方和 Search Console 的報表才會出現資料。
參考來源
以下依 Google 官方文件整理，指標門檻與效能分數的權重以官方說明當下為準。