網站速度優化：PageSpeed 報告先修哪三項

Photo by Jake Givens on Unsplash

把自家官網網址丟進 Google 的 PageSpeed Insights，螢幕上跳出一個紅色的 38 分，下面接著二十幾條英文建議：減少未使用的 JavaScript、延後載入螢幕外圖片、避免大型版面配置位移……多數老闆看到這一頁的反應是關掉分頁，然後把這件事丟回給網站廠商，再被回一句「這個要大改，報價另計」。

速度問題之所以難處理，不是因為技術太深，而是因為報告把二十幾件事平鋪在同一頁，看起來每一項都要做。實際上對大多數中小企業官網來說，真正會讓客戶等到不耐煩的只有三件事，而這三件事有明確的先後順序。這篇把報告拆開，說明哪一項先修、哪一項可以先放著。

先看懂：報告上有兩種資料，只有一種算數

PageSpeed Insights 這一頁其實混了兩種完全不同的東西，分不清楚就會修錯方向。

上半部標示「探索實際使用者正在經歷的情況」，是 Google 從 Chrome 使用者端收集的真實瀏覽資料，取最近 28 天的滾動統計。這一段才是你的客戶真正遇到的速度。流量太小的網站可能看不到這塊，因為樣本不足，Google 就不顯示。

下半部那個 0 到 100 的分數，是 Lighthouse 在模擬環境跑出來的實驗室結果。它預設模擬一支中階手機、刻意壓低的網路速度，所以分數偏低是正常的。它的價值在於「告訴你哪裡慢」，而不是「你有多慢」。

另外一個常被忽略的開關：報告右上角可以切換行動版與電腦版。台灣中小企業官網的流量普遍以手機為主，先看行動版才有意義。電腦版好看、行動版難看，是非常常見的組合。

Photo by Peter Yost on Unsplash

三個指標，各自代表一種被惹毛的方式

報告裡的核心指標只有三個，分別對應訪客的三種不耐煩。記住它們的門檻，比記住二十條建議有用得多。

LCP（最大內容繪製）：從點進來到畫面上最大的那塊內容（通常是首圖或大標題）顯示完成，花了幾秒。2.5 秒以內算良好，超過 4 秒算差。對應的訪客感受是「這頁一直白白的」。

CLS（累積版面配置位移）：頁面載入過程中，內容有沒有自己跳動。0.1 以內算良好，超過 0.25 算差。對應的感受是「我正要按，按鈕跑掉了」。

INP（與下一次繪製的互動延遲）：訪客點了按鈕、展開選單之後，畫面隔多久才有反應。200 毫秒以內算良好，超過 500 毫秒算差。這個指標在 2024 年 3 月正式取代舊的 FID，衡量的是整段互動而不只是第一次點擊，所以很多以前看起來沒問題的網站，換算成 INP 之後才露出馬腳。對應的感受是「我點了，它沒反應，我再點一次」。

第一順位：LCP ——先處理首圖與主機

如果只能修一件事，修 LCP。訪客對白畫面的耐性最低，而且這一項通常最好修。

最常見的兩個原因，第一個是首圖太肥。不少官網的橫幅主視覺是設計稿直接輸出的 JPG，動輒三、四 MB，手機用 4G 開要好幾秒。處理方式是壓縮並轉成 WebP 或 AVIF 格式，寬度依實際顯示尺寸輸出，大多數橫幅圖壓到 200KB 以內畫質仍然足夠。這件事不需要改程式，用線上壓縮工具或請設計重新輸出就能完成。

第二個是主機回應太慢，也就是報告裡的 TTFB（首位元組時間）。Google 建議控制在 0.8 秒以內。共用主機塞了幾十個網站、資料庫查詢沒有快取、WordPress 外掛裝了三十幾個，都會讓這個數字惡化。這類問題換主機方案或加上快取機制通常有感，但要先量過 TTFB 再決定，不然很容易花了升級費卻沒改善。

還有一個反直覺的細節：很多網站為了省流量，把圖片全部設成延遲載入（lazy loading）。首屏的主視覺如果也被延遲載入，反而會讓 LCP 變慢。首屏那一張要排除在外。

第二順位：CLS ——讓版面不要自己跳

版面位移不會讓頁面變慢，但它造成的惱怒程度往往更高，而且修起來便宜。

最常見的來源是圖片沒有指定寬高。瀏覽器在圖片下載完成前不知道要留多少空間，圖片一到就把下面的文字推下去。解法是在 HTML 的 img 標籤補上 width 與 height 屬性，或用 CSS 的 aspect-ratio 先把空間佔住。

第二個來源是後來才插入的區塊：頂部公告條、Cookie 同意條、促銷橫幅、第三方廣告位。它們通常是 JavaScript 跑完才塞進畫面，把整頁往下推一截。做法是事先保留固定高度的位置，或改成浮動在內容上方而不是推擠內容。

第三個來源是網頁字型。自訂字型載入前後字寬不同，整段文字會重排。中文字型檔案大，這個問題在中文站特別明顯。在 CSS 加上 font-display: swap、並且只載入實際用到的字重，可以減少跳動幅度。

第三順位：INP ——通常是外掛和第三方腳本

INP 偏高幾乎都指向同一個方向：頁面上跑的 JavaScript 太多，瀏覽器忙著處理，沒空回應點擊。

先盤點一份清單：線上客服外掛、社群分享按鈕、彈窗工具、熱點圖工具、各家廣告追蹤碼、輪播特效、動畫套件。中小企業官網常見的狀況是這些東西在三、五年間陸續加上去，沒有人記得哪些還在用。停用一半通常不影響任何業務，INP 就回到正常範圍。

還在用的腳本，可以請廠商改成延後載入——等頁面主要內容顯示完、或等訪客開始捲動才載入。客服小工具是最典型的例子，它不需要在第 0.1 秒就出現。

如果網站是 WordPress，外掛數量往往是最大的變數。這一項的檢查成本很低：到後台把停用候選清單逐一關掉，再測一次，數字自己會說話。

Photo by Ann Ann on Unsplash

四個容易踩的坑

追滿分。實驗室分數從 50 拉到 70，訪客有感；從 90 拉到 98，通常只有工程師有感，成本卻高出許多。把目標設在三個核心指標都進入綠色範圍，比追分數實際。

只測首頁。首頁被盯得最緊，通常也最快。真正帶來詢問單的是產品頁、服務說明頁、部落格文章頁，這些頁面常常塞了更多圖片和外掛。至少各挑一頁測。

改完不回頭量。真實使用者資料是 28 天的滾動統計，今天改完，報告上半部不會馬上變。要看立即效果，看下半部的實驗室數據；真實資料則要等幾週後再回來確認。

把速度當成排名特效藥。網頁體驗確實是 Google 的排名考量之一，但它的權重遠低於內容本身是否回答了搜尋者的問題。速度的直接價值在於減少跳出、讓已經來的訪客願意往下看，把它當成轉換率問題處理會比當成 SEO 問題更貼近現實。

一個可以今天就開始的順序

不必等到改版。建議的執行順序是：先把行動版的首頁、一個主力產品或服務頁、一篇部落格文章各測一次，把三個核心指標的數字抄下來；接著處理首圖體積與首屏延遲載入設定，這一步通常不需要動到程式；再補上圖片的寬高屬性、處理會跳動的公告條；最後盤點第三方腳本與外掛，把沒在用的停掉。每做完一輪就重測一次，記錄數字的變化。

這份紀錄還有另一個用處：當廠商報價「網站優化」時，你手上有改前改後的具體數字，可以問出對方到底打算動哪一項、預期改善多少。速度這件事的好處就在於它可以被量測，對話因此可以從感覺回到證據。