PageSpeed 是什麼？先看真實體驗，再看效能分數
PageSpeed 指的是「網頁速度」，但網站效能不只包含載入時間，也涉及操作是否即時、版面是否穩定。想知道網站該如何加速，可先使用 Google 免費工具PageSpeed Insights，輸入網址，分別查看行動裝置與電腦版報告，再依問題影響程度安排改善。
PageSpeed Insights，簡稱 PSI，結合 Chrome 使用者體驗報告（CrUX）的實際使用資料，以及 Lighthouse 模擬環境的檢測結果。前者協助判斷使用者真正遇到的體驗，後者提供效能問題與最佳化方向。
PSI 分數不等於載入秒數，也不是 SEO 排名保證。 Google 沒有規定網站必須達到 80 分才適合做 SEO；即使拿到 100 分，也不代表內容品質、搜尋意圖與網站可信度都已達標。
PageSpeed 與 SEO 有什麼關係？
Google 的排名系統會使用 Core Web Vitals，也就是「網站體驗核心指標」。不過，Google 搜尋中心明確說明，良好的核心指標成績不保證搜尋排名位居前列。
網頁速度的價值，在於減少等待與操作阻礙。內容尚未出現、按鈕沒有反應，或版面突然位移，都可能妨礙閱讀、填表與購買，但實際影響仍須透過網站分析資料驗證，不能直接套用固定的轉換率提升比例。
符合經驗、專業、權威性與可信度原則的文章，仍須具備可靠來源、清楚解答與正確資訊。速度最佳化能改善閱讀環境，卻無法取代內容本身的價值；E-E-A-T 也不是 PSI 會計算的分數。
PageSpeed Insights 教學：如何看懂網站速度報告？
輸入網址，分別檢查手機與電腦
開啟 PageSpeed Insights 線上工具，輸入完整網址後執行分析。建議優先測試首頁、主要商品頁、服務頁及高流量文章，不要只用首頁成績代表整個網站。
行動裝置與電腦的模擬條件不同，因此分數不一致很常見。判讀時應配合實際訪客的裝置比例，而不是只挑較高的成績作為成果。
先看實際使用資料，再看實驗室診斷
CrUX 通常呈現過去 28 天的彙整資料，因此剛完成的修改不會立即完整反映在報告中。若單一網址資料不足，PSI 可能顯示來源層級資料，或沒有足夠資料可供呈現；務必確認報告描述的是該頁面還是整個來源。
Lighthouse 則是在指定條件下執行模擬測試，適合找出當下可改善的問題。分數可能受伺服器負載、第三方程式與測試環境影響，宜重複測量並觀察趨勢。
正確認識 Core Web Vitals
核心指標包含 LCP、INP 與 CLS。實際體驗通常以第 75 百分位數判讀，也就是至少 75% 的體驗需要落在相應門檻內；三項都達到良好標準，才算通過核心指標評估。
網頁效能指標比較表
| 指標 | 主要觀察內容 | 良好門檻 | 常見改善方向 |
|---|---|---|---|
| LCP：最大內容繪製 | 主要內容出現的時間 | 2.5 秒以內 | 改善主機回應、首屏圖片與阻塞資源 |
| INP：與下一次繪製的互動時間 | 點擊等互動後的視覺回應 | 200 毫秒以內 | 減少 JavaScript 長任務與主執行緒負擔 |
| CLS：累計版面配置位移 | 非預期的版面移動 | 0.1 以下 | 預留圖片、廣告及嵌入內容空間 |
| FCP：首次內容繪製 | 首次出現文字或圖片的時間 | 1.8 秒以內 | 改善初始回應與轉譯阻塞 |
| TBT：總阻塞時間 | 實驗室測試中的主執行緒阻塞 | 行動測試通常以 200 毫秒以內為良好 | 拆分長任務、降低程式執行成本 |
FCP 與 TBT 是診斷參考，不屬於現行三項 Core Web Vitals。舊資料常提到 DCL，或以 FID 評估互動性，但目前核心互動指標是 INP，不能沿用過時說法。
PageSpeed 分數怎麼算？需要追求 100 分嗎？
PSI 的 Lighthouse 效能分數介於 0 至 100 分，通常以 90 至 100 分為良好、50 至 89 分為需要改善、0 至 49 分為不佳。這是多項實驗室效能指標的加權結果，不是單純測量網頁多久載入完成。
搜尋 PageSpeed Calculator 時，常見的是 Lighthouse 評分計算器。這類工具可用於理解不同指標對分數的影響，但必須確認對應版本，因為評分模型可能更新。
改善順序應以使用者影響為主，而不是逐條消除警告。 例如主要商品圖遲遲不出現，通常比縮減少量已快取資源更值得優先處理；診斷中的預估節省時間，也不能全部相加當成實際加速成果。
SiteSpeed、GTmetrix 與 WebPageTest 怎麼選？
不同工具的用途不完全相同。PSI 適合快速確認核心指標與改善方向；WebPageTest適合深入觀察請求瀑布圖、載入過程與不同測試條件；GTmetrix則提供效能報告，方便檢查資源負擔，實際功能與可選條件依方案而異。
若要建立持續監測流程，sitespeed.io可協助自動化測試；Google Lighthouse 通常指 Google Lighthouse，可透過 Chrome 開發人員工具或命令列執行，不必每次都使用 PSI 網站。
速度測試關鍵字的用途差異
| 工具或搜尋用語 | 適合用途 | 判讀注意事項 |
|---|---|---|
| PageSpeed Insights | 檢查真實體驗與模擬效能 | 確認資料層級及裝置類型 |
| Google Lighthouse | 開發階段診斷與重複測試 | 本機測試條件會影響結果 |
| GTmetrix | 分析載入資源與效能瓶頸 | 不同地點、方案與設定不能直接比較 |
| WebPageTest | 檢查瀑布圖、影片與快取影響 | 測試地點及連線條件須一致 |
| SiteSpeed | 自動化測試與長期趨勢追蹤 | 通常需要部署與設定能力 |
| speedtest | 測量網路下載、上傳與延遲 | 不能直接代表網站效能 |
| Webspeedtest、Googlespeedtest | 常見的速度測試搜尋字詞 | 名稱不一定對應單一工具，須確認服務來源 |
家中 speedtest 結果很快，不代表網站一定快；後端處理、圖片大小及 JavaScript 執行仍可能造成延遲。搜尋 Googlespeedtest 或 Webspeedtest 時，也應先分辨是在測試網路連線，還是測試網頁載入。
提升 PageSpeed 的五個實務方向
改善主機回應與快取
若初始回應偏慢，應檢查後端程式、資料庫查詢、重新導向與快取設定。CDN 有助於縮短部分資源的傳輸距離，但不能自動修正緩慢的動態查詢。
登入頁、購物車與個人化內容要特別設計快取規則，避免將私人資訊錯誤提供給其他使用者。
最佳化圖片與首屏內容
依顯示尺寸輸出圖片，並視支援情況採用 WebP 或 AVIF。首屏主要圖片若是 LCP 元素，通常不應套用延遲載入；非首屏圖片則可考慮 lazy loading。
圖片應設定寬高或比例，降低載入後推擠內容的機會。壓縮時也要兼顧可讀性與商品細節。
減少 JavaScript 執行負擔
盤點未使用的套件、外掛與第三方追蹤程式，移除不必要功能，並拆分長任務。延後執行程式不代表執行成本消失，仍須實測選單、表單與結帳是否正常。
INP 問題往往需要分析實際互動，不能只看初始載入報告就判定已改善。
降低 CSS 與字型阻塞
移除不需要的 CSS，避免大量樣式阻塞首屏呈現。繁體中文字型可能較大，可評估系統字型、字型子集及載入策略，但要確認沒有缺字或明顯版面跳動。
預留動態內容空間
廣告、影片與外部嵌入元件應預先保留適當空間。避免在使用者閱讀時，於內容上方突然插入橫幅，這類調整有助於降低 CLS 及誤點風險。
結論：用一致測試與真實資料驗證成果
PageSpeed 最佳化應形成持續流程：先記錄重要頁面的基準，找出影響最大的問題，修改後用相同條件複測，再追蹤 CrUX 與站內使用資料。
短期可用 Lighthouse 確認修改方向，長期則觀察核心指標與實際操作體驗。相關定義可核對PSI 官方文件及Web Vitals 說明。目標不是取得漂亮截圖，而是讓訪客穩定、順暢地完成任務。
PageSpeed 常見問題
1. PageSpeed Insights 免費嗎？
是，Google 提供免費線上分析。透過 API 大量使用時，則需確認配額與相關使用限制。
2. PageSpeed 一定要 100 分嗎？
不必。應優先改善真實使用者遇到的問題，再評估繼續提高分數的成本與效益。
3. PSI 低於 80 分就無法排名嗎？
不是。Google 沒有這項排名門檻，搜尋表現仍取決於內容相關性、品質及其他訊號。
4. 為什麼手機分數通常比較低？
行動模擬測試通常採用較受限的處理效能與網路條件，更容易暴露圖片或程式負擔。
5. 為什麼每次測試分數不同？
伺服器負載、第三方資源及測試環境都可能造成波動。建議多次測量，不以單次成績下結論。
6. 沒有 CrUX 資料代表網站不好嗎？
不代表。可能是符合條件的樣本不足；仍可先利用實驗室測試診斷問題。
7. 安裝快取外掛就能解決速度問題嗎？
不一定。快取主要降低部分重複處理成本，無法取代圖片最佳化、程式精簡與互動問題排查。
8. PSI 可以取代完整 SEO 健檢嗎？
不能。它以效能與相關稽核為主，無法完整評估索引、內容策略、內部連結與搜尋需求。
9. 網站更新後多久會反映成效？
實驗室測試可在更新後重新執行；CrUX 採滾動期間彙整，真實體驗改善會逐步反映。
10. PageSpeed Insights 已經淘汰了嗎？
沒有。部分舊版擴充工具已停止使用，不代表線上 PSI 服務淘汰；目前可直接使用官方網站分析。