網站速度優化實戰：圖片 WebP／AVIF、延遲載入與快取設定一次搞懂

很多老闆第一次打開自家官網的 PageSpeed Insights 報告，看到一片紅字就頭痛：「網站速度優化到底要從哪裡改？」其實多數中小企業官網的速度問題，並不是主機不夠貴，而是首頁放了好幾張直接從相機匯出的 5MB 大圖、所有圖片一次載入、每次造訪都重新下載同樣的檔案。

這篇文章不談艱深的程式碼重構，而是聚焦在投資報酬率最高的三件事：圖片格式與尺寸、延遲載入、快取設定，並說明怎麼避免「越優化越慢」的常見錯誤。內容整理自 web.dev、MDN 與 Nielsen Norman Group 的公開資料，再加上我們實際替台灣企業改版時的經驗。

為什麼速度會影響詢價與排名？

Nielsen Norman Group 創辦人 Jakob Nielsen 很早就提出使用者對回應時間的三個界線：0.1 秒會讓人覺得是即時反應；1 秒內使用者的思緒不會被打斷，但已經感覺到延遲；超過 10 秒，使用者就很難繼續專注在任務上。換句話說，訪客點進你的服務頁，如果主要內容遲遲出不來，他的注意力很可能就轉回 LINE 或其他競爭對手的分頁了。

在搜尋排名方面，Google Search Central 的「網頁體驗」說明明確寫到 Core Web Vitals 會被排名系統使用，但同時提醒：分數好看不保證排名就會在最前面。所以速度優化的定位很清楚——它是讓好內容不被扣分的基本功，而不是取代內容的捷徑。關於三項指標的完整說明，可以參考我們的 Core Web Vitals 改善指南。

先找出瓶頸：主圖就是最大的嫌疑犯

web.dev 的〈Optimizing Largest Contentful Paint〉把 LCP（最大內容繪製）時間拆成四段：

LCP 的建議門檻是 2.5 秒以內（以 75% 的造訪為準）。對大多數形象官網而言，LCP 元素就是首屏那張大橫幅或主視覺照片，所以從這張圖下手，往往最快看到成效。

圖片優化第一步：選對格式、給對尺寸

WebP 與 AVIF 差在哪？

依 MDN 的圖片格式指南：

• WebP：有損壓縮通常比同畫質 JPEG 小 25–35%，目前主流瀏覽器的最新版本都支援，是相容性與檔案大小之間最穩的選擇。
• AVIF：壓縮效率更好，MDN 引用的資料顯示相較 JPEG 的中位數節省約 50%；Chrome、Edge、Firefox、Safari 的新版本都已支援，但 MDN 提醒舊版瀏覽器的支援度仍不夠全面，且 AVIF 不支援漸進式顯示，建議準備替代格式。

實務上最保險的做法，是用 picture 元素依序提供 AVIF、WebP，最後再以 JPEG 或 PNG 當作後援，瀏覽器會自動挑它支援的第一個格式。很多 CMS 與圖片 CDN 也能自動完成這件事，不一定要手寫。

尺寸比格式更重要

把 4000 像素寬的照片縮在 400 像素的卡片裡，就算轉成 AVIF 也是浪費。建議：

1. 依照版面實際顯示寬度，輸出 2–3 種尺寸（例如手機、平板、桌機各一）
2. 用 srcset 讓瀏覽器依螢幕挑選
3. 每張 img 都寫上 width 與 height，先保留空間，避免圖片載入後把文字往下推（這正是 CLS 的主要成因之一）

延遲載入：用對地方才會變快

瀏覽器原生的 loading="lazy" 已被 Chrome、Edge、Firefox、Safari 支援，不支援的瀏覽器會直接忽略，沒有副作用。它會讓畫面外的圖片等使用者捲動接近時才下載，對長頁面、作品集、部落格列表特別有效。

但 web.dev 特別警告：首屏可見的圖片，尤其是 LCP 主圖，不要延遲載入。 我們看過不少網站外掛「一鍵全站延遲載入」，結果連首頁橫幅都被延後，LCP 反而變差。正確做法是：

• 首屏主圖：保持預設載入，並加上 fetchpriority="high"，只給 1–2 張最重要的圖
• 主圖若寫在 CSS 背景，改成 HTML 的 img，或用 link rel="preload" 讓瀏覽器提早發現
• 首屏以下的圖片、嵌入的 YouTube 與 Google 地圖 iframe：使用延遲載入

快取設定：讓回訪者幾乎不用重新下載

web.dev 的〈HTTP Cache〉一文給了一個很實用的分法：

• 檔名帶版本號或雜湊的靜態檔（例如 style.a1b2c3.css）：內容永遠不會變，可以設定 Cache-Control: max-age=31536000（一年），瀏覽器直接用本機快取
• HTML 頁面這類網址固定的檔案：不適合長時間快取，重點是讓重新驗證變快，可搭配 no-cache（注意：它的意思是「每次使用前先確認」，不是「不快取」）與 ETag，內容沒變時伺服器只回 304
• 完全不該被保存的內容（例如含個資的頁面）：才使用 no-store

另外，web.dev 提醒：沒有設定 Cache-Control 並不等於不快取，瀏覽器會自己猜，結果反而難以預測。所以請明確設定。如果網站使用 Cloudflare 等 CDN，也要確認 CDN 與主機的快取規則一致，避免更新內容後訪客一直看到舊版。

其他常被忽略的拖慢因素

• 字型：中文字型檔案動輒數 MB，載入策略不當會讓文字晚出現或版面跳動，詳見網頁字體排版與配色一文
• 第三方程式碼：聊天外掛、多套追蹤碼、社群嵌入，每一個都可能拖慢互動反應，定期盤點、移除不用的
• 轉址鏈：http → https → www → 最終網址，一層層轉跳都在消耗 TTFB
• 主機位置：主要客群在台灣，主機或 CDN 節點離台灣越近越好

常見問題

網站速度優化要做到 PageSpeed Insights 100 分嗎？

不需要。實驗室分數會隨測試環境波動，真正重要的是實際使用者的 Core Web Vitals 是否達到「良好」，以及訪客是否順利找到資訊、送出詢價。與其追滿分，不如先把主圖、延遲載入與快取這些高效益項目做好。

換成 AVIF 之後，舊瀏覽器會看不到圖嗎？

只要用 picture 元素提供 WebP 與 JPEG 後援，瀏覽器會自動選擇支援的格式，不會出現破圖。若使用 WordPress 或圖片 CDN，多半也有自動依瀏覽器回傳格式的功能。

裝了快取外掛，速度還是很慢怎麼辦？

快取外掛只能解決一部分問題。如果首頁主圖本身就是好幾 MB、被錯誤延遲載入，或載入大量第三方程式碼，快取幫不上忙。建議先用 PageSpeed Insights 找出 LCP 元素，再依本文四個階段逐一排查。

結語：速度優化是持續的習慣，不是一次性工程

網站速度不是改版時做一次就結束，每次上傳新的橫幅、加一個追蹤碼，都可能讓網站變慢。建議把「上傳前先壓縮、首屏不延遲載入、靜態檔長快取」寫進內部的網站維護流程，並搭配官網維護與資安的定期檢查一起執行。完整的官網規劃流程，可以從企業官網設計完整指南開始看起。

如果你的網站架構老舊、外掛疊太多，單靠調整設定已經改善有限，網軍行銷也提供網站開發，從架構面把速度做進去。

參考資料

• web.dev，Optimizing Largest Contentful Paint：https://web.dev/articles/optimize-lcp
• web.dev，Browser-level image lazy loading for the web：https://web.dev/articles/browser-level-image-lazy-loading
• web.dev，Prevent unnecessary network requests with the HTTP Cache：https://web.dev/articles/http-cache
• MDN Web Docs，Image file type and format guide：https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types
• Nielsen Norman Group，Response Times: The 3 Important Limits：https://www.nngroup.com/articles/response-times-3-important-limits/
• Google Search Central，Understanding page experience in Google Search results：https://developers.google.com/search/docs/appearance/page-experience