同一張圖，手機為什麼不該拿到 1920 那一檔

圖片通常是網頁裡最大的一塊。而它同時也是最容易改善的一塊——不用重構任何邏輯，換個格式、多輸出幾個尺寸就有效。

發想：不要用教學用的假素材

這個 demo 我刻意用 /surf 那頁實際在用的照片，不是另外找一張漂亮的範例圖。位元組是當場抓下來量的。

理由是：教學範例常常挑一張特別適合某種壓縮的圖，數字好看但沒有代表性。用自己網站上真的會載入的東西，數字才有意義。

測試：兩個維度一起看

同一張圖輸出成 AVIF 與 WebP、各兩種寬度。點左側名稱可以切換預覽，下方顯示每一檔的實際位元組。

兩個結論會同時浮出來：

格式：AVIF 通常比 WebP 再小三到四成
尺寸：手機只需要 768 寬那一檔，硬塞 1920 給它就是白花好幾倍流量

第二點的差距通常比第一點還大。這也是我覺得這個 demo 值得做的原因——大家都在討論該用哪種格式，卻常常所有裝置都送同一張最大的圖。

理解：srcset 與 sizes 的分工

不必手動選。把這兩個屬性寫對，瀏覽器會依螢幕寬度與像素密度自己決定：

<picture>
  <source type="image/avif" srcset="pic-768.avif 768w, pic-1280.avif 1280w" sizes="...">
  <source type="image/webp" srcset="pic-768.webp 768w, pic-1280.webp 1280w" sizes="...">
  <img src="pic-1280.webp" width="2400" height="1350" loading="lazy" decoding="async" alt="...">
</picture>

各自的角色：

<source type>：格式協商。瀏覽器由上往下挑第一個它支援的，所以 AVIF 要排在 WebP 前面。
srcset 的 w：告訴瀏覽器每個檔案實際多寬。這個數字必須誠實，寫錯瀏覽器就挑錯。
sizes：告訴瀏覽器這張圖在版面上會佔多寬。這是最容易寫錯的一個——寫 100vw 但實際只佔 500px 的欄位，瀏覽器就會高估一階、多下載一個尺寸。
width / height：給瀏覽器算長寬比用，圖還沒載入就先佔好版位，避免內容往下跳（CLS）。

講解：這站上的實作

我這個部落格的圖片管線就是照這個做的：原圖丟進一個不會被部署的資料夾，一支腳本輸出 AVIF + WebP 各五種寬度（160 / 400 / 768 / 1280 / 1920），並把「哪張圖有哪些尺寸」寫成一份清單。

建置時，markdown 裡的 ![說明](/blog/檔名.jpg) 會依那份清單自動展開成上面那段 <picture>。作者端永遠只寫原始檔名。

其中最有感的一個修正：文章列表的縮圖只顯示 60px，原本卻在載 800×800 的原圖。加上 160 這一階之後，那張縮圖從 19.4 KB 降到 1.4 KB。

格式選對是一次性的收益，尺寸選對才是每天都在省。

這個 demo 可以在效能實驗室自己操作。