同一張首頁主視覺，一個網站丟上 4MB 的原圖，另一個壓到 300KB，使用者在手機上看到的體感差距可能是「秒開」跟「等到失去耐心」。圖片優化就是這種投入不多、回收卻很明顯的項目，卻偏偏是最多網站隨便帶過的一塊。這篇我們把圖片優化拆成格式、檔案大小、尺寸標註、延遲載入、檔名與替代文字幾塊，講我們實際在做的判斷，而不是空泛的方向。這些項目乍看瑣碎，但每一項都同時牽動載入速度、使用者體驗與搜尋引擎對圖片的理解，處理得好，等於一次改善好幾個面向。我們會盡量給出可以直接照做的原則。要先建立一個觀念：圖片優化不是單一動作，而是一條流程，從挑格式、壓縮、縮圖，到標尺寸、決定載入時機、命名與替代文字，環環相扣。任何一環漏掉，整體效果都會打折，所以我們習慣把它當成一套檢查清單，而不是零散的技巧。
1. 選對格式，檔案先瘦一半
圖片優化的第一步是格式。同一張圖，用對格式跟用錯格式，檔案大小可以差上一大截，而且肉眼幾乎看不出畫質差異。這是我們每次稽核圖片時最先看的地方。
1.1 WebP 與 AVIF 該怎麼選
WebP 在相同畫質下，檔案通常比傳統的 JPEG 或 PNG 小不少，且瀏覽器支援度已經相當普及，是目前最穩妥的預設選擇。AVIF 壓縮效率又更好一些，畫質與檔案大小的平衡更漂亮，但編碼較耗時、部分舊環境支援度稍弱。我們的建議是以 WebP 為主力，對首屏那幾張最吃頻寬的關鍵大圖，再評估是否額外提供 AVIF 版本。不必為了追新格式而全站換成 AVIF，那通常得不償失，挑真正影響體感的大圖下手才划算。要補充的是，格式的選擇也要看圖的性質：色彩層次豐富的照片最能吃到 WebP 與 AVIF 的壓縮優勢，但圖示、標誌、線條這類內容，用 SVG 這種向量格式反而更小、放大也不會糊，硬把它們轉成 WebP 等於用錯工具。先依圖的類型分流，再決定要不要套用現代點陣格式，判斷會更準。
1.2 用 picture 標籤做優雅降級
為了兼顧新格式的效率與舊瀏覽器的相容，我們常用 <picture> 讓瀏覽器自己挑能吃的格式，挑不到就退回 JPEG。這樣既拿到新格式的好處，又不會讓少數舊環境的使用者看到破圖。瀏覽器會由上而下讀取來源，選第一個它支援的，所以把效率最高的 AVIF 放最前面，WebP 其次，最後留一個通用的 JPEG 當保底。
<picture>
<source srcset="/images/hero.avif" type="image/avif">
<source srcset="/images/hero.webp" type="image/webp">
<img src="/images/hero.jpg" width="1200" height="630" alt="產品應用情境示意">
</picture>1.3 一張表快速決定格式
| 圖片類型 | 建議格式 | 理由 |
|---|---|---|
| 照片、情境圖 | WebP（首屏可加 AVIF） | 壓縮效率高，畫質損失難察覺 |
| 需要透明背景的元素 | WebP | 支援透明，比 PNG 小 |
| 圖示、線條、色塊 | SVG | 向量檔小且可無限縮放 |
| 動態圖 | WebP 或影片格式 | 比傳統動圖檔案小很多 |
2. 把檔案大小控制在該有的範圍
選對格式之後，還要控制實際輸出的大小。格式決定同樣畫質下的壓縮效率，但真正決定檔案多大的，是你輸出時的尺寸與品質設定。我們看過不少網站已經轉成 WebP，但因為沒有壓縮、也沒有依顯示尺寸縮圖，單張圖還是好幾百 KB，轉格式的功效幾乎被抵銷掉。這裡有幾個我們固定會檢查的點。
2.1 內文圖控制在 200KB 以內
對一般內文圖片，我們會把單張控制在 200KB 以下作為參考線，首屏的主視覺大圖可以放寬一些，但也要盡量壓到合理範圍。超過這個量級的圖，通常是沒有依實際顯示尺寸縮圖，或壓縮品質設得太高。把品質參數調到視覺可接受的臨界，檔案往往能再少三、四成，而讀者根本看不出來。這條參考線不是鐵律，而是一個提醒你回頭檢查的門檻，超過就值得問一句為什麼。實務上我們會用瀏覽器的開發者工具，在網路面板把資源依大小排序，一眼就能看出哪幾張圖特別肥、該優先處理。與其憑感覺逐張猜，不如用這個方式鎖定真正拖慢頁面的那幾張，把力氣花在影響最大的地方。壓縮也有分有損與無損，一般照片用有損、品質抓在高檔與中檔之間，通常是檔案與畫質最划算的平衡點。
2.2 不要用超大原圖硬塞小版位
一個很常見的浪費，是版位只顯示 400 像素寬，卻載入一張 3000 像素寬的原圖，讓瀏覽器縮小顯示。使用者付了頻寬，卻看不到那些多餘像素。我們建議依照實際顯示的最大尺寸準備圖片，並用 srcset 針對不同螢幕提供不同解析度，讓裝置各取所需。手機抓小圖、桌機抓大圖，不會讓小螢幕的使用者白白下載一張用不到的巨圖。
<img src="/images/card-800.webp"
srcset="/images/card-400.webp 400w,
/images/card-800.webp 800w"
sizes="(max-width: 600px) 400px, 800px"
width="800" height="600" alt="服務流程說明圖">2.3 我在製造業客戶身上看到的落差
根據我們的服務經驗，曾接手一個工業設備產業的網站，首頁光是幾張產品照就吃掉將近 4MB。他們的圖其實已經是 WebP，問題出在每張都是直接從攝影原檔匯出、沒有依版位縮圖。我們把顯示尺寸重新裁切、品質參數調整過，同樣視覺呈現下首頁圖片總量降到原本的四分之一左右，行動裝置上的載入體感差異相當明顯。這件事沒有動到任何設計，純粹是輸出流程的調整。我們後來把這套縮圖與壓縮的規則寫進他們的上稿流程，讓行銷團隊上傳圖片時系統自動處理，就不必每次都靠工程師手動介入，長期維護也輕鬆很多。
另一個容易被忽略的細節是圖片的色彩模式與中繼資料。攝影原檔常帶有相機型號、拍攝參數、色彩描述檔等資訊，這些對網頁顯示多半用不到，卻會增加檔案體積。輸出網頁用圖時把非必要的中繼資料清掉、統一色彩模式，單張圖又能再省下一些容量。這些調整單看每一張影響有限，但整個網站累積起來，對頻寬與載入時間的貢獻並不小。
3. 標好尺寸，畫面就不會亂跳
圖片載入造成的版面位移，是使用者體驗的隱形殺手。你正要點按鈕，圖片突然載入把內容往下推，手指就按錯了。這種累積的位移會直接反映在體驗指標上，而解法其實很單純。
3.1 為每張圖標上 width 與 height
在 <img> 上明確寫出 width 與 height，瀏覽器就能在圖片還沒下載完前，先保留正確比例的空間，避免載入後內容突然跳動。這個屬性只能填純數字，不能寫成帶單位的值。我們稽核時常抓到寫成 width="80px" 的錯誤，這在嚴格解析下會被視為無效，等於白標了。這裡填的數字不必等於圖片在畫面上實際顯示的大小，填圖片本身的原始像素寬高即可，瀏覽器是靠這兩個值算出長寬比來預留空間，實際顯示尺寸交給後面的 CSS 控制。很多人誤以為要填顯示尺寸，結果在響應式版面上比例就跑掉了，這個觀念先釐清，後面的響應式處理才不會打架。
正確：<img src="/images/icon.webp" width="80" height="80" alt="聯絡我們">
錯誤：<img src="/images/icon.webp" width="80px" height="80px" alt="聯絡我們">3.2 用 CSS 維持響應式比例
標了 width 與 height 後，再用一小段 CSS 讓圖片在不同螢幕上等比縮放，就能同時拿到「不位移」與「響應式」兩個好處。關鍵是讓瀏覽器從一開始就知道長寬比，即使實際顯示尺寸會隨螢幕變動，保留的空間比例也不會跑掉。max-width: 100% 讓圖片不會超出容器、在小螢幕自動縮小，height: auto 則確保縮放時維持原比例不變形。這兩行搭配 HTML 上標好的長寬，就是兼顧穩定版面與響應式最簡單的組合，幾乎適用於所有內容圖，不需要為每張圖另外寫樣式。把它放進全站通用的樣式裡，之後新加的圖自然就會套用，省去重複設定的功夫。
img { max-width: 100%; height: auto; }4. 延遲載入與命名，把細節做到位
前面處理的是每張圖本身，這一段談的是「什麼時候載入」以及「怎麼命名」。這兩件事一個影響速度，一個影響圖片被理解的程度，都是小動作卻常被略過。它們的共通點是幾乎不花成本，只是習慣有沒有養成，卻能在速度與可被搜尋理解這兩個面向各補一塊，屬於最值得內建進日常流程的細節。
4.1 首屏之外才用 lazyload
延遲載入能讓還沒滾動到的圖片先不下載，替首屏省下頻寬。原生的做法是加上 loading="lazy"，現在主流瀏覽器都已支援，不必再為此額外載入套件。但我要特別提醒，首屏、尤其是最大的那張主視覺圖，反而不該延遲載入，否則會拖慢它出現的時間。首屏關鍵圖可以用 loading="eager" 或搭配預先載入，讓它盡早顯示。把 lazyload 一律套到所有圖片上，是很常見卻會反效果的做法。判斷的分界線很簡單：使用者一打開頁面、不滾動就會看到的圖，要盡早載入；需要往下捲才會出現的圖，才交給延遲載入。照這個原則分，既省了頻寬，又不犧牲首屏的第一印象。
首屏主圖：<img src="/images/hero.webp" loading="eager" width="1200" height="630" alt="首頁主視覺">
下方圖片：<img src="/images/section.webp" loading="lazy" width="800" height="500" alt="功能區塊說明">4.2 語意化檔名比你想的重要
檔名是搜尋引擎理解圖片的線索之一。用 seo-audit-flow.webp 這種能看出內容的英文命名，會比 img_0012.webp 或一串亂碼好得多。命名時用小寫、以連字號分隔、避免空白與大寫，維持一致風格。這件事花不了多少力氣，卻是很多網站直接忽略的免費機會。尤其在圖片搜尋的情境下，一個描述清楚的檔名，等於多給了搜尋引擎一個判斷這張圖在講什麼的依據。要注意的是，檔名的權重不高，不值得為了它去改動已經上線、已被收錄的圖片網址，那反而可能造成連結失效。比較務實的做法是在新產生圖片時就養成好的命名習慣，舊圖則順其自然，不用特地回頭改。命名的重點是自然可讀，而不是硬把一串關鍵字用連字號串起來。
4.3 alt 要自然描述，不是塞關鍵字
替代文字讓搜尋引擎理解圖片內容，也讓使用螢幕閱讀器的訪客知道畫面上是什麼。好的 alt 是自然的一句描述，例如「工程師檢視伺服器機櫃的照片」，而不是堆疊一串關鍵字。純裝飾用、不承載資訊的圖片，可以留成 alt=""，讓輔助技術略過它。要注意的是 alt="" 和完全不寫 alt 屬性是兩回事：留空字串是明確告訴螢幕閱讀器「這張圖可以跳過」，完全不寫則會讓部分輔助技術去念出檔名，反而造成干擾，所以裝飾圖要寫成空字串而不是省略。我們看過不少網站把 alt 當成關鍵字倉庫，一張圖塞進七八個商業詞，這種寫法對排名沒有幫助，還可能被判定為濫用，同時讓依賴螢幕閱讀器的使用者聽到一長串沒有意義的字詞。描述時想像你要用一句話告訴看不到畫面的人這張圖在講什麼，通常就會寫得剛剛好。下表是我們常用的對照。
| 情況 | 建議寫法 |
|---|---|
| 承載資訊的內容圖 | 自然描述圖片主題，如「網站結構稽核示意圖」 |
| 純裝飾、無資訊的圖 | 留成 alt=””，讓螢幕閱讀器略過 |
| 兼具連結功能的圖 | 描述連結目的地，而非只描述外觀 |
| 堆疊關鍵字 | 避免，可能被判定為濫用 |
5. 圖片優化最常見的三個誤區
講完該怎麼做，這一段反過來談三個我們反覆遇到的誤區。它們的共同點是都「看起來有在優化」，實際上卻沒抓到重點，甚至幫了倒忙。
5.1 以為轉成 WebP 就等於優化完成
最常見的一種，是把全站圖片批次轉成 WebP 就認為大功告成。轉格式確實有幫助，但如果轉完之後既沒壓縮、也沒依顯示尺寸縮圖，單張圖還是可能有好幾百 KB。格式、壓縮、縮圖是三件獨立的事，只做其中一件，省下來的容量很有限。我們的經驗是，真正讓檔案瘦下來的關鍵往往是縮圖到實際顯示尺寸，而不是格式本身。把三件事當成一套流程一起做，效果才會明顯。
5.2 只看單張圖，忽略整頁的圖片總量
第二個誤區是盯著單張圖看，覺得每張都不算太大就放心了。但使用者感受到的是整頁一次要載入多少。一頁如果有二十張各 150KB 的圖，加起來就是 3MB，體感一樣很重。評估時要把整頁的圖片總量、數量一起算進來，必要時用延遲載入讓首屏之外的圖晚點再下載，而不是只逐張檢查。頁面的圖越多，越該認真分配哪些需要一開始就載入、哪些可以等使用者滾動到再說。像商品列表、相簿這種圖片密集的版型最容易踩到這個坑，單張看都合格，整頁卻重得嚇人。遇到這種頁面，除了延遲載入，也可以考慮縮圖列表只放小尺寸預覽、點開才載入大圖，讓第一次進頁面的負擔降到最低。
5.3 為了 SEO 在 alt 和檔名塞滿關鍵字
第三個是把 alt 與檔名當成塞關鍵字的欄位。一張圖的 alt 塞進七八個商業詞、檔名堆滿關鍵字，不只對排名沒有幫助，還可能被判定為濫用，更會讓依賴螢幕閱讀器的使用者聽到一長串沒有意義的字詞。alt 與檔名的首要任務是如實描述圖片內容，讓機器與使用輔助工具的人都能理解，關鍵字只是在自然描述中順帶出現，而不是硬塞的主角。把它們寫得像給人看的說明，通常就剛剛好。
6. 常見問題
6.1 全站圖片都換成 AVIF 是不是最好
不一定。AVIF 壓縮效率確實出色，但編碼較慢、部分環境支援度稍弱。比較穩健的做法是以 WebP 為主，對首屏最吃頻寬的少數關鍵圖再額外提供 AVIF，用 <picture> 讓瀏覽器自行選擇。全站一律換成 AVIF 的效益，通常不如把力氣花在壓縮與縮圖上。換句話說，對多數網站來說，把圖確實縮到顯示尺寸、設好合理的壓縮品質，帶來的檔案縮減往往比糾結格式更大，這才是該先投入的地方。
6.2 只要圖片壓夠小，還需要標 width 和 height 嗎
需要。檔案大小影響的是載入快慢，而 width 與 height 解決的是版面位移。即使圖很小，沒標尺寸一樣會在載入時推動版面，造成使用者點錯。這兩件事要分開處理，壓縮不能取代標尺寸。換個說法，壓縮管的是「多快載完」，標尺寸管的是「載入過程中版面穩不穩」，兩個問題的成因不同，自然要用不同的方法各別解決。
6.3 把所有圖片都加上 loading=”lazy” 可以嗎
不建議一律套用。首屏、特別是最大的主視覺圖延遲載入，會拖慢它出現的時間，反而傷害首屏體感。延遲載入應該用在需要滾動才會看到的圖片上，首屏關鍵圖要讓它盡早載入。簡單的判斷是：打開頁面不捲動就看得到的圖不要延遲，其餘的才套用。
6.4 裝飾性圖片的 alt 要寫什麼
留成空字串 alt="" 即可。這會告訴輔助技術這張圖不承載資訊、可以略過。若硬要為純裝飾圖塞入描述，反而會干擾使用螢幕閱讀器的訪客，聽到一堆與內容無關的字詞。
6.5 圖片檔名用中文可以嗎
技術上可行，但我傾向用語意化的小寫英文加連字號，跨系統與網址編碼時比較不會出問題，維護上也較一致。重點是能看出內容、風格統一，避免空白與大寫。中文檔名在某些伺服器或分享情境下容易被轉成一長串編碼，反而失去可讀性，也可能在複製網址時出現亂碼，增加溝通與除錯的麻煩。
6.6 已經上線的舊圖沒優化，值得回頭處理嗎
視流量而定。不過以投報率來說，建立好的上傳流程通常比回頭修舊圖更值得先做，因為它能讓往後所有新圖都自動合規，不必再一次次補救。我會優先處理流量高的頁面與首屏圖片，那裡的改善最有感。長尾的舊圖可以排在後面，或在下次改版時一併調整輸出流程，讓新產生的圖自動符合規範。與其一次全部重做，不如從影響最大的地方開始，逐步把規則內建到上稿流程裡。判斷要不要回頭處理時，可以先看效能工具點出哪些頁面的最大內容繪製被圖片拖慢，那些就是最值得優先動手的對象，改完的體感與指標回饋都最直接。把有限的時間投在這些地方，比平均地把每張舊圖都重壓一遍更有效率。