很多公司的官網，真正拖慢速度的不是程式寫得差，而是圖片。相機直出的照片一張動輒 5MB 以上，行銷同事做好的 banner 匯出成 PNG 又是 3MB，一個首頁十幾張圖疊上去，手機用 4G 開進來要等三、四秒才看到東西。訪客不會知道是圖片的問題，他只知道「這網站好慢」，然後按上一頁。
圖片最佳化是官網少數「投入很小、回報很直接」的工程：不用改版、不用重寫，把格式、尺寸、載入方式三件事設對，首頁重量常常可以從 8MB 掉到 1MB 以下，而且肉眼看不出差別。這篇把實際該怎麼做寫清楚。
Photo by Markus Spiske on Unsplash
一、先搞懂你在跟什麼數字賽跑
Google 用 Core Web Vitals 衡量使用者體驗，其中最吃圖片的是 LCP（Largest Contentful Paint，最大內容繪製）——也就是畫面上「最大那塊東西」多久才顯示出來。對絕大多數官網來說，那塊東西就是首頁主視覺那張大圖。Google 建議的門檻是 2.5 秒內，超過 4 秒算差。
要知道自己現在幾分，用 PageSpeed Insights（pagespeed.web.dev）輸入網址就有，記得看「行動裝置」那一頁而不是電腦版，因為多數訪客是手機進來的，而手機的網路與處理器都比桌機吃力。報告下方的「機會」區塊通常會直接點名哪幾張圖最肥、可以省下幾 KB，那就是你的待辦清單。
Photo by Nick Fewings on Unsplash
二、尺寸：不要讓瀏覽器幫你縮圖
最常見的浪費是「上傳 4000px 寬的原圖，放在版面上 600px 寬的位置」。瀏覽器會照原圖下載完整的 4000px，再縮小顯示給你看——頻寬全花在看不到的畫素上。
實務上的尺寸基準可以這樣抓：
- 全幅主視覺／banner：寬度 1920px 就夠，不需要 3000px 以上
- 內文插圖、三欄卡片：寬度 800–1200px
- 商品列表縮圖：寬度 400–600px
- Logo、icon：用 SVG，向量放大不失真，檔案通常只有幾 KB
進階一點的做法是讓同一張圖準備多個尺寸，由瀏覽器自己挑。HTML 原生就支援：
<img src="hero-1200.webp"
srcset="hero-600.webp 600w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="(max-width: 768px) 100vw, 1200px"
alt="產線實景" width="1200" height="675" />這段的意思是：手機抓 600px 那張、桌機抓 1200px 或 1920px。手機訪客因此只下載原本三分之一的資料量。多數 CMS 與前端框架有內建的圖片元件會自動產生這段，不必手刻，但要確認它真的有開。
另外注意最後那個 width 與 height。寫上去不是為了控制大小（大小交給 CSS），而是讓瀏覽器在圖還沒載完時就先把位置留好，避免圖一載完整個版面往下跳。那個跳動也是 Core Web Vitals 的扣分項目（CLS）。
三、格式：WebP 與 AVIF 才是現在的預設
JPEG 和 PNG 是三十年前的規格。同樣的畫質，WebP 大約比 JPEG 小 25–35%，AVIF 更兇，常見可以再小一半。瀏覽器支援度在 2026 年已經不是問題——WebP 幾乎全支援，AVIF 在主流瀏覽器也都進來了。
選擇邏輯可以簡化成三條：
- 照片：優先 AVIF，退一步用 WebP，品質設 75–80 通常是肉眼無感的甜蜜點
- 需要透明背景的圖：WebP 支援透明，直接取代 PNG
- 線條、圖標、簡單圖形：SVG，不要用點陣圖
如果擔心少數舊裝置看不到，用 <picture> 做漸進式降級：
<picture>
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="工廠外觀" width="1200" height="800">
</picture>瀏覽器會從上往下挑第一個看得懂的格式，看不懂 AVIF 就退 WebP，再不行才用 JPEG。
轉檔工具不必花錢：Squoosh（squoosh.app）可以在瀏覽器裡拖進去轉，左右兩邊即時比對畫質；量大就用 ImageMagick 或 sharp 寫個批次腳本跑一輪。真正該做的是把轉檔塞進流程——例如在 CMS 上傳時自動轉，而不是每次都靠人記得。這一點很關鍵，因為只要依賴人工，半年後一定又開始出現 5MB 的 PNG。
Photo by Abhinav Kumar on Unsplash
四、載入時機：該偷懶的偷懶，該搶先的搶先
不是所有圖都要立刻載。使用者剛進頁面只看得到第一個畫面，底下的圖可以等他滑下去再載。HTML 內建一個屬性就能做到：
<img src="section-3.webp" loading="lazy" alt="…" />但有個很多人踩的坑：首頁主視覺那張大圖千萬不要加 lazy。它正是 LCP 要量的對象，加了 lazy 等於叫瀏覽器晚點再處理，分數反而更差。正確做法是對它反向加速：
<img src="hero.avif" fetchpriority="high" alt="…" />簡單記法——第一屏的圖用 fetchpriority="high"，第一屏以下全部 loading="lazy"。
還有一個容易忽略的來源：輪播 banner。很多官網首頁放五張輪播圖，結果五張一次全載完，使用者卻只看到第一張。輪播的第二張之後應該延後載入，光這一項常常就省掉好幾 MB。
五、alt 文字：這是 SEO，也是法規
圖片的 alt 屬性有三個作用：圖沒載出來時顯示替代文字、螢幕閱讀器念給視障使用者聽、以及讓搜尋引擎理解這張圖的內容。Google 圖片搜尋帶來的流量在部分產業（家具、服飾、建材、食品）相當可觀，而它判斷圖片主題的主要依據就是 alt 與周圍的文字。
寫法上有幾個原則：
- 描述畫面，不要塞關鍵字。「不鏽鋼工作桌側面，桌面有排水溝槽設計」比「工作桌 不鏽鋼 工作桌推薦 工作桌價格」好得多，後者還可能被判定為操弄
- 長度抓 10–30 個字，講清楚是什麼就好
- 純裝飾的圖片留空：寫
alt=""，螢幕閱讀器會跳過。留空是正確做法，漏掉屬性不是 - 檔名也算：
stainless-worktable-drain.webp比IMG_4821.jpg有用
順帶一提，台灣的無障礙網頁規範（依 WCAG 2.1 制定）對政府與公部門委外網站有明確要求，圖片替代文字是基本項。如果公司有接政府標案的打算，這部分現在補起來比驗收前才補輕鬆很多。
六、一個下午能跑完的檢查清單
不必大改版，照這個順序走一輪就會有感：
- 用 PageSpeed Insights 跑首頁與一個主要內頁，記下現在的行動版分數與 LCP 秒數，當作對照基準
- 在瀏覽器開發者工具的 Network 分頁篩選 Img，依大小排序，揪出前十大肥圖
- 把這十張縮到合理尺寸、轉成 WebP 或 AVIF，重新上傳
- 檢查所有
<img>：第一屏加fetchpriority="high"，其餘加loading="lazy" - 補上
width與height，解掉版面跳動 - 把缺少的 alt 補齊，裝飾性圖片明確寫
alt="" - 在 CMS 或建置流程加上自動轉檔，讓下一位同事上傳時不必再記這些規則
- 一週後再跑一次 PageSpeed Insights，和第 1 步的數字對照
結語：這是維護問題，不是專案問題
圖片最佳化的麻煩不在技術，在於它會回彈。今天花一個下午把全站圖片壓好，三個月後行銷換了活動 banner、業務補了十張產品照，官網又重回原點。所以真正要做的決定只有一個：把轉檔與尺寸限制放進上傳流程，讓系統自動處理，而不是寫在交接文件裡期待大家遵守。
如果你的官網目前行動版 LCP 超過 4 秒，先別急著討論改版或換主機——很可能只是幾張沒壓縮的照片。從最肥的那十張開始，成本最低、效果最明顯。