Google 在 2018 年做了一件很重要的事 — 把 PageSpeed Insights 跟 Lighthouse 引擎綁在一起，推出了 PSI V5。這不是單純改改介面那種小更新，而是整個測速邏輯都換了。現在 PSI 能同時給你實驗室資料和真實使用者資料，而且直接跟 Core Web Vitals 綁在一起。你可能不知道，頁面載入時間從 1 秒拉長到 3 秒，跳出率就會多 32%。如果你的網站還沒用新版 PSI 做過健檢，這篇會帶你從頭搞懂。
PageSpeed Insights V5 整合 Lighthouse 之後，一個工具就能同時跑 Lab Data 和 Field Data。對台灣站長來說，這是做速度最佳化最方便的免費工具，沒有之一。Google 自己的研究也說了：載入時間每多 1 秒，轉換率掉 7% 左右。
文章目錄
PageSpeed Insights 是什麼？為什麼你一定要用它
PageSpeed Insights，大家通常叫它 PSI，是 Google 免費提供的網站速度檢測工具。操作很簡單 — 輸入網址，等幾秒鐘，你就會拿到一份完整的速度報告。它跟 SEO 的關係非常直接。Google 從 2010 年就把網站速度當作排名因素，2021 年又把 Core Web Vitals 加進頁面體驗訊號裡。所以如果你在規劃 SEO 策略，速度這塊真的不能跳過。
很多站長會想：「我的網站開起來很快啊。」但你的感覺不等於使用者的體驗。你在台北用光纖，很快。但花蓮用 4G 訊號的人呢？PSI 的厲害之處就在這裡 — 它會模擬各種網路環境和裝置條件，告訴你真實使用者可能碰到什麼狀況。這對 行動裝置 SEO 超級重要，因為台灣超過六成搜尋流量來自手機。
PSI 到底解決了什麼問題？
你可能會問：市面上速度工具那麼多，幹嘛一定要用 PSI？三個理由。第一，它同時跑 Lighthouse 實驗室測試和 Google Search Console 的真實使用者資料，別的工具做不到這個組合。第二，它直接告訴你哪些問題最該先處理，不用自己瞎猜。第三，PSI 的資料跟 Google 排名演算法用的是同一套。改善 PSI 分數，就等於在改善 Technical SEO 的基本盤。
誰應該定期用 PSI 測速？
簡單講：有網站的人都需要。但如果你是 WordPress 站長、經營電商、或負責公司的 On-Page SEO，PSI 是你每個月都要跑一次的基本功。特別是每次改版、換主題、裝新外掛之後。為什麼？因為這些操作都可能讓分數掉個 20 到 30 分，而且你根本不會注意到。搭配 關鍵字研究和 內容 SEO 一起做，效果最好。
PSI 跟 Lighthouse 到底什麼關係？V5 改版改了什麼
2018 年 11 月，Google 發布了 PageSpeed Insights V5。這是 PSI 歷史上最大的一次改版。改版之前，PSI 和 Lighthouse 是兩個獨立的工具，各有各的評分標準。站長最頭痛的就是：PSI 跑出 90 分，換 Lighthouse 跑只剩 60 分。到底該信誰？那時候 演算法更新已經夠煩了，工具還各說各話，真的很崩潰。
改版前：兩套工具，兩套標準，站長很頭大
舊版 PSI 用的是 Google 自己的 PageSpeed 分析引擎，評分邏輯跟 Lighthouse 完全不一樣。Lighthouse 是 Chrome 的開源自動化審查工具，涵蓋 SEO、效能、無障礙等一堆面向。兩邊建議打架是家常便飯 — PSI 說圖片要壓，Lighthouse 說 JavaScript 太肥，站長根本不知道先改哪個。這也是為什麼打好 SEO 基礎知識的底子很重要，至少你能判斷哪些建議的優先順序比較高。
V5 的核心改變：一個引擎統一所有
V5 直接把 Lighthouse 引擎嵌進 PSI。你現在在 PSI 看到的效能分數和最佳化建議，背後都是 Lighthouse 在跑。也就是說，你在 Chrome DevTools 裡跑 Lighthouse，和在 PSI 網頁上跑，結果會一致得多。舊的 PSI API 在改版後半年內就被淘汰了，有在用 API 的開發者需要遷移。
說個我自己的經驗。曾經幫客戶的網站在改版前一週用舊 PSI 測，手機版 92 分。改版後 V5 上線，同一個網站只剩 58 分。客戶嚇了一跳。但其實不是網站變慢了，是評分標準變嚴了。這種「分數重新校正」的狀況，2018 年就在做 SEO 最佳化的人應該都遇過。所以如果你看到分數突然掉很多，先別慌，搞清楚是標準變了還是真的變慢了。
PSI 報告怎麼看：Lab Data 跟 Field Data 全拆解
打開 PSI，輸入網址，等它跑完。你會看到兩大區塊：「欄位資料」和「實驗室資料」。很多人只瞄一眼最上面的 0-100 分數就關掉了。但兩邊的資料都很有用，缺了哪邊都不完整。
Field Data — 來自真實使用者的資料
Field Data 的來源是 Chrome 使用者體驗報告，簡稱 CrUX。這不是模擬的，是過去 28 天內真實使用者訪問你網站時收集到的資料。打個比方，Lab Data 像是健康檢查的抽血報告（標準化測試），Field Data 則像你實際日常生活的體能表現。如果你的網站流量不夠高，這個區塊可能會顯示「沒有足夠資料」，因為資料量太少做不了統計。Field Data 顯示的是你的 Core Web Vitals 在真實世界的表現，包括 LCP、INP、CLS 的 75 百分位數值。白話來說，就是「每 100 個使用者裡，有 75 個人的體驗至少是這個水準」。
Lab Data — 標準環境下的模擬測試
Lab Data 是 Lighthouse 在受控環境下模擬出來的。它用的是一台模擬的中階手機（Moto G Power），在 4G 網路條件下載入你的頁面。所以如果你用自己的 iPhone 15 Pro 測覺得「超快」，但 PSI 給了低分。不是 PSI 壞了，是它在模擬一般使用者的體驗，不是你的體驗。這些資料可以搭配 Google Analytics 的網頁速度報告一起看，更能了解 自然流量使用者的實際狀況。
為什麼兩種資料一定要交叉看？
只看 Lab Data，你知道「在標準條件下網站表現如何」，但不知道真實使用者碰到什麼。只看 Field Data，你知道真實使用者的問題，但不知道原因在哪。兩邊交叉比對才能抓到真正的瓶頸。舉個例子：Field Data 顯示 LCP 很差，但 Lab Data 的 LCP 其實不錯。那問題可能出在特定地區的 CDN 節點或第三方腳本。這時候就要搭配 Screaming Frog 或 Ahrefs 等爬蟲工具，進一步分析資源載入狀況。
六大核心指標白話解釋：LCP、FID、CLS、INP、TTFB、FCP
PSI 報告裡會跑出一堆英文縮寫，第一次看到真的很頭暈。沒關係，下面一個一個用白話文講清楚。每個指標我會告訴你：它量什麼、標準多少、怎麼改善。
LCP — 最大內容繪製（頁面的主角多久才出場）
LCP 衡量的是頁面主要內容載入完成要多久。你可以把它想成：使用者打開你的網頁，那個最大塊的內容（首圖、大標題區塊、或影片第一幀）什麼時候才完整出現。Google 的標準是 2.5 秒以內算「良好」，超過 4 秒就是「差」。改善 LCP 最直接的做法：壓縮首圖、用 CDN、開啟伺服器端快取。如果你的 WordPress 主機回應速度本身就很慢，LCP 很難好得起來。這就像地基沒打好，上面的裝潢再漂亮也沒用。
INP — 互動到下次繪製（按了按鈕，多久才有反應）
INP 是 2024 年 3 月正式取代 FID 的新指標。它量的是：你點了頁面上的按鈕或連結，畫面多久才做出回應。跟 FID 不同的是，INP 不只看第一次互動，而是看整個過程中所有互動的表現。標準是 200 毫秒以內算良好，超過 500 毫秒算差。200 毫秒有多短？眨一下眼睛大約 300-400 毫秒。也就是說，如果 INP 超過 500 毫秒，使用者的感覺就是「卡卡的」。INP 太高通常是頁面上的 JavaScript 太肥或太多，需要減少主執行緒的阻塞。這跟 圖片 SEO 不一樣，INP 的問題幾乎都在程式碼層面。
CLS — 累積佈局偏移（頁面會不會突然亂跳）
你有過這種經驗嗎？點開一篇文章，手指正要按某個按鈕，結果畫面突然跳動，你按到了廣告。這就是 CLS 在搞鬼。CLS 衡量的是頁面載入過程中，元素非預期移動的程度。標準是 0.1 以內算良好。改善方式：給圖片和影片設定明確的寬高屬性，別在視窗上方塞動態內容，用 CSS transform 做動畫而不是改元素實際位置。這也是 在地 SEO 經營者常忽略的問題，特別是嵌了 Google 我的商家地圖元件的頁面，地圖元件載入前後的高度常常不一樣，就會造成 CLS。
TTFB — 首字節時間（伺服器反應有多快）
TTFB 量的東西很直覺：瀏覽器發出請求，到收到伺服器傳回第一個位元組，中間花了多少時間。它反映的就是伺服器的回應速度。標準是 800 毫秒以內。TTFB 太高的話，先檢查這幾件事：主機效能夠不夠、資料庫查詢有沒有最佳化、有沒有裝頁面快取、CDN 節點離使用者夠不夠近。台灣很多網站用的是美國主機，TTFB 隨便就 500ms 起跳。換到 台灣或亞太區主機通常能立刻改善。這就像你叫外送，廚房出餐速度慢，不管外送員騎多快都沒用。
FCP — 首次內容繪製（畫面第一次出現東西的時間）
FCP 量的是瀏覽器第一次繪製出任何內容的時間。文字也行、圖片也行，只要畫面上出現東西了，那一刻就是 FCP。標準是 1.8 秒以內。FCP 直接影響使用者「覺得網站快不快」的第一印象。白話講：FCP 太慢，使用者看到的就是一片白，然後他就關掉了。改善 FCP 的關鍵是減少渲染阻塞 — 把關鍵 CSS 內聯、延遲載入非必要的 JavaScript。如果你的 Meta Description 和 Title Tag 寫得再好，但 FCP 太慢，使用者在看到內容前就已經走人了。
指標總覽對照表
| 指標 | 白話解釋 | 良好 | 需要改善 | 差 |
|---|---|---|---|---|
| LCP | 最大內容多久出來 | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| INP | 按鈕按了多久有反應 | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS | 頁面會不會亂跳 | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
| TTFB | 伺服器多久才回應 | ≤ 800ms | 800ms – 1800ms | > 1800ms |
| FCP | 畫面多久出現東西 | ≤ 1.8s | 1.8s – 3.0s | > 3.0s |
PSI 分數怎麼算出來的：權重與評分邏輯拆解
PSI 的 0-100 分不是隨便給的。背後有一套加權計算邏輯，每個指標佔的比重不同。知道這些權重，你才知道該把力氣花在哪裡。
效能分數的加權公式
Lighthouse 效能評分裡，各指標的權重是這樣分配的：LCP 大約佔 25%、Total Blocking Time（TBT，跟 INP 相關）佔約 30%、CLS 佔約 25%、FCP 佔約 10%、Speed Index 佔約 10%。看清楚了嗎？TBT 和 LCP 加起來就超過一半的分數。所以很多網站只要改善 JavaScript 執行時間和首圖載入速度，分數就能大幅跳升。這就是為什麼懂權重比懂所有細節更重要。
多少分算好？別被顏色嚇到
PSI 把分數分成三個等級。90-100 分是綠色（良好），50-89 分是橘色（需要改善），0-49 分是紅色（差）。但說實在的，90 分跟 100 分在 SEO 排名上的差異非常小。Google 的 John Mueller 說過，Core Web Vitals 只是排名的「決勝因素」，不是主要排名訊號。也就是說，兩個頁面其他條件都差不多的時候，速度快的會贏。但如果你的內容本身不夠好，速度再快也沒用。
我的實務建議：先把所有指標都推到綠色，再來想極致优化的事。從 50 分到 85 分的努力，報酬率遠高於從 95 分拚到 100 分。後面那 5 分，你可能要花前面 35 分十倍的時間。
PSI 跟其他速度工具比一比
市面上速度檢測工具一堆，各有各的定位。下面把最受歡迎的四個攤開來比較。這些工具都可以當成你 連結建設和技術最佳化之外的互補工具。很多人會問「PSI 跟 GTmetrix 哪個準」或「到底要用哪個」，其實答案很簡單：看你在什麼場景。
四大工具功能比較
| 功能 | PageSpeed Insights | GTmetrix | WebPageTest | Lighthouse CLI |
|---|---|---|---|---|
| 真實使用者資料 | 有（CrUX） | 無 | 無 | 無 |
| Lighthouse 整合 | 原生整合 | 使用 Lighthouse | 部分支援 | 本身就是 |
| 多地點測試 | 固定地點 | 多個地點 | 全球多點 | 本地執行 |
| 免費額度 | 無限制 | 有限制 | 有限制 | 無限制 |
| 適合對象 | 站長、SEO | 開發者、站長 | 進階開發者 | 工程團隊 |
什麼場景用什麼工具
日常健檢用 PSI 就夠了。免費、快速、資料跟 Google Search Console 一致。需要看瀑布圖（就是那種一條一條顯示每個資源載入順序的圖）的時候，GTmetrix 更直覺。WebPageTest 適合需要從全球不同地點測試的場景，比如你的網站同時服務台灣和東南亞讀者。Lighthouse CLI 則是開發者在本地開發或跑 CI/CD 自動化測試時的好夥伴。
WordPress 網站在 PSI 最常被扣分的原因
WordPress 是全球市佔率最高的 CMS，但它「什麼都能裝」的特性也是速度殺手。下面列出最常被扣分的幾個原因。排名是根據我過去兩年幫超過 30 個 WordPress 網站做速度最佳化時觀察到的，不是憑空猜的。
原因一：圖片沒壓縮就直接上傳
這是 WordPress 網站最常見的問題，沒有之一。很多站長寫文章的時候，直接把相機拍出來的 5MB 原圖丟上去。一篇文章五張圖就 25MB。LCP 想好都不可能。解法很簡單：上傳前用 TinyPNG 或 ImageOptim 壓一下。懶得手動壓的話，裝個 Smush 或 ShortPixel 之類的圖片壓縮外掛也行。更好的做法是改用 WebP 格式，同樣品質下檔案可以再小 25-35%。這個問題在 電商 SEO 網站上最嚴重，因為商品圖動輒幾十上百張。
原因二：外掛裝太多，一堆沒在用
WordPress 外掛方便歸方便，但每裝一個就可能多一堆 CSS 和 JavaScript。我之前看過一個網站裝了 42 個外掛，其中 15 個根本沒在用。這些閒置外掛照樣在每個頁面載入自己的資源，白吃白喝拖慢整站。建議你定期清外掛清單。超過三個月沒動過的就停用刪除。也不要裝功能重疊的，例如同時裝兩個快取外掛，只會互相打架。內部連結和 XML Sitemap 這些基本功能用免費的就好，不需要每個都找外掛。
原因三：佈景主題太肥了
免費或便宜的 WordPress 主題為了迎合所有人，通常塞了一大堆你不一定用得到的功能。頁面建立器類型的主題更是重災區。一個頁面可能載了 1MB 以上的 CSS 和 JS，光解析這些就夠讓瀏覽器卡半天了。如果你的網站以內容為主，選輕量的主題遠比選功能多的聰明。GeneratePress、Astra 這類輕量主題，裝好後的初始 PSI 分數通常比 Avada、Flatsome 高出 20-30 分。如果你同時在意 WordPress 安全性和速度，輕量主題這兩方面都佔優勢。
原因四：完全沒裝快取
WordPress 預設每次有人來訪問，都要重新從資料庫撈資料、動態組出 HTML。流量低的時候影響不大。但日流量破千以後，TTFB 就會開始拖慢。裝一個快取外掛（WP Rocket 或 LiteSpeed Cache 都行），把動態頁面靜態化，TTFB 通常能從 800ms 降到 200ms 以下。如果你的 主機支援，頁面快取加上物件快取（Redis 或 Memcached）的效果最好。記得也要配好 robots.txt，別讓搜尋引擎爬蟲把資源浪費在無效頁面上。
提升 PSI 分數的 10 個實用方法（按投資報酬率排序）
知道問題在哪，下一步就是動手改。下面 10 個方法按照「花的時間少、效果大」的順序排。越前面的方法，CP 值越高。先做前面幾項，你的分數就會有明顯進步。
方法 1-3：圖片、快取、主機（效果最大）
1. 全面改用 WebP 格式。WordPress 6.0 之後原生支援 WebP 上傳。把現有的 PNG 和 JPEG 批次轉檔，光這一步 LCP 就能改善 0.5 到 1.5 秒。用 ShortPixel 或 Imagify 可以一鍵搞定。如果你想了解為什麼 WebP 比較好，簡單說就是：同一張圖，WebP 用更聰明的方式壓縮，品質差不多但檔案小很多。
2. 啟用頁面快取。LiteSpeed 主機直接開 LiteSpeed Cache，其他主機裝 WP Rocket 或 WP Super Cache。這一步通常能讓 TTFB 直接砍半。如果只能做一件事改善速度，就做這件。
3. 換一台夠快的主機。如果你的主機 TTFB 就已經 1 秒以上了，前端再怎麼最佳化都很難救。考慮換到支援 PHP 8.x、用 NVMe SSD、機房在亞太區的主機。Kinsta 或 Cloudways 新加坡節點都是台灣站長常用的選擇。
方法 4-6：CSS、JavaScript、字型
4. 精簡 CSS 和 JavaScript。用 WP Rocket 的「最佳化 CSS 載入」功能，或 Rank Math 內建的程式碼精簡功能，把沒用到的 CSS 和 JS 砍掉或延遲載入。Perfmatters 這類外掛可以做到更細的按頁面條件載入。如果你正在比較 Rank Math 和 Yoast，速度最佳化功能是 Rank Math 的強項之一。
5. 延遲載入非必要的 JavaScript。Google Analytics、Facebook Pixel、LINE Tag 這些第三方追蹤碼都會拖慢頁面。用 Flying Scripts 或 WP Meteor 把它們延遲到使用者開始互動後才載入，INP 和 FCP 都會明顯改善。這就像請客人先進來坐，飲料晚點再上，總比讓他們在門口等全部飲料都調好才放行好。
6. 預載入關鍵字型。如果你用 Google Fonts 或任何外部字型服務，加上 font-display: swap 和 <link rel="preload"> 可以避免字型載入時造成的 CLS 和 FOIT（字型還沒載入時文字消失閃爍的問題）。
方法 7-10：進階最佳化技巧
7. 部署 CDN。主機在台灣但讀者遍布全球的話，CDN 是必要的。Cloudflare 免費方案就很好用。進階可以考慮 BunnyCDN 或 StackPath。CDN 不只加快靜態資源傳輸，也減少主機的負載。一舉兩得。
8. 設定 Lazy Loading。WordPress 5.5 以後內建圖片延遲載入。但建議再加裝 LazyLoad by WP Rocket 或類似外掛，確保 iframe（像是 YouTube 嵌入影片）也被延遲。一篇文章如果嵌了 5 個以上的影片，沒有 Lazy Loading 的話 FCP 和 LCP 都會被拖垮。這對做 影片 SEO 的網站尤其重要。
9. 減少第三方腳本。每個第三方腳本（廣告、追蹤、社群分享按鈕）都會增加頁面的 JavaScript 數量。用 Google Tag Manager 集中管理所有追蹤碼，比在頁面上直接放好幾個 script 標籤更乾淨。也定期檢查是不是有不再使用的腳本還掛在網站上。
10. 定期監控，別只測一次。網站速度不是一次最佳化就一勞永逸。每次更新 WordPress、更新外掛、新增文章、換圖片，都可能影響速度。建議用 PSI 至少每個月測一次首頁和流量最高的幾個頁面。也可以用 Google Search Console 的 Core Web Vitals 報告做持續追蹤。PTT 和 Dcard 上常常有站長分享自己的速度最佳化心得，值得參考別人的實戰經驗。
PSI API 開發者指南：把速度監控自動化
如果你會寫程式，或者團隊裡有工程師，PSI 有免費的 REST API 可以用。把速度監控自動化，對需要持續追蹤多個頁面的團隊來說超級實用。不用每次都手動開網頁輸入網址。
API 基本用法
PSI API 的端點是 https://www.googleapis.com/pagespeedonline/v5/runPagespeed，加上 url 參數指定要測的網址。你可以用 strategy=mobile 或 strategy=desktop 選擇測試裝置。免費額度每天 25,000 次查詢，對大多數團隊來說根本用不完。回傳的 JSON 裡包含完整的 Lighthouse 報告，你可以解析出每個指標的數值做自動化判斷。
整合到 CI/CD 流程
很多團隊會把 PSI API 串進 GitHub Actions 或 GitLab CI。每次部署前自動跑一次速度測試。如果分數低於設定的閾值（例如 80 分），就自動擋下來不讓它上線。這樣可以防止速度退化被無意間推到正式環境。Lighthouse CI（LHCI）是 Google 官方提供的工具，搭配 PSI 可以做更完整的自動化流程。YouTube 上有不少教學影片示範怎麼設定，有興趣的可以搜尋「Lighthouse CI setup」看看。
Core Web Vitals 在 Google 排名裡到底有多重要？
很多人問過我這個問題：「PSI 分數拚到 100 分，排名就會上去嗎？」答案是不一定。Core Web Vitals 是排名因素沒錯，但它的重要性常常被過度放大。
速度在排名中的真實地位
Google 說了很多次：頁面體驗訊號（包含 Core Web Vitals、HTTPS、行動裝置相容性、沒有侵入式插頁廣告）是排名的「決勝因素」。白話講就是：當兩個頁面的內容品質和 反向連結都差不多的時候，速度快的排前面。但如果你的內容本身就不行，速度再快也沒用。這跟 E-E-A-T 的邏輯一樣：內容品質永遠是基本盤。
速度如何間接影響 SEO
速度對 SEO 的影響，很大一部分是透過使用者行為間接傳遞的。載入慢的網站 跳出率高、停留時間短、點閱率低。這些行為訊號 Google 都看得到，也會拿來判斷頁面品質。Google 自己的研究說：頁面載入時間從 1 秒增加到 5 秒，轉換率會掉 90%。十個人裡有九個會跑掉。所以速度最佳化的價值不只在排名，更在於真實的商業成果。你的訂單、你的廣告收入，都跟速度有關。
Search Console 裡的 Core Web Vitals 報告
Google Search Console 裡有專門的 Core Web Vitals 報告，會告訴你哪些網址的 LCP、INP、CLS 不合格。它用的是 Field Data，所以更貼近真實使用者體驗。建議把這個報告和 PSI 的結果交叉看。找出「PSI 分數好但 Search Console 報紅燈」的頁面，那些通常是特定裝置或瀏覽器有問題。也要確認 Canonical URL 設定正確，不然 Search Console 可能會把重複頁面的資料分開統計，讓你誤判。
PageSpeed Insights 常見問題（FAQ）
PSI 分數多少才算好？
90 分以上是綠色良好區間。但從 SEO 角度來看，所有 Core Web Vitals 指標都通過（綠色）比總分更重要。80 分但所有指標都綠色，比 95 分但有紅色指標來得好。這跟 長尾關鍵字策略的概念很像：個別指標的品質比單一總分重要。
為什麼每次測 PSI 分數都不一樣？
Lab Data 雖然在受控環境跑，但網路波動、伺服器負載、CDN 快取狀態都會影響結果。Field Data 是過去 28 天的統計值，相對穩定。建議連續測三次取平均，或者直接看 Search Console 的長期趨勢更準確。
PSI 分數跟排名有直接關係嗎？
Core Web Vitals 是排名因素之一，但不是主要因素。內容相關性、反向連結品質、E-E-A-T 的重要性都高於速度。速度更像「加分題」— 在其他條件差不多的情況下，速度快的頁面會佔優勢。
手機版跟電腦版的 PSI 分數為什麼差那麼多？
PSI 手機版測試用的是模擬的中階手機（Moto G Power）加上 4G 網路。CPU 和網路速度都遠低於桌面環境。所以同一個頁面，手機版分數一定比電腦版低。這不是 bug，是刻意設計的，為了反映真實使用者的設備條件。因為 Google 採用 行動優先索引，手機版分數才是你該優先關心的。
為什麼我的網站沒有 Field Data？
Field Data 來自 Chrome UX Report，需要你的網站有一定的流量門檻才會被收錄。通常月流量低於幾千次的網站不會有 Field Data。別擔心，改看 Lab Data 就好。也可以在 Google Analytics 裡用網頁速度報告補充參考。
Lighthouse 跟 PageSpeed Insights 到底差在哪？
Lighthouse 是開源的瀏覽器審查工具，可以在 Chrome DevTools、命令列、或 CI 環境中執行。PSI 是 Google 的線上服務，底層跑的就是 Lighthouse。兩者的 Lab Data 結果基本一致，但 PSI 額外提供了 Field Data（來自 Chrome UX Report）和 SEO 相關建議。了解 SERP 排名機制的人會知道，PSI 的資料更貼近 Google 真正用來評估頁面的標準。
裝了 CDN 之後 PSI 分數一定會變好嗎？
不一定。CDN 主要改善靜態資源（圖片、CSS、JS）的傳輸速度。但如果你的伺服器回應本身就很慢，或頁面上的 JavaScript 太多太肥，CDN 能幫的有限。CDN 是速度最佳化的一環，不是萬靈丹。搭配 伺服器端快取、圖片壓縮、JS 精簡才能看到綜效。這就像穿了一件好的防風外套，但裡面的衣服如果不保暖，光靠外套還是不夠。
PSI 說「伺服器回應時間過長」怎麼辦？
先看 TTFB 數值。超過 800ms 就該處理了。優先做這幾件事：啟用頁面快取、把 PHP 升級到 8.x、檢查資料庫查詢有沒有瓶頸、考慮換回應更快的主機。共用主機的 TTFB 通常在 500-1500ms 之間，升級到 VPS 或管理型主機可以降到 200ms 以下。也建議用 Google Keyword Planner 確認目標關鍵字的競爭程度，決定速度最佳化的優先順序。
Google AI 搜尋會看 PSI 分數嗎？
Google 的 AI Overview（AI 搜尋摘要）生成時會考慮頁面體驗。如果你的頁面載入太慢，AI 爬蟻可能無法完整抓取內容，導致你的頁面不會出現在 AI 搜尋結果裡。所以 PSI 分數不只影響傳統排名，也影響你的 AI 搜尋時代的能見度。這是很多站長還沒意識到的。
可以用 ChatGPT 幫我看 PSI 報告嗎？
可以。把 PSI 的 JSON 報告貼給 ChatGPT 或 Claude，請它幫你分析哪些問題該優先處理，效果不錯。不過要小心一件事：AI 給的建議有時候太通用，沒考慮到你網站的具體情況。最好的做法是用 AI 當第一輪篩選，再根據你對自己網站的了解做判斷。畢竟沒有人比你自己更清楚你的網站裝了哪些外掛、用了什麼主題。
PSI 分數突然掉很多是什麼原因？
常見原因有幾個：最近裝了新外掛、WordPress 或外掛自動更新後出了相容性問題、主機效能下降、流量突然暴增導致伺服器負載過高。另一個很多人忽略的原因是：CDN 快取被清掉了，重新建立快取的期間分數會暫時偏低。遇到這種狀況別急，先連測三次確認不是單次波動，再逐一排查最近有什麼變動。
把 PSI 當成網站健檢的例行功課
PageSpeed Insights 從 2018 年整合 Lighthouse 到現在，已經從單純的跑分工具變成全方位的速度診斷平台。它同時提供 Lab Data 和 Field Data、直接對接 Core Web Vitals、資料跟 Search Console 一致。對台灣站長來說，PSI 是零成本、零門檻的速度最佳化起點。把它和你現有的 Semrush 或 Yoast SEO 工作流程結合，就能形成從 On-Page 到 Off-Page 完整的 SEO 體系。
但有一件事一定要記住：PSI 分數不是目的，使用者體驗才是。一個 85 分但內容紮實、導覽清楚的網站，比一個 100 分但內容空洞的網站有價值得多。速度最佳化是持續的過程，不是一次性的衝分活動。每個月花 10 分鐘跑一次 PSI，搭配 Search Console 的 Core Web Vitals 報告，確保 網站速度沒有悄悄退化。同時別忘了做好 多語系 SEO 和 社群媒體 SEO，讓網站從各個面向都能獲得流量。這才是把 PSI 真正用好的方式。
