PageSpeed Insights（PSI） 是 Google 官方推出的免費網站測速工具，幫你快速檢查網頁在行動裝置與電腦上的載入效能、Core Web Vitals，以及可能拖慢網站速度的技術問題。

一份完整的 PageSpeed Insights 報告同時包含「 真實使用者過去一段時間的使用體驗 」與「 Lighthouse 當下模擬測試的診斷結果 」，兩種資料回答的是不同問題。

這篇文章會帶你操作 PageSpeed Insights、看懂每個指標的分數意義、判讀檢測報告，最後告訴你報告出現一堆警告時該怎麼優化：）

• PageSpeed Insights 是什麼？
• 怎麼用 PageSpeed Insights 測網速？操作 3 步驟
• PageSpeed Insights 分數怎麼看？90 分才算好嗎？
• PageSpeed Insights 報告怎麼判讀？
• PageSpeed Insights 報告一堆警告，該怎麼優化？
• 常見問題
• 聯絡犬哥網站

---

PageSpeed Insights（PSI）是 Google 用來分析網頁使用體驗與效能問題的官方工具，只要輸入網址，就能同時看到「 實地資料 」與「 實驗室資料 」這兩種完全不同性質的數據。

這兩種資料乍看都在測網站速度，但觀察角度完全不同。

實地資料（Field Data／CrUX）：真實使用者的體驗

實地資料是真實訪客在過去 28 天內，實際瀏覽這個網頁時被動蒐集下來的效能數據，資料來源是 Google 的「 Chrome 使用者體驗報告（CrUX） 」。

因為這些數據來自真人、真裝置、真網路環境，所以最能反映「 使用者實際感受到的速度 」，也是 Google 用來評估 Core Web Vitals（核心網頁指標） 是否通過的依據。

不過實地資料有一個限制。如果網頁流量太少，或剛上線不久，CrUX 資料庫可能還沒累積到足夠樣本，這時候 PageSpeed Insights 就不會顯示這個區塊。

實驗室資料（Lab Data／Lighthouse）：模擬環境的診斷

實驗室資料是 PageSpeed Insights 在測試當下，用 Google 的開源工具 Lighthouse，在標準化的模擬環境中即時跑出來的分析結果。

Lighthouse 會模擬固定的網路速度與裝置效能（例如模擬中階手機、4G 網路），針對同一個網頁重複跑分，並列出詳細的診斷建議跟逐項改善方向。

實驗室資料的優點是每次都能立刻取得結果，不需要等待真實流量累積，缺點則是「 模擬環境 」跟訪客實際使用的網路、裝置條件不一定完全相同，兩者數字有落差是正常現象。

實地資料 vs 實驗室資料

實地資料跟實驗室資料最大的差異，在於「 資料來源 」、「 更新頻率 」與「 波動性 」這三個面向，兩者要搭配著看，才能完整判斷網站的真實狀況。

比較項目	實地資料（Field / CrUX）	實驗室資料（Lab / Lighthouse）
資料來源	真實使用者過去 28 天的瀏覽數據	測試當下模擬環境跑出的即時結果
主要用途	判斷 Core Web Vitals 是否實際通過	診斷問題根源、取得逐項優化建議
更新頻率	每 28 天滾動更新一次	每次測試都重新產生
波動性	相對穩定，反映長期趨勢	容易受當下網路壅塞、伺服器負載影響而波動
該怎麼用	用來確認「使用者實際感受到的效果」是否有改善	用來找出「具體要修哪裡」的可執行清單

簡單來說，「 實地資料 」告訴你使用者實際感受如何；「 實驗室資料 」告訴你該往哪個方向優化，兩者搭配使用才不會只看到片面的結果。

---

怎麼用 PageSpeed Insights 測網速？操作 3 步驟

用 PageSpeed Insights 測網速的核心步驟，只要「 輸入正確網址 」、「 分開查看行動裝置與電腦版 」、「 同頁面重複測試 」這 3 個步驟，就能取得可信度較高的參考數據。

步驟一：輸入正確的頁面網址

PageSpeed Insights 測的是「 單一頁面 」，不是整個網站，因此輸入網址時要確認是你真正想檢測的那個頁面，而不是網站首頁。

舉例來說，如果你想優化的是某篇商品頁或文章頁的載入速度，就要直接貼上該頁面的完整網址，而不是貼首頁網址後假設「 全站速度都差不多 」，因為不同頁面的圖片數量、外掛載入情況都不一樣，分數落差可能很大。

步驟二：分別查看「 行動裝置 」與「 電腦版 」

測試完成後，畫面上方會有「 行動裝置 」與「 電腦版 」兩個分頁，這兩組分數是完全獨立計算的，不能只看其中一邊就下結論。

因為 Google 目前以行動版索引為主，行動裝置的分數通常比電腦版低很多，這是正常現象，不代表網站有問題，主要是因為手機的運算效能與網路條件本來就比電腦嚴苛，Lighthouse 的評分標準也是照這個模擬條件去打分數。

建議兩個分頁都要看過，尤其行動裝置分數更該優先關注，因為多數使用者的實際瀏覽情境就是透過手機。

步驟三：同頁面重複測，看「 反覆出現 」的問題

對同一個頁面重複測試 2 到 3 次，因為實驗室資料本來就會受到當下伺服器負載、網路狀況影響，單次測試的分數有時候會出現明顯落差。

真正該優先處理的，是每次測試都反覆出現的同一項警告或建議，而不是只出現一次、下次測就消失的偶發性問題，這樣才能避免把資源花在不穩定的雜訊上。

如果想更深入了解圖片、程式碼層級的優化細節，可以參考這篇《 網站速度優化的最佳技巧 》。想知道除了 PageSpeed Insights 之外還有哪些測速工具可以交叉比對，也可以參考《 網站測速工具 》這篇文章。

---

PageSpeed Insights 分數怎麼看？90 分才算好嗎？

PageSpeed Insights 的效能分數只是 Lighthouse 用來呈現整體表現的綜合數字，實際上要看的是「 90-100 良好 」、「 50-89 需要改善 」、「 0-49 不佳 」這三個級距落在哪一區。

90 分不是唯一的合格標準，要正確解讀分數，還需要搭配 Core Web Vitals 三大指標，並避開幾個常見的誤解。

Lighthouse 效能分數三個級距

Lighthouse 的效能分數採用 0 到 100 分計算，並用顏色區分成三個級距，這套標準同時適用於行動裝置與電腦版分數。

分數區間	顏色標示	代表意義
90-100	綠色	良好，使用者體驗已達到 Google 建議的標準
50-89	橙色	需要改善，還有明顯可優化的空間
0-49	紅色	不佳，載入或互動體驗可能已經影響使用者留存

要注意的是，要拿到「 100 分 」難度非常高，因為 Lighthouse 評分曲線是採用對數常態分布計算，分數越接近滿分，同樣的分數增幅需要付出的優化成本會越高。

對多數中小企業網站來說，行動裝置分數能穩定落在良好或需要改善區間的中上段，已經是很務實的目標，不需要執著在滿分。

Core Web Vitals 三大指標門檻一次看懂

Core Web Vitals（核心網頁指標） 是 Google 用來評估使用者體驗的三項關鍵指標，分別是 LCP（載入速度）、INP（互動反應速度）、CLS（視覺穩定度），每一項都各自有獨立的「 良好、需要改善、不佳 」門檻。

指標	測量內容	良好	需要改善	不佳
LCP	最大內容繪製完成的時間	2.5 秒以內	2.5 秒～4 秒	超過 4 秒
INP	使用者互動到畫面反應的延遲	200 毫秒以內	200 毫秒～500 毫秒	超過 500 毫秒
CLS	版面在載入過程中的位移程度	0.1 以下	0.1～0.25	超過 0.25

INP（Interaction to Next Paint） 是在 2024 年 3 月正式取代舊指標 FID（First Input Delay）成為 Core Web Vitals 的一員。

跟 FID 只看「 第一次互動 」不同，INP 會追蹤整個瀏覽過程中所有的點擊、輸入、觸控反應，取其中反應較慢的結果，因此更能反映使用者在整個瀏覽過程中的真實互動體驗。

Core Web Vitals「 三項同時達標 」才通過

Google 判定一個頁面的 Core Web Vitals 是否「 通過 」，判定邏輯是 LCP、INP、CLS 這三項指標同時達標，同時有至少 75% 的訪客體驗落在「 良好 」門檻內，才算通過。

只要其中一項沒達標，這個頁面的 Core Web Vitals 就會被判定為未通過。

這也是為什麼有些網站三項指標中有兩項都是綠色，卻依然顯示「 未通過 」的原因，通常是被其中一項指標拖累整體結果。

網站速度優化也會影響 SEO 與 GEO 表現嗎？

網站速度對 SEO 與 GEO 表現會有一定程度的影響，但速度只是門檻，不是全部。網站速度太差，確實可能讓內容再好也難以獲得應有的排名與能見度。

不過真正決定 SEO 與 GEO（生成式引擎優化） 表現的關鍵，其實是「 技術結構 」、「 內容品質 」、「 語意標記 」這三者的整體佈局，網站速度更像是入場券，速度太差會讓爬蟲與 AI 引擎難以順利讀取內容，但速度快本身也不會直接讓排名往上衝。

以犬哥協助的「 家居燈飾品牌 」為例，主要客群為室內設計師與住宅裝潢業主，執行上就沒有只單獨衝網站速度分數，而是先處理網站的技術結構與速度問題，確保爬蟲與 AI 引擎能順利讀取、理解頁面內容，再進一步針對高流量關鍵字強化內容深度與結構化標記。

技術結構先行、內容與標記接續的優化順序，最終讓該品牌燈飾等相關關鍵字成功排上 Google 搜尋首頁，官網訂單量成長 6 倍，品牌在 AI 平台的提及率也同步提升。

這印證了網站速度只是基礎門檻，真正帶動成效的還是技術、內容與結構化標記的整體佈局，正是犬哥網站的 SEO ＆ GEO 行銷服務 項目，如果你也想從技術結構打好地基、同步兼顧 SEO 排名與 AI 能見度，歡迎進一步了解：）

分數不是排名分數：常見的四個誤解

PageSpeed Insights 分數常見的誤解，分別是把分數當成排名依據、只看電腦版分數、質疑分數不穩定，以及以為報告建議必須全部執行。

• 誤解一：Performance 分數就是 Google 排名的依據

Lighthouse 的 Performance 分數本身，並不是 Google 搜尋排名演算法直接使用的數字，Google 用來評估頁面體驗的排名訊號，是根據 Core Web Vitals 的實地資料判定通過與否，Performance 分數只是一個輔助診斷用的參考指標。

• 誤解二：只要電腦版分數高，手機版就不用擔心

如同前面提過的，Google 目前以行動版索引為主，代表手機版的體驗才是評估重點，就算電腦版分數是漂亮的綠色 95 分，手機版如果掉到需要改善區間，這個頁面在搜尋表現上依然可能吃虧。

• 誤解三：每次測試分數不同，代表這個工具不準

實驗室資料本來就會受到測試當下的伺服器負載、網路壅塞程度影響而波動，分數在合理範圍內上下浮動是正常現象，不代表工具本身有問題，這也是為什麼建議同頁面要重複測試，找出反覆出現的問題。

• 誤解四：報告中所有的優化建議都必須全部執行

Lighthouse 列出的建議，有些對整體分數的影響微乎其微，有些甚至可能跟網站既有功能互相牴觸，並不是每一項都值得投入時間去修，應該優先處理必要項目。

---

PageSpeed Insights 報告怎麼判讀？

PageSpeed Insights 的報告主要分成「 實際使用者體驗 」與「 診斷效能問題 」這兩大區塊，前者呈現的是真實訪客的實地資料，後者則是 Lighthouse 模擬測試的診斷結果，兩個判讀邏輯完全不同。

「 實際使用者體驗 」區塊

「 實際使用者體驗 」區塊會用標籤、75 百分位數數值、展開檢視的分布這三種方式，呈現 LCP、INP、CLS 三項指標的真實表現。

• CWV 標籤（通過／未通過）：畫面上方會直接標示這個頁面的 Core Web Vitals 整體是「 通過 」還是「 未通過 」評估，這是最快掌握整體狀況的方式。
• 75 百分位數數值：每一項指標會列出實際的 75 百分位數數值，例如 LCP 顯示 2.8 秒，代表有 75% 的訪客體驗，載入時間都在 2.8 秒以內。
• 展開檢視畫面的分布：點擊展開檢視畫面後，會看到該指標被分成良好、需要改善、不佳三個區間的訪客佔比，能更細緻地看出訪客分布的落差有多大。

為何 Core Web Vitals 統一採第 75 百分位數？

Google 選擇用第 75 百分位數，而不是平均值來評估 Core Web Vitals，是因為這樣才能確保多數使用者都有良好體驗，而不是被少數表現特別好的樣本拉高整體平均、掩蓋真實問題。

如果改用平均值計算，即使有一大群使用者體驗其實很差，只要有部分使用者的網路環境特別好，平均出來的數字看起來還是能維持不錯的水準，這樣就無法真實反映多數人的實際感受。

為什麼沒有出現「 實際使用者體驗 」區塊？

如果 PageSpeed Insights 沒有顯示「 實際使用者體驗 」區塊，代表這個頁面是新網址，或流量太少，還沒有累積到 CrUX 資料庫要求的最低樣本數，這時候系統會顯示「 沒有足夠的即時資料 」之類的提示。

遇到這種情況，仍然可以參考 Lighthouse 的實驗室資料作為優化方向，等網頁累積一段時間的真實流量後，「 實際使用者體驗 」區塊通常就會逐漸出現。

「 診斷效能問題 」區塊

「 診斷效能問題 」區塊是 Lighthouse 在測試當下產生的完整診斷結果，會列出效能、無障礙、最佳做法、SEO 這四大類別的個別分數，並附上逐項修改建議，例如「 移除未使用的 JavaScript 」、「 適當調整圖片大小 」等。

除了這四大傳統類別，Lighthouse 目前也新增了「 代理瀏覽（Agentic Browsing）」這個實驗性類別，跟其他類別最大的不同是，不會給出 0 到 100 的加權分數，而是改用「 通過率 」與「 通過／未通過 」狀態來呈現結果。

「 代理瀏覽 」是評估 AI 代理程式能不能順利讀懂、操作這個網站，屬於收集資料、提供優化方向的階段，還不會直接影響搜尋排名的正式評分依據，但提早關注這塊，能讓網站在 AI 代理程式逐漸普及的趨勢下超前部署。

每一項建議通常會標示這項問題「 預估能節省多少載入時間 」以及對應的技術說明，點開每一項還能看到受影響的具體檔案清單，方便直接對照網站後台去修改。

---

PageSpeed Insights 報告一堆警告，該怎麼優化？

面對 PageSpeed Insights 報告裡一長串的警告，正確的優化順序是「 先分辨問題出在哪一層 」，再鎖定「 影響大、風險低、容易驗證 」的項目優先處理，最後用同樣的方式重新測試驗證成效，而不是看到警告就逐條照單全收。

先分辨問題出在哪一層

PageSpeed Insights 常見的效能瓶頸，通常可以歸類成「 圖片 」、「 JavaScript 與外掛 」、「 主機回應 」三大類，判斷問題出在哪一層，會直接影響後續的優化方向，舉例來說：

• 圖片過大：如果報告中出現「 適當調整圖片大小 」、「 提供新一代格式的圖片 」等建議，且受影響的檔案清單裡有很多張大尺寸圖片，代表問題主要出在圖片沒有壓縮或格式過舊。

可以參考《 WebP、JPG、PNG 格式怎麼選 》這篇文章，了解不同圖片格式的取捨方式。

• JavaScript 與外掛過多：如果報告中大量出現「 減少未使用的 JavaScript 」、「 避免大量網路酬載 」等建議，通常代表網站安裝了過多外掛、佈景主題本身載入了不必要的程式碼，或第三方追蹤碼疊加過多。

• 主機回應（TTFB）過慢：如果連 FCP、LCP 這類最早期的載入指標都偏慢，即使圖片跟程式碼都已經優化過，問題很可能出在主機本身的回應速度太慢，這種情況通常需要從主機規格或快取機制下手，才能真正改善。

需要優先優化的項目

優化 PageSpeed Insights 報告時，應該先處理「 影響大、風險低、容易驗證 」的項目，而不是按照報告列出的順序從上改到下。

• 圖片壓縮、明顯多餘的外掛，建議優先處理

這類調整通常不會動到網站的核心功能邏輯，風險相對低，效果也容易在下次測試時直接反映出來。

• JavaScript 延遲載入、CSS 精簡，則需要謹慎測試

這類調整雖然對分數提升的效果通常比較明顯，但也比較容易不小心影響到網站原本的互動功能或版面呈現，建議先在測試環境確認過沒有問題，再套用到正式網站，避免顧此失彼。

修改後怎麼驗證有沒有變好

驗證優化成效時，要用同一個網址、同一個裝置版本（行動裝置對行動裝置、電腦版對電腦版）重新測試，才能做出有意義的前後比較，換頁面或混用不同裝置版本比較，得到的結果會失去參考價值。

除了看分數有沒有進步，同時也要實際檢查網站的核心功能，例如：表單送出、選單展開、購物車結帳流程是否依然正常運作。

部分速度優化手法（例如：延遲載入 JavaScript）如果設定不當，有可能在提升分數的同時，意外讓某些互動功能失效，這一步驗證絕對不能省略。

---

常見問題

---

聯絡犬哥網站

在網頁設計＋AI SEO 行銷的過程中，或許會遇到一些解決不了問題，可以在下方留言給我，我會盡力協助解答！

接下來，額外分享 2 個實用資源，可有效幫助大家解決問題。

資源一：犬哥網站（專業 WordPress 網頁設計＆ AI SEO 行銷公司）

如果你沒時間自己架站，或是遇到網站沒有流量、Google 網站排名不理想，或是沒有被 AI 提及你的品牌。歡迎洽詢 犬哥網站（WordPress 網頁設計＆ AI SEO 行銷公司），請專家協助你會更容易！

我們有多年網頁設計、AI SEO 行銷經驗，加上上百個實戰案例，絕對能滿足您的需求！

資源二：WordPress 高手架站課＋SEO 排名飆升課（線上課程）

如果想學習更深入的 WordPress 架站技巧，或是想透過 SEO 關鍵字提升網站流量？

可以參考犬哥近期推出的這兩門課程，課程非常的扎實，都是犬哥自己實戰出來的經驗分享，不打高空只教你做出成績！