網站速度優化要先量測、再動手：用 PageSpeed Insights 與 Search Console 的 Core Web Vitals 報告找出慢在哪裡，再處理圖片、快取、腳本、字型和主機。Google 以 LCP、INP、CLS 三項核心指標衡量載入、互動與版面穩定度，良好標準分別是二點五秒內、兩百毫秒以內、零點一以下。找出不及格的那個指標、對準它的成因處理，就不必每一項都重做。
先看懂三項核心指標在量什麼
| 指標 | 衡量什麼 | 良好標準 | 常見拖累來源 |
|---|---|---|---|
| LCP（Largest Contentful Paint） | 主要內容（常是主視覺圖或大標題）顯示完成的時間 | 開始載入後二點五秒內 | 伺服器回應慢、主圖過大或被延遲載入 |
| INP（Interaction to Next Paint） | 使用者點擊、輸入後，畫面做出回應的時間 | 兩百毫秒以內 | 長時間執行的 JavaScript、過多第三方腳本 |
| CLS（累計版面配置位移） | 載入過程中版面意外跳動的程度 | 零點一以下 | 圖片與廣告沒預留空間、字型替換 |
INP 已取代舊的 FID 成為互動回應的核心指標。LCP 還能拆成首位元組時間（TTFB）、資源載入延遲、資源載入時間與元素算繪延遲四段，先找出卡在哪一段再處理。
用兩個 Google 工具找出問題頁
兩個工具的資料來源不同，要搭配著看：
- Search Console 的 Core Web Vitals 報告：以實際使用者資料呈現，網址依體驗相似度分組，狀態分為良好、需要改善、不良，適合找出哪一類頁面有問題。
- PageSpeed Insights：同時提供現場資料（Chrome 使用者體驗報告）與實驗室資料（Lighthouse 在單一裝置、固定網路條件下的模擬），適合看單一網址的診斷建議。
流程是先在 Search Console 找出狀態不佳的群組，挑一個代表網址丟進 PageSpeed Insights，確認哪項指標不及格，再依診斷決定從哪裡下手。Lighthouse 無法量測 INP，實驗室裡可改看總封鎖時間（TBT）。
圖片：格式、尺寸與載入順序
- 改用新式格式：AVIF 與 WebP 的壓縮與品質都優於 JPEG、PNG，舊版瀏覽器可保留 JPEG 或 PNG 備用。
- 依螢幕提供合適尺寸：用 srcset 與 sizes 提供多種尺寸，讓手機不必下載電腦版大圖。
- 標註寬高：圖片加上 width 與 height 屬性，或用 CSS 的 aspect-ratio 預留空間，避免版面跳動。
- 首屏圖片不要延遲載入：loading 屬性設為 lazy 適合畫面下方的圖片，可視區域內的圖片，尤其是 LCP 圖片，不應延遲載入。
- 提高主圖優先順序：確定是 LCP 元素的圖片，可以把 fetchpriority 屬性設為 high。
快取：讓重複造訪不必重新下載
瀏覽器的 HTTP 快取是減少重複下載的頭一道防線，由伺服器回傳的 Cache-Control 標頭決定快取方式與時間。web.dev 建議的分法是：
- 帶版本資訊的靜態檔：檔名含雜湊或版本號的 CSS、JavaScript 與圖片，可設定很長的快取期限，更新時改檔名即可。
- 沒有版本資訊的網址：例如 HTML 頁面，可用 no-cache 讓瀏覽器每次使用快取前先向伺服器重新驗證，驗證依據建議用 ETag。
伺服器端也有快取：動態網站每次查資料庫產生頁面會拉長回應時間，頁面快取能直接送出已產生的結果。但快取會掩蓋後端真正的速度，測量伺服器效能時可能要略過快取。
程式碼與第三方腳本：減輕主執行緒負擔
一次互動分成輸入延遲、處理時間與顯示延遲三段，主執行緒被長時間工作佔住時，瀏覽器就無法及時回應點擊。處理方向：
- 拆分長時間工作：把事件處理拆小、適時讓出主執行緒，先更新畫面再處理非必要工作。
- 縮小 DOM：頁面元素過多時，算繪工作會跟著變重，拖慢初次顯示與每次互動。
- 盤點第三方腳本：分析、廣告、社群嵌入等第三方指令碼是拖慢網站的常見原因，非關鍵的用 async 或 defer 載入，沒有明顯價值的就移除；Lighthouse 的 JavaScript 執行時間診斷可以當作盤點起點。
- 控制外掛數量：WordPress 的外掛可能各自載入腳本與樣式，定期清掉閒置與功能重疊的外掛，做法可參考WordPress 外掛數量的控制原則。
字型：中文網站要注意檔案大小
繁體中文字型收錄的字元數量龐大，整套載入的負擔不小。可以照這幾個方向處理：
- 字型子集化：只保留網站實際用到的字元，縮小檔案；子集化與自行代管前，先確認字型授權。
- 設定 font-display：swap 先用備用字型顯示再替換，字型要及早送達以免位移；optional 是 web.dev 推薦的效能優先做法，字型來不及載入就不使用。
- 預先連線：使用外部字型服務時，用 preconnect 提早連線。
- 自行代管先實測：沒有搭配相應的優化技術時，自行代管字型的效能不太可能提升。
主機、CDN 與通訊協定
web.dev 把主機代管列為改善首位元組時間（TTFB）時優先考慮的事項：主機要能負荷流量、記憶體足夠、後端軟體維持更新。TTFB 不是核心指標，但數值偏高時 LCP 很難達標，轉址過多也是 TTFB 偏高的常見原因。
訪客與主機距離較遠時，可以考慮內容傳遞網路，由靠近使用者的伺服器快取並送出資源；CDN 也可能使用 HTTP/2 或 HTTP/3，其中 HTTP/3 改用 UDP，解決了 HTTP/2 所依賴的 TCP 行首封鎖問題。原理與適用情境可參考CDN 是什麼。
優化後怎麼驗證成果
- 每改一項就用 PageSpeed Insights 重測實驗室資料，避免一次改太多、看不出哪一項有效。
- 現場資料反映一段期間內的真實體驗，不會立刻變化，需要持續觀察。
- 在 Core Web Vitals 報告修正某個問題後，可以按「開始追蹤」啟動驗證；監控期間只要任一網址仍有問題，就會被標為未修正。
- 以真實使用者感受得到的順暢為目標。Google 表示，若只是為了 SEO 追求滿分，不建議花時間這麼做。
常見問題
網站速度會影響 Google 排名嗎？
會列入考量，但不是全部。Google 說明排名系統會使用 Core Web Vitals，也表示即使網頁體驗不夠理想，仍會盡可能顯示相關性高的內容，速度和內容品質要一起顧。
PageSpeed Insights 每次測的分數都不一樣，正常嗎？
常見。Lighthouse 說明分數波動通常來自基本條件變化，例如網路路由異動、測試裝置不同、瀏覽器擴充功能或內容的 A/B 測試。多測幾次看趨勢，並以現場資料為主要依據。
Core Web Vitals 報告顯示沒有資料，是什麼原因？
報告採用實際使用者資料，網址群組的資料量不足時不會列出，也只顯示已建立索引的網址。流量較小的網站常見這種情況，可先用 PageSpeed Insights 的實驗室資料檢查。
手機版和電腦版要分開優化嗎？
要分開看。Google 建議行動裝置與電腦分別評估核心指標，兩邊的版型、圖片尺寸與載入的腳本也常不同，問題來源未必一樣，修正後兩種裝置都要重測。
裝了快取外掛，速度問題就解決了嗎？
不一定。快取能縮短伺服器產生頁面的時間、減少重複下載，但解決不了圖片過大、腳本佔住主執行緒或版面位移。先用報告確認哪一項指標不及格，再決定對策。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
建議先打開 Search Console 的 Core Web Vitals 報告，找出狀態不佳的網址群組，再用 PageSpeed Insights 確認是哪一項指標拖後腿。京采的技術 SEO 與網站健檢服務會從圖片、腳本、字型到主機設定逐項檢查，整理出依影響程度排序的修正清單；想討論網站速度的問題，歡迎與我們聯繫。
