PageSpeed Insights 怎麼看分數？讀懂 LCP、INP、CLS 與優化優先序

PageSpeed Insights 是什麼？不只是測速工具

PageSpeed Insights（PSI）是 Google 官方提供的網頁效能分析工具，輸入任一 URL 就能取得行動裝置與電腦版的效能評分，以及具體的優化建議。工具網址：pagespeed.web.dev。多數人把 PSI 當純粹的測速計分板，但它實際做的事比這複雜。它同時整合了兩套完全不同的數據來源，而這正是很多人搞不清楚「為什麼同一個網站今天 72 分、明天 68 分」的根本原因。要決定先修哪一項，你必須先分辨眼前的分數與建議來自哪一套數據，因為兩者指向的修復方向並不相同。

PSI 怎麼收集數據：CrUX 真實數據 vs Lighthouse 實驗數據

PSI 的實際使用者體驗資料來自 Chrome User Experience Report（CrUX），彙整符合資格且達隱私門檻的 Chrome 使用者樣本，不代表所有訪客。它呈現最近 28 天的滾動資料，並以第 75 百分位判定 LCP、INP 與 CLS 的狀態；資料每日以 best-effort 方式更新，通常約落後兩天，不是每 28 天才更新一次。

實驗室資料由 Lighthouse 在模擬行動裝置或桌面條件下產生，適合找出問題與重測；分數仍會受測試地區、服務負載和頁面變動影響。它不能取代 CrUX，也不保證每次結果完全一致。

CrUX 與 Lighthouse 結果不同時，先確認兩者的範圍：CrUX 是最近 28 天的真實使用者分布，Lighthouse 是單次模擬。前者用來判斷使用者體驗，後者用來除錯；不能由其中一個「良好」就推定另一個結果不重要。

頁面樣本不足時，PSI 可能改顯示來源層級 CrUX；若來源也不足，才不會顯示 field data。此時可用 Lighthouse 找明顯瓶頸，並以自有 Real User Monitoring 補足真實體驗資料。

PSI 效能分數怎麼算

目前 Lighthouse 10 的效能分數由五項指標加權：TBT 30%、LCP 25%、CLS 25%、FCP 10%、Speed Index 10%。舊版曾包含 TTI 並給 CLS 15%，文章不應把舊權重當現行規則；權重仍可能隨 Lighthouse 版本更新。

TBT 權重最高只代表它對 Lighthouse 10 lab 分數的影響較大，不代表 JavaScript 必然是根因。低分時應看各 metric score 與 trace，依載入、主執行緒或版面穩定的實際缺口分流；Opportunities 與 Diagnostics 不直接進入分數，只有帶動 metric 改善時才會間接改分。

三大 Core Web Vitals 指標怎麼看

PSI 分數不等於排名。PageSpeed Insights 報告裡同時呈現 CrUX 與 Lighthouse 兩套數據，前者反映真實用戶的 Core Web Vitals 表現，後者是實驗室模擬的稽核結果。拿到報告後，你該先看 CrUX 的 LCP、INP、CLS 是否達標，再決定要修哪一項，而不是被 Lighthouse 的紅色警告牽著走。

LCP（最大內容繪製）：主視覺多快出現

LCP 衡量頁面主要內容可能完成顯示的時間。以第 75 百分位判定，LCP ≤2.5 秒為良好，2.5–4 秒需改善，超過 4 秒為不良；LCP 元素可能是圖片、文字或其他符合資格的元素，必須在 PSI／DevTools 實際確認。

LCP 根因可能位於 TTFB、資源發現延遲、下載時間或元素渲染延遲。只有在 LCP 資源無法及早發現或優先級不足時才評估 preload／fetchpriority；文字 LCP 也不必然只由字體或伺服器造成。修復成本依架構而異。

INP（與下一個顯示的內容互動）：整體互動反應速度

INP 在 2024-03-12 取代 FID 成為 Core Web Vital。FID 只看第一次互動的輸入延遲；INP 觀察頁面生命週期內的點擊、鍵盤與觸控，回報接近最慢的代表性互動延遲。以第 75 百分位判定，≤200ms 為良好、200–500ms 需改善、超過 500ms 為不良。

JavaScript 長任務、頻繁 DOM 更新與呈現延遲都可能拉高 INP，但不能只由框架名稱判定。應在 DevTools 錄製真實互動 trace，再依第 75 百分位缺口、受影響流量與任務重要性排序修復。

CLS（累計版面配置位移）：頁面穩不穩

CLS 測量頁面在載入過程中元素意外移動的程度。你點了一個連結，結果廣告突然插入，你按到了另一個按鈕，這就是 CLS 製造的問題。標準：0.1 以下算良好，0.1 至 0.25 需改善，超過 0.25 屬不良。最常見的 CLS 問題來源：圖片沒有設定 width 和 height 屬性（瀏覽器不預留空間）、字體替換時造成文字跳位、動態插入的廣告或嵌入內容。

圖片尺寸、廣告槽位與字體策略是常見 CLS 檢查點，但 post-load 位移、第三方元件或應用狀態也可能需要跨團隊修復；不能保證只靠前端即可獨立完成。

指標	衡量對象	良好	需改善	不良
LCP	主視覺載入速度	≤2.5 秒	2.5–4 秒	>4 秒
INP	整體互動反應	≤200 毫秒	200–500 毫秒	>500 毫秒
CLS	版面穩定性	≤0.1	0.1–0.25	>0.25

三項指標的修復優先序應同時看第 75 百分位差距、受影響頁面與流量、使用者任務、商業影響和工程成本。沒有官方固定的 CLS → LCP → INP 順序。

不同頁型的關鍵任務不同，應用 RUM、轉換漏斗與錯誤紀錄確認哪種延遲真的影響使用者；不要預先把特定 Core Web Vital 固定分配給某一頁型或商業結果。CrUX 樣本不足時，Lighthouse 只提供 lab 參考，仍可用自有 RUM 補足。

PageSpeed Insights 操作教學：3 分鐘讀懂報告

用 PSI 分析一個頁面只需要幾個步驟，但報告出來之後大部分人盯著數字不知道從哪裡開始。這裡說明的是怎麼有效率地讀報告，而不只是「把網址貼進去」。讀懂報告的關鍵在於，分數只是結果，真正能引導你採取行動的是分數下方的三個區塊，以及每個區塊裡列出的具體稽核項目。把注意力從分數轉移到這些項目上，你才能知道下一件該做的事是什麼。

基本操作

前往 pagespeed.web.dev，貼上 URL 並等待報告完成；耗時依頁面與服務狀況而異。建議同時檢查行動裝置與桌面。Google 採 mobile-first indexing，使用手機版內容進行索引；但 Lighthouse 行動分數本身不是排名分數，仍須和 CrUX 與實際流量裝置占比一起判讀。

操作上有一個常見的誤解，以為把網址貼進去、看到分數就完成了。實際上 PSI 允許你針對同一頁面反覆測試，每次測試的結果會因為網路狀況與設備效能而有些微差異。建議在優化前先測試一次作為基準，完成一項優化後再測試一次，用前後數據對比來確認修改是否有效，而不是只看單次分數就下結論。

報告三區塊：機會、診斷、已通過

Lighthouse audits 可能提供潛在節省時間或位元組，這些是模擬估算，不是對 Core Web Vitals、ROI 或商業效果的保證。排序時還要看它對哪個 metric 有影響、field data 缺口、實作風險與成本。

Diagnostics 提供額外除錯資訊，有些不直接對應可節省時間。Opportunities 與 Diagnostics 都不直接計入 performance score；只有帶動 metric 改善時才會間接影響分數。

實務排序不應固定從某個區塊開始。先確認 metric 與 trace 的瓶頸，再比較預估節省、受影響流量、修復成本和回歸風險；單一未壓縮大圖可能是高優先，也可能不是該頁主要瓶頸。

PSI 分數 90 分，排名就會好？先搞懂這件事

Google 目前說明，核心排名系統會考量與整體頁面體驗一致的多種信號，Core Web Vitals 也在其中；但沒有單一「頁面體驗信號」，報表全綠不保證排名。相關、實用的內容即使頁面體驗較差，仍可能勝出。相關層級可參考 SEO 排名因素解析。

為什麼分數高，排名卻不一定跟著動？

CrUX 是最近 28 天的滾動資料，PSI field data 每日更新；新樣本會逐步取代舊樣本，所以修復效果通常漸進顯現，而不是等到第 28 天一次刷新。

Lighthouse 重測可立即提供 lab 方向；CrUX 仍混合修復前後 28 天的真實使用者樣本。驗收可同時看相同設定的 Lighthouse、PSI field data、自有 RUM 與 Search Console Core Web Vitals 報表，分清 lab 回歸、真實使用者趨勢與 URL 群組狀態。

分數要追求到多少才夠？邊際效益遞減的實務判斷

Google 不建議只為 SEO 追求滿分；Lighthouse 90–100 為綠色區間，但 75 或 85 並不是排名門檻。是否繼續投資，要看 field data、使用者影響、風險與機會成本。

競品分數不能換算成固定排名優勢。把 LCP 從不良改善到良好有使用者價值，但排名仍由相關性、內容與其他信號共同決定；90 到 95 的 lab 分數差異也不能直接推論排名效果。

看懂低分建議後，你能實際做哪些優化

PageSpeed Insights 的建議是診斷線索，不是固定處方。部分圖片與資源設定可由網站管理員處理；涉及 JavaScript 執行、伺服器或架構時，仍需工程能力、staging 與回歸驗證。

圖片未優化：直接影響 LCP 與 CLS

圖片可能是 LCP 或傳輸瓶頸，但必須先在 PSI／DevTools 確認。WebP 或 AVIF 可能比未最佳化的 JPG／PNG 更小，幅度取決於原始編碼與品質設定；先用相同視覺品質比較實際位元組，再選格式。WordPress 外掛可協助批次轉換，但要先在 staging 驗證相容性與回復方案。

除了格式轉換，圖片尺寸屬性也必須補齊。為每張圖片加上明確的 width 與 height 屬性，瀏覽器才能在圖片載入前預留正確空間，避免版面位移造成 CLS 分數惡化。針對非首屏圖片，加上 loading="lazy" 屬性可延後載入，讓初始畫面更快呈現，但首屏圖片不可使用懶載入，否則反而會延遲 LCP 的觸發時間。

這項優化的成立條件在於圖片本身確實佔據較大體積。若你的網站圖片已經經過壓縮，且格式已是 WebP，那麼 LCP 瓶頸可能來自其他資源，此時應轉向檢查伺服器回應時間或渲染路徑，而非繼續在圖片上做文章。

未使用的 JavaScript：影響 TBT 與 INP

Lighthouse 可列出未使用 JavaScript 的估算與相關資源，但移除、延後或拆分前要用 coverage、trace 與功能測試確認；不要只憑估算停用外掛或腳本。

Asset CleanUp 可讓管理員針對頁面卸載資源，但應先開啟 test mode，確認依賴、快取與表單等功能，再逐頁部署；後台勾選不是免測試的安全保證。

但這項優化有其界線：若 PSI 顯示「縮短主要執行緒工作」或「減少 JavaScript 執行時間」，卻沒有明顯的未使用 JS 可移除，代表問題出在程式碼本身的執行效率，而非資源載入策略。這種情況通常需要重構程式碼邏輯，例如拆分大型函式庫或改用更輕量的替代方案，這已超出外掛設定的範疇，需要工程師介入。

阻塞渲染的資源：影響 FCP 的關鍵路徑

阻塞渲染資源可能拖慢 FCP／LCP。先辨識首屏必要的 critical CSS 與必要腳本，再延後非關鍵資源；不是把所有 CSS 一律放進 head，async／defer 也要依依賴順序與功能測試決定。

WordPress 外掛可提供延遲 JavaScript 或移除未使用 CSS 等不同設定，但不是一鍵保證。每項設定都要先在 staging 開啟，檢查首屏、互動和快取，再以相同條件重測 FCP／LCP。

需要注意的是，並非所有 JavaScript 都適合延遲載入。會影響首屏內容呈現的腳本（例如字型載入器或關鍵樣式產生器）若被延遲，反而可能造成畫面閃爍或樣式錯亂。因此，在啟用自動優化後，應實際瀏覽網站確認功能與視覺呈現皆正常，再將設定套用到正式環境。

伺服器回應時間（TTFB）過長：前端優化的天花板

TTFB 是從導覽開始到收到回應第一個位元組的時間，會受重導、連線、後端處理與傳輸影響。PSI field data 將 TTFB ≤800ms 分為良好、800–1800ms 為需改善、超過 1800ms 為不良；TTFB 不是 Core Web Vital，也只是 LCP 的一個組成，不能用 600ms 當通用硬門檻。

改善 TTFB 可能涉及重導、CDN、連線協定、快取、後端查詢與主機容量。先量測各組成再選方案；快取或 CDN 不一定適用所有動態頁，也不能保證立即達標。

TTFB 問題應先用 trace 與伺服器紀錄分解重導、連線、後端處理和傳輸；只有確認主機容量或後端處理是主要瓶頸後，才評估主機、快取或架構調整。

若 trace 顯示長任務或架構問題，通常需要工程介入與回歸測試。技術 SEO 還需獨立檢查 canonical 與 URL 結構；它們影響重複網址整併與可抓取性，但不能概括成「直接決定索引優先度」。可分別參考 Canonical 標籤設定、URL 結構原則與SEO 工具比較清單。

PSI 報告怎麼決定優化優先序

Opportunity 的預估節省時間可作初步篩選，但不是 ROI、Core Web Vitals 影響或官方優先級。AK 的排序會再加入第 75 百分位缺口、受影響流量、商業頁重要性、修復成本與回歸風險。

從 Opportunity 區塊的時間預估建立排序

Opportunity 的潛在節省值是模擬估算，不是官方優先級或商業回報。AK 可把大於 1 秒、0.5–1 秒與低於 0.5 秒當初步分組，但每項仍要綜合受影響流量、metric 缺口、實作成本、功能風險與可回復性後再排序。

要注意的是，Opportunity 區塊的預估是以 Lighthouse 的測試環境為基準，它假設網路速度與裝置效能都符合中階標準。如果你的目標使用者多數使用高階手機或穩定的 Wi-Fi，實際節省時間可能比預估值低；反之，若使用者多為低階裝置或行動網路，實際改善幅度會更明顯。因此，排序時除了看預估數字，也要參考 CrUX 資料中目前第 75 百分位的 LCP、INP 與 CLS 數值，確認哪些指標離目標值最遠，優先處理與該指標直接相關的 Opportunity 項目。

Lighthouse 改善與 CrUX 改善的時間差如何影響驗收

Lighthouse 是當次 lab 測試；CrUX 是每日更新的 28 天滾動 field data。修復後應固定測試條件觀察 lab 回歸，並持續查看 field 趨勢，不設定「一定一至兩週才反映」的通則。

若 Lighthouse 已改善而 CrUX 尚未變，先確認部署覆蓋、快取、流量與 field data 範圍，再等待滾動樣本更新；完整 28 天視窗後仍無改善時，回查其他 metric 組成與真實使用者分群。

把技術項目分類為快贏、結構性修復與工程介入

可把工作分成設定型快贏、結構性修復與工程介入，但分類必須以 trace 與功能依賴為準。即使是圖片、lazy loading 或外掛停用，也需 staging、回歸測試與回復方案；工時依技術棧估算，不承諾數小時完成。

結構性修復可能包含 critical CSS、圖片 delivery、快取或第三方腳本策略，會牽涉功能與效能回歸測試；工期依實際 trace、程式碼與部署流程估算，不使用一至三天的固定承諾。

工程介入可能涵蓋長任務拆分、Web Worker、第三方腳本治理或渲染架構調整。是否投入要看第 75 百分位缺口、受影響頁面與商業任務、實作風險及替代方案；不預設一定需要數週，也不以影響多個指標作唯一門檻。

分類後仍需逐項確認根因，不固定先做所有快贏。每次部署都保留基準、變更與回復方案，用相同條件重測 Lighthouse，並以 CrUX／RUM 追蹤真實使用者趨勢。

PSI + Google Search Console 整合診斷：AK PSI 診斷三步驟

PSI 只能逐頁測試，但一個網站可能有幾十甚至幾千個頁面。只用 PSI 掃幾個頁面，很難知道是不是整站都有問題。要判斷優化優先序，你需要的不是更多單頁數據，而是把 PSI 的單頁深度與 Google Search Console 的整站覆蓋率結合起來，先確認問題是局部還是全面，再決定投入資源的方向。

以下是 AK 的三步驟內部起點，不是 Google 官方流程：

1. 盤點：先用 Search Console Core Web Vitals 報表找出不良 URL 群組與高流量模板。
2. 診斷：對代表 URL 跑 PSI／Lighthouse，搭配 trace 與 field data 找根因。
3. 驗收：部署後立刻看 lab 回歸，並用 PSI、CrUX／RUM 與 Search Console 持續查看 28 天滾動趨勢。

這個流程先用 Search Console 盤點受影響 URL 群組，再用 PSI／Lighthouse 對代表頁面做單頁診斷。兩者範圍不同；少數測試頁不能證明整站沒有問題。

三步驟之間的判斷順序，決定你修哪裡

先看 Search Console URL 群組能估計問題範圍，再用代表 URL 的 trace 驗證根因。群聚在同一模板可優先懷疑共用元件，但仍需測試，不能由群組分布直接判定成因。

不良 URL 分散時，可優先檢查個別頁面的媒體、第三方腳本與內容差異；這只是調查起點，是否需要動全站架構仍以可重現 trace 與共用依賴為準。

驗收至少保留 lab 結果、field data／RUM 與部署前後對照；若要連到商業結果，再加入 GA4 流量與轉換數據，但不把跳出率或互動異常直接判定為速度造成。若問題涉及共用模板、伺服器或前端架構，可至 AK SEO 服務頁核對技術盤點與執行方式。

常見問題

PageSpeed Insights 分數多少算好？

Lighthouse 90–100 為綠色、50–89 需改善、0–49 不良；這是 lab 分數區間，不是 Google 排名門檻。是否投入要看 field data、使用者影響與工程成本，沒有通用的 75 或 85 分邊際效益線。

行動裝置和電腦的分數為什麼差很多？

Lighthouse 行動與桌面測試使用不同模擬條件，因此分數可能不同。Google 以行動版內容進行索引，但這不代表 Lighthouse 行動分數就是排名分數；應同時看真實裝置組成、CrUX 與可重現的 trace。

PSI 分數和 Google 搜尋排名直接相關嗎？

Google 的核心排名系統會考量 Core Web Vitals 等頁面體驗信號，但沒有單一頁面體驗信號，報表全綠也不保證排名。相關、實用的內容仍可能在頁面體驗較差時排名更好。

優化後分數為什麼沒有立刻提升？

PSI 包含 Lighthouse lab data 與 CrUX field data。Lighthouse 可立即重測；CrUX 是每日更新、約落後兩天的 28 天滾動資料，因此改善會隨新樣本逐步反映，而不是每月一次更新。

INP 是什麼，和 FID 有什麼不同？

FID 只看第一次互動的輸入延遲；INP 觀察頁面生命週期內的點擊、鍵盤與觸控，回報接近最慢的代表性互動。INP 在 2024-03-12 取代 FID，良好門檻為第 75 百分位 ≤200ms。

沒有工程師也能提升 PSI 分數嗎？

部分圖片、尺寸與資源設定可由管理員處理，但必須先在 staging 測試。JavaScript 執行、伺服器或架構問題通常需要工程介入；排序應綜合 field data、trace、流量、成本與回歸風險，而不是只看預估節省時間。

PageSpeed Insights 和 GTmetrix 有什麼差別？

PSI 結合 Lighthouse lab data 與 CrUX field data，適合 Google 工具鏈中的診斷；它不是「直接反映排名標準」。GTmetrix 也使用 Lighthouse，並提供瀑布圖與不同測試位置等功能，選擇取決於除錯需求。

網站圖片很多，LCP 一直不達標，最有效的做法是什麼？

先在 PSI／DevTools 確認真正的 LCP 元素，再縮小其傳輸位元組、提供正確尺寸與 srcset，並避免對 LCP 圖片使用 lazy loading。只有資源無法從初始 HTML 及早發現時，才評估 preload 或 fetchpriority；是否同網域不是通用判準。