多數網站主管一看到 PageSpeed 或 Lighthouse 報告裡「提供新一代格式圖片」那項紅字，直覺反應是把整個媒體庫拉出來，一張一張轉成 WebP 或 AVIF。但真正該問的問題，從來不是「該不該換格式」，而是「哪些圖片才值得換」。把幾百張、幾千張舊圖全部重新轉檔，是一次性的高成本工程：要找出每張圖片實際被哪個頁面引用，確認轉檔後畫質沒有肉眼可辨的落差，還要處理舊瀏覽器的相容問題，一步都省不了；換來的往往只是那項稽核從紅字變綠字，排名不會因此跟著往上跳。
WebP 與 AVIF 是目前主流瀏覽器都支援的新一代圖片格式，核心賣點是同樣畫質下檔案更小，理論上能讓頁面載入更快。這個「檔案變小」到「排名變好」之間，其實隔著好幾層因果。網頁體驗相關的指標裡，真正被 Google 排名系統直接採計的只有 Core Web Vitals，圖片格式從來不是獨立的加分項。搞懂這條因果鏈，才知道力氣該花在哪：從現在起新上傳的圖片，直接存成新格式，幾乎沒有額外成本；舊圖庫要不要跟著全部重做，答案要看這張圖在不在關鍵頁面的關鍵位置，不是看格式本身夠不夠新。
新圖片直接上新格式，舊圖不必為了分數整批重做
對「該不該把整站舊圖庫重新轉檔成 WebP 或 AVIF」這個問題，答案其實要分兩塊看，不是全有或全無。既有的圖片庫，多半不值得為了 PageSpeed 分數整批重做，那是一次性的高成本工程，要逐張核對頁面引用、確認畫質沒有明顯落差、處理舊瀏覽器的備用方案，投入的工時跟換來的分數提升不成比例。至於新上傳的圖片，情況完全相反。從現在起直接存成新格式，幾乎不會多花額外成本，反正每張圖都要存一份檔案，差別只在選哪一種格式，卻能持續累積效益，越晚換，要補的舊圖只會越多。
這兩個決定之所以答案不同，其實跟成本結構有關。轉檔舊圖是「一次做完一大批」的工程型成本，而且每張圖都得個別確認畫質與引用位置；新圖直接存新格式則是「順手就做」的習慣型成本，幾乎不用額外投入。同一件事，擺在不同的成本結構下，划不划算的答案自然不一樣。
這個判斷不是憑感覺，Google 自己怎麼看待圖片格式在排名裡的角色，答案其實寫得很清楚。
Google 官方排名系統不會用圖片格式本身當排名訊號
很多人聽過「網站速度會影響 SEO」，順勢就把這句話延伸成「圖片格式換得越新，分數推得越高，排名也會跟著往上」，這中間其實藏了一個因果誤解。
Google 官方在說明搜尋排名系統怎麼考量網頁體驗時，講得很明確。真正被排名系統直接採計的網頁體驗訊號，只有 Core Web Vitals 這一項；而且 Google 特別補充，如果只是為了 SEO，去把 Core Web Vitals 報告或第三方工具的分數衝到滿分，未必是值得花時間的做法。分數是設計來幫網站主評估自家使用者體驗，不是排名的直接依據。
圖片格式在這條因果鏈裡扮演的角色其實是間接的。格式選得好，檔案通常會變小，檔案變小才有機會讓最大內容繪製（LCP，Core Web Vitals 三項指標之一）的時間縮短，Core Web Vitals 才是真正被排名系統採計的那一關。格式本身不是獨立於 LCP 之外的另一個加分項，跳過中間這一步，直接把換格式當成加分，就是誤解的起點。
2024 年，Google 搜尋開始支援 AVIF 格式的圖片索引。公告交代的重點是，改用 AVIF 不需要為了讓 Google 讀懂而做任何特殊處理，圖片一樣能被正常索引；同一篇公告還提醒，不建議盲目對整站圖片做大規模更換，應先花時間評估哪種格式適合自己的需求。公告全文沒有出現「排名」或「加分」這類字眼，這也佐證了格式本身從來不是一個獨立的排名訊號，能不能被索引，跟能不能帶來排名加分，是兩件不相干的事。
WebP 比 JPEG、PNG 省下的實測位元組
換算成實際數字，WebP 能省下的位元組相當明確。Google 官方維護的 WebP 頁面實測，有損壓縮比同等視覺品質的 JPEG 小 25% 到 34%，無損壓縮比同等的 PNG 小 26%，MDN 技術文件給出的區間也幾乎一致。加上 WebP 同時支援透明背景與動畫，一款格式就能接手 JPEG、PNG、GIF 三種舊格式的使用情境，新圖片直接存成 WebP，不必再為「這張圖該用哪種舊格式」多做取捨，也不會少功能。
AVIF 更高壓縮率背後多付出的運算成本
AVIF 的壓縮率比 WebP 再往前推一截，web.dev 指出相較 JPEG 實測可省下超過 50%（實際幅度依圖片內容與編碼設定而定），圖片 CDN 業者 Imgix 的實測則是比 WebP 再省 35%。但省下的位元組是拿運算成本換來的，web.dev 提到編碼器 libaom 光是從 2.0.0 版到 3.1.0 版，就把 CPU 使用量降低 6.5 倍，反過來正好說明 AVIF 編碼原本有多吃資源；官方建議用圖片 CDN 自動化整套轉檔流程，也坦言費用可能讓部分專案無法負擔。放到舊圖遷移這件事上，沒有 CDN 幫忙自動處理時，靠人力把整站舊圖批次轉成 AVIF，要花的運算時間與人力比轉 WebP 高出不少。
兩種新格式的支援落差已縮到舊版本與少數瀏覽器
以今天的瀏覽器來看，WebP 與 AVIF 在主流瀏覽器的最新版本都已經完整支援。依 W3C WebDX 社群群組制定的 Baseline 指標（Google 的 Web Platform Status 網站可以查），AVIF 在 2024 年 1 月成為「新近可用」，2026 年 7 月進入「廣泛可用」；WebP 則早在 2023 年 3 月就達到廣泛可用。Can I Use 統計的全球可用比例，AVIF 約 95%、WebP 約 97%（2026 年 9 月資料），相容性已經不是兩者在最新版瀏覽器上的主要差別。
落差留在兩個地方。第一個是舊版本，同一款瀏覽器達到完整支援的時間點差了好幾年：Edge 瀏覽器第 18 版、也就是 2018 年前後就完整支援 WebP，要到第 121 版、2024 年初才完整支援 AVIF，中間隔了 5 年多；Firefox 的 WebP 從第 65 版開始完整支援，AVIF 在第 77 版到 92 版之間都還維持預設關閉，到第 93 版才正式開啟；Safari 的 WebP 從 16.0 版起完整支援，AVIF 則是 16.4 版才完整支援，中間 16.1 到 16.3 只有部分支援。還停在這些舊版本的裝置，就吃不到 AVIF。
第二個是少數瀏覽器。KaiOS（常見於功能陽春的行動網路手機的作業系統）第 3 版就支援 WebP，但目前的版本都不支援 AVIF；Opera Mini 這種主打省流量、常見於網路條件較差地區的瀏覽器，所有版本都支援 WebP，AVIF 則完全不支援。這些使用者佔比不高，但也代表 AVIF 仍然需要一份備用格式，WebP 的覆蓋面則再廣一點。
讓瀏覽器從多種格式裡挑自己支援的那一份
上一節的支援落差，答案不是二選一、犧牲一邊使用者，而是讓瀏覽器自己挑。Google 在圖片 SEO 最佳做法頁面裡建議，用 <picture> 元素包住同一張圖的多個 <source> 版本，並且一定要用帶 src 的 <img> 當備用。套用到新格式，就是依序放 AVIF、WebP，最後用 <img src> 放最保守的 JPEG 或 PNG。瀏覽器會挑它支援的第一個格式，都不支援才退回 <img> 裡的備用圖，也就是 Google 所形容的「內建優雅降級」。
這個機制其實把「該不該全面遷移」這個問題本身變得不必要，不是整站統一改成同一種格式，是每張圖各自準備需要的版本。不用因為 Edge 舊版本不支援 AVIF，就整站放棄 AVIF；也不用因為 KaiOS 不支援 AVIF，就連 WebP 都不敢上。呼應前面「舊圖不必整批重做」的立場，如果某張舊圖本來就只有一份舊格式檔案，維持現狀完全沒問題，不需要為了相容性倒過來強迫自己轉檔；只有真的要做新圖，或是網頁裡真正吃重的關鍵圖片，才需要花力氣準備多格式版本。
舊圖裡的 LCP 候選圖，是值得反過來優先處理的例外
前面提到「舊圖不必整批重做」，但有一種情況要反過來優先處理：某張舊圖如果剛好是網頁的 LCP 元素，像首頁主視覺、產品主圖，這張圖的格式選擇會直接影響 Core Web Vitals 的實測分數，不是無差別地放著不管就好。web.dev 官方文章明講，圖片通常是 LCP 指標的常見候選項目，並直接建議在 LCP 候選項目是圖片的情況下，可以嘗試改用 AVIF 來改善網站的 LCP 時間。這句建議本身就是針對性的，是針對 LCP 候選圖，不是要整站圖片比照辦理。
HTTP Archive 這份國際研究機構的年度大規模調查數字，剛好佐證了現況有多落後。2025 年，桌面版網頁的 LCP 圖片裡仍有 57% 是 JPG、26% 是 PNG，WebP 只佔 11%（比 2024 年的 7% 成長，但仍是少數），AVIF 更是只佔 0.7%。HTTP Archive 給出的解讀是，這種緩慢的採用可能反映了遷移既有圖片管線與內容庫的成本，即使新格式已經有廣泛的瀏覽器支援。這句話同時印證了前面的兩個立場：多數網站確實還沒做全面遷移，但連最該優先處理的 LCP 圖片，都還大量停留在舊格式。
實務上要抓出這個例外，不必用猜的。先用 PageSpeed Insights 或 Lighthouse 檢查頁面的 LCP 元素是不是圖片，是的話，優先幫這一張圖準備 WebP 或 AVIF 版本，搭配上一節提到的 <picture> 備用機制；其餘的舊圖，維持原狀就好。
多數 AVIF 檔要下載完才顯示，大張首屏圖要多想一步
AVIF 還有一個容易被忽略的顯示特性。傳統的漸進式 JPEG 可以邊下載邊顯示，讀者會先看到一張模糊的輪廓，隨著下載進度逐漸變清晰；一般的 AVIF 檔沒有這個機制，MDN 的說明是檔案必須完整下載後才能顯示，在圖片完成前，讀者看到的只會是一片空白。
AVIF 規格本身其實有留漸進式的路。開放媒體聯盟（Alliance for Open Media）制定的 AVIF 規格，支援用分層影像做漸進式解碼，web.dev 也提到 AVIF 可以做解析度逐步提升、畫質逐步提升兩種漸進方式。但分層檔要在編碼時刻意產生，例如開放媒體聯盟的參考編碼器 libavif，要另外加上 --progressive 參數才會輸出這種檔案，預設產出的仍是單層檔。所以兩種說法都成立，格式能做到漸進式解碼，只是網站上常見的 AVIF 檔多半不是這樣編出來的。
MDN 對這個特性的解讀是，多數情況下影響不大，因為 AVIF 檔案本身就比同品質的 JPEG 或 PNG 小很多，下載本來就快，空白的時間也就短；但檔案本身比較大時，這個影響就會變得明顯，這種情況應該考慮改用支援漸進式渲染的格式。放回舊圖要不要轉的判斷，面向網路條件較差地區的受眾、檔案又偏大的首屏大圖，維持漸進式 JPEG，或先確認自己的轉檔工具能輸出分層的 AVIF，會是比較穩妥的預設。AVIF 適合用在網路條件較好、圖片也已經搭配 <picture> 備用機制的情境，不該是唯一格式。
把這幾件事放在一起看，答案其實一開始就不是全面轉檔或完全不管兩個極端。新圖片直接存成新格式，幾乎沒有多餘的決策成本；舊圖庫維持現狀，直到某一張圖真的卡在 LCP 或首屏這種關鍵位置，才值得回頭花力氣處理。PageSpeed 或 Lighthouse 那項紅字會不會變綠，從來不是重點，使用者實際等圖片出現的那幾百毫秒才是。分數只是這件事的副產品，不是目的本身。