「明明功能都開發完了，為什麼你的 PageSpeed Insights 還是一片紅字？」
你是否也曾經盯著 PageSpeed Insights 那個令人焦慮的紅色分數，看著 LCP 4.5 秒、CLS 0.25 的警告，卻不知道從何下手？在現代網頁開發中，速度不僅僅是使用者體驗（UX）的問題，更是搜尋引擎優化（SEO）的關鍵指標。Google 的 Core Web Vitals（核心網頁指標）已經成為衡量網頁品質的標準。本文將深入探討如何系統性地提升網頁效能，讓你輕鬆拿下 PageSpeed Insights 的高分。
Google PageSpeed Insights 的分數往往讓開發者頭痛，但它其實是網站健康度的重要指標。這篇文章不談高深的伺服器架構，而是整理了從圖片優化、字體載入到程式碼縮減的關鍵策略。無論你是前端工程師還是網站管理者，這份指南都能協助你打造極速且穩定的網頁體驗，提升 SEO 排名與使用者留存率。
一、知己知彼：Google 到底在乎什麼？
在動手優化之前，我們先對齊一下目標。Google 列出了許多指標，但你只需要專注於這三個「核心戰犯」：
- LCP (Largest Contentful Paint)：最大內容繪製。
簡單說，就是使用者「看到主要內容」要多久。Google 建議在 2.5 秒 內。這通常取決於你的 Hero Image 或 H1標題載入速度。 - CLS (Cumulative Layout Shift)：累積版面配置位移。
這是衡量「視覺穩定性」。如果你看過那種圖片載入後把文字往下擠的網頁，那就是 CLS 太高。Google 建議小於 0.1。 - INP (Interaction to Next Paint)：互動到下次繪製。
衡量網頁對使用者點擊的反應速度，建議小於 200 毫秒。
搞懂了這三個，接下來的優化才有針對性。我們用一張表來總結這三個指標的健康標準：
| 指標 | 縮寫 | 全名 | 綠燈 (良好) | 黃燈 (需要改善) | 紅燈 (差) |
|---|---|---|---|---|---|
| LCP | Largest Contentful Paint | 最大內容繪製 | < 2.5 秒 | 2.5 - 4.0 秒 | > 4.0 秒 |
| INP | Interaction to Next Paint | 互動到下次繪製 | < 200 毫秒 | 200 - 500 毫秒 | > 500 毫秒 |
| CLS | Cumulative Layout Shift | 累積版面配置位移 | < 0.1 | 0.1 - 0.25 | > 0.25 |
補充：CLS 是怎麼算出來的？
CLS 的分數計算其實有個明確的數學公式，它是由「影響分數」與「距離分數」相乘而得：
\[ CLS = \text{Impact Fraction} \times \text{Distance Fraction} \]其中：
- Impact Fraction (影響分數)：不穩定元素佔總視窗面積的比例。
- Distance Fraction (距離分數)：不穩定元素移動距離佔總視窗高度的比例。
這解釋了為什麼即使是很小的位移（Distance 小），如果是很大的區塊在動（Impact 大），或者位移距離很長（Distance 大），都會導致分數暴增。
二、視覺減肥：解決 LCP 的頭號殺手
圖片通常是網頁中最肥大的資源，也是造成 LCP 分數低落的主因。優化圖片是 CP 值最高的手段。
換掉老舊格式
請放棄傳統的 JPG 和 PNG。全面改用 WebP 或 AVIF。
這些現代格式在相同畫質下，體積往往能減少 30% 到 50%。這對手機用戶來說是巨大的差別。
| 格式 | 優點 | 缺點 | 建議場景 |
|---|---|---|---|
| JPG | 相容性 100% | 不支援透明、壓縮品質遞減快 | 不建議使用 |
| PNG | 無失真、支援透明 | 體積極大 | 僅限 Logo 或線條圖 |
| WebP | 體積小、兼具 JPG/PNG 優點 | 舊版 Safari (iOS < 14) 不支援 | 通用標準格式 |
| AVIF | 壓縮率最高 (贏 WebP) | 編碼慢、部分老舊瀏覽器不支援 | 極致優化首選 |
為了幫助你判斷何時該做什麼處理，這裡有一張「圖片優化決策樹」：
讓瀏覽器選圖片 (Responsive Images)
不要給手機用戶看 4K 大圖。使用 srcset 和 sizes 屬性，列出不同尺寸的圖片候選清單。
<img srcset="photo-320w.jpg 320w, photo-800w.jpg 800w"
sizes="(max-width: 320px) 280px, 800px"
src="photo-800w.jpg" alt="...">這樣瀏覽器就會根據當前螢幕寬度，自己決定下載哪一張，節省寶貴的頻寬。
下載順序的藝術：預載 vs 懶加載
這是最常被搞混的觀念，請務必記住這個原則：
- 首屏圖片 (LCP)：要預載 (Preload)。使用
<link rel="preload">並設定fetchpriority="high"，告訴瀏覽器：「這張圖最重要，別管其他的一先下載它！」 - 非首屏圖片：要懶加載 (Lazy Load)。加上
loading="lazy"，讓使用者捲動到附近時才下載。
三、視覺穩定：如何消除版面跳動 (CLS)
CLS 分數差，通常是因為瀏覽器「不知道這個元素有多大」，所以先渲染了文字，等圖片下載完後硬把文字擠開。
明確指定寬高
這是最簡單也最有效的解法。為所有的 <img>、<iframe> 和影片標籤明確寫上 width 和 height。
<img src="cat.webp" width="800" height="600" alt="Cute Cat">這就像去餐廳先訂位一樣，瀏覽器會先預留 800x600 的空白空間，圖片載入時直接填進去，版面就不會跳動了。
別讓字體閃爍 (FOIT)
字體下載慢的時候，文字會隱形，這叫 FOIT (Flash of Invisible Text)。
解法是在 CSS 的 @font-face 裡加上：
font-display: swap;這告訴瀏覽器：「如果字體還沒來，先用系統預設字體頂著，別讓文字開天窗。」雖然會有一瞬間的字體切換，但使用者能隨時看到內容，體驗會好很多。
四、底層加速：程式碼與基礎建設
搞定圖片和版面後，最後一步是優化傳輸效率。
JS 與 CSS 的載入策略
- Inline Critical CSS：把首屏會用到的關鍵 CSS 直接寫在 HTML 的
<style>裡，省去一次 HTTP 請求，讓畫面瞬間渲染。 - Defer JS：除非必要，所有的
<script>都應該加上defer。這能確保 HTML 解析完畢後才執行 JS，避免阻塞畫面的產生。 - Purge CSS：在打包時自動剔除沒用到的 CSS Class，保持檔案輕量。
我們來看看瀏覽器是如何處理網頁渲染的，以及為什麼 defer 這麼重要：
從上圖可以清楚看到，使用 defer 後，畫面渲染 (LCP) 的時間點大幅提前，因為它不再需要等待 JS 下載與執行。
基礎建設 (CDN & Caching)
- 使用 CDN：讓使用者從離他最近的伺服器抓取圖片和檔案，大幅降低延遲。
- 開啟 Gzip/Brotli：在伺服器端開啟壓縮，文字型檔案 (HTML/CSS/JS) 通常能壓縮到原本的 30%。
結語與推薦工具
PageSpeed 的優化不是一次性的工作，而是一個持續的過程。如果你想檢查優化成果，這裡有幾個必備工具：
- PageSpeed Insights：Google 官方權威報告。
- Web Vitals Extension：在 Chrome 即時查看三大指標。
- Cloudflare：如果不想動程式碼，Cloudflare 的自動優化功能可以幫你解決大部分圖片和 CDN 問題。
建議先從 「圖片轉 WebP」 和 「固定圖片寬高」 這兩點做起，這通常能帶來最有感的分數提升。
如果你能落實上述 80% 的技巧，你的網頁在 PageSpeed Insights 拿 90 分以上絕對不是夢想！
訂閱我的 Newsletter
想要更多實用技巧？訂閱我的 Newsletter，每週收到可立即應用的網頁開發方法與工具，讓你持續進步，打造更高效的數位體驗。
參考資料
- Google Web.dev: Web Vitals - Google 官方對於核心網頁指標的定義與說明。
- MDN Web Docs: Image optimization - Mozilla 開發者社群提供的圖片優化指南。
- PageSpeed Insights: About PageSpeed Insights - 關於評分系統的詳細解釋。
- Simon Arneaud: Calculating Cumulative Layout Shift - 深入探討 CLS 的數學模型。
