網站速度怎麼改善？看懂 PageSpeed、LCP、INP 與 CLS

看到網站測速分數偏低，不必立刻刪掉主視覺或全部動畫。先確認訪客在哪個步驟感到慢：內容遲遲不出現、按鈕按了沒有反應，還是閱讀中畫面一直移動。不同問題需要不同修正，單一分數無法代替診斷。

網站速度工作的目的，是讓內容能順利被看見與操作，並保留品牌需要的設計。以下從報表判讀到改善順序，說明業主可以和開發團隊一起確認的重點。

一、 分數與真實體驗是不同層次的資料

PageSpeed Insights 同時提供受控環境的實驗室測試，以及在有足夠樣本時提供真實使用者資料。前者可用來找問題與比較修改；後者來自 Chrome 使用者體驗報告，也就是 CrUX，反映一段期間內的實際體驗。PageSpeed 官方說明。

讀取報表時確認資料是單一網址，還是整個來源網域的彙整。若沒有足夠真實樣本，就記錄「資料不足」，不能把實驗室高分寫成通過真實使用者評估。手機與桌面、首次與重複瀏覽、不同網路情況，本來就可能得到不同結果。

盤點時至少挑選不同用途的代表頁：首頁看主要內容出現的速度、作品頁看圖片瀏覽、服務或聯絡頁看操作回應。只測首頁，容易漏掉大量作品圖片或特定互動帶來的問題。將訪客反映的裝置、頁面與操作也記錄下來，讓工具結果能對應實際使用情境。

二、 LCP、INP 與 CLS 代表什麼？

LCP 觀察畫面中最大的主要圖片或文字區塊何時呈現，協助了解主要內容載入。INP 觀察使用者互動後到下一次畫面更新的回應延遲。CLS 則衡量非預期版面位移，並不是以秒數表示的速度。這三項是目前的 Core Web Vitals，也就是核心網頁體驗指標。Web Vitals 文件。

實驗室報表中的 TBT 是總阻塞時間，能協助發現頁面載入時的主執行緒工作問題，但它不是 INP，不能改名當成真實互動成績。web.dev 的實驗室與實際資料差異說明也指出，兩者量測情境不同。

官方對良好體驗的參考門檻為 LCP 不超過 2.5 秒、INP 不超過 200 毫秒、CLS 不超過 0.1；判讀真實資料時看的是第 75 百分位，並區分手機與桌面。它們不是所有訪客的平均值，也不能用一次電腦測試代替整段期間的資料。若某項未提供數值，先記錄缺少資料，不用其他指標補成「通過」。

三、 圖片與主要內容先處理哪些事？

先找出主要內容元素，再檢查圖片尺寸、檔案量、載入時機與傳送速度。若畫面只需要中等尺寸圖片，就不必讓手機下載不必要的大檔；但也不應過度壓縮到作品細節失真。

首屏主要圖片，尤其是 LCP 圖片，不應套用一般延遲載入；畫面下方的圖片則可依情境延後取得。不要把所有圖片都設成最高優先，也不要為了分數任意更換品牌構圖。可依 LCP 改善指南確認資源何時被發現及開始下載，再做有針對性的調整。

假設一個作品網站的主圖已經很清楚，但進入頁面時還同時下載整套相簿，改善重點可能是下方作品的載入安排。若主圖本身很晚才開始下載，則應先檢查它是否被輪播程式或背景設定延後發現。兩種情況都不能只用「圖片很多」判斷，更不需要先刪除最能呈現作品品質的照片。

四、 JavaScript 與第三方工具

把網站使用的互動程式和外部工具列出來，確認每一項的用途、負責人與是否重複。追蹤碼、聊天工具、影片嵌入或社群元件，都可能增加網路與執行工作；不能只因為不是自己寫的程式，就忽略影響。

改善時先處理不需要的重複安裝、過早載入與過重的工作，再檢查導覽、輪播、篩選及返回上一頁是否正常。需要延後執行時，也要保留可理解的操作狀態，避免按鈕看起來能用卻沒有反應。INP 改善指南可作為開發端查找互動延遲的依據。

可以在預覽環境一次停用一個非必要工具，確認問題是否隨之消失，再決定保留、延後或移除。追蹤與同意管理不能為了分數直接刪掉；嵌入影片若改成點擊後載入，也要讓訪客看得懂如何播放。每項調整都應同時記錄效能變化及功能是否仍可用。

五、 字型與版面位移

圖片和嵌入內容應預留合適尺寸，避免載入後突然把段落推開。品牌字型載入前後的字寬與行高也可能不同，應檢查替代字型及載入策略，而不是直接拿掉品牌字體。

測試不只停在首屏。往下捲動、展開 FAQ、進入作品後返回，都可能出現另一種位移或互動問題。依 CLS 改善指南排查缺少尺寸的媒體、動態插入內容與字型變化，並在修改後對照畫面，確保沒有破壞原本留白與內容完整性。

六、 改善前後如何公平比較？

先固定網址、版本、裝置模擬、網路與快取條件，保存原始報告；在同樣條件下重測，觀察多次結果，不挑最好看的一次當成果。真實使用者資料有自己的收集期間，不能期待部署後立即完整反映新版本。

實務上可先各測三次，並保留每次結果與中間值作為討論起點；這是便於比較的工作方法，不是 Google 規定的測試次數。若結果差距很大，先找出環境或外部資源的變動，再決定是否需要增加測試。修正順序則先處理無法閱讀或操作的問題，再處理主要內容、互動延遲及位移，最後檢視剩餘工具建議是否值得投入。

以下是測試記錄範本，欄位用來填入實際結果，不代表網站已經達標。

數值改善後，還要實際確認導航、圖片與聯絡動線。若測試環境或內容不同，就清楚標明不能直接比較；沒有真實資料時，僅回報已測的條件。

七、 常見問題

7.1 Lighthouse 滿分就代表排名會變好嗎？

不能這樣推論。分數是工具在特定條件下的評估，並不等於搜尋排名、詢問或營收保證。

7.2 圖片全部延後載入比較快嗎？

不一定。首屏主要圖片被延後，反而可能讓重要內容更晚出現。應區分主要內容和畫面下方資源。

7.3 沒有 CrUX 資料是不是代表網站很差？

不是。可能只是樣本不足。可以先用受控測試和實際裝置診斷，但必須如實標記資料限制。

八、 相關閱讀與下一步

手機版的閱讀與操作也會影響實際體驗，可搭配 RWD 手機版驗收清單，把速度數據和選單、圖片、表格的操作一起檢查。

本篇技術規則依各節列出的 Google 與 web.dev 官方文件核對。評估技術案例時，也應查看受測網址、日期與環境；單獨的分數或提升比例，仍不足以判斷能否套用在自己的網站。

若正在規劃改版，可先閱讀網站設計指南並了解網站建置服務。討論改善時，提供受測網址、報告與實際卡住的操作，比只傳一個分數更容易找出優先處理的問題。