頁面上一張 1920 寬的圖，手機使用者也得下載整張，然後瀏覽器再把它縮到 390 像素寬顯示——流量浪費了五倍，載入慢了一截。srcset 就是讓瀏覽器按螢幕寬度挑一個合適的版本，前提是你得先把這幾個版本做出來。
為什麼一張圖不夠
Core Web Vitals 裡的 LCP（最大內容繪製）通常就是首屏那張大圖。給手機使用者一張 1920 寬、400KB 的圖，LCP 很難進 2.5 秒；換成 480 寬、40KB 的版本，同樣的網路下快一個量級。Google 的頁面體驗訊號直接看這個數字。
反過來，桌面大螢幕只給 768 寬的圖又會糊。所以需要幾檔尺寸，讓瀏覽器自己選。
一張實用的斷點表
斷點按圖片在頁面裡的實際顯示寬度定，不是按螢幕寬度。對最常見的「通欄大圖」和「正文配圖」兩種情況：
- 通欄大圖（hero、橫幅）：480、768、1200、1920 四檔。覆蓋手機、平板、筆電、大螢幕。
- 正文配圖（內容區最寬 800 左右）：400、800、1200 三檔，1200 是給 1.5x 到 2x 螢幕的。
- 縮圖 / 卡片圖（顯示寬 300 左右）：300、600 兩檔。
檔位不是越多越好。每多一檔就多一次匯出、多一份儲存，而瀏覽器選圖有容差，相鄰檔位差 1.5 到 2 倍最合理。四檔已經覆蓋九成以上的裝置組合。
2x 版本要不要
Retina 和多數手機螢幕的像素密度是 2x 到 3x，顯示寬 400 的圖在這些螢幕上要 800 像素才清楚。上面表裡的大檔位其實已經在充當小檔位的 2x 版本——768 是 390 寬手機的 2x，1200 是 600 寬內容區的 2x。
所以不需要單獨再出一套「@2x」檔案，只要斷點之間保持 2 倍左右的間距，瀏覽器會按密度自動選高一檔。
格式：WebP 為主，JPG 備援
同樣畫質下 WebP 比 JPG 小 25% 到 35%，現代瀏覽器全部支援。做法是每個尺寸出 WebP，用 picture 標籤給舊瀏覽器留一份 JPG 備援；如果你的訪客裡 2020 年以前的瀏覽器已經可以忽略，直接只出 WebP 也行。
AVIF 更小，但在瀏覽器裡編碼慢得多，大批次匯出時不划算。關於幾種格式的取捨，AVIF、WebP、JPEG 對比說得更細。
批次匯出整套尺寸
把要處理的圖一起拖進批次圖片處理，按檔位跑幾遍，每遍改一個寬度和後綴：
- 尺寸「寬度 480」，關「允許放大」，輸出 WebP 品質 80%，檔名加後綴 -480。
- 同樣設定改成 768、後綴 -768；再 1200、1920。
- 需要 JPG 備援的話，輸出改 JPG，後綴不變，再跑一輪。
每一輪幾十秒，出來的 ZIP 檔名已經是 hero-480.webp、hero-768.webp 這種形式，直接傳到圖片目錄。「允許放大」務必關掉，1000 像素的原圖不會被拉到 1920 去。
單張圖想順手看看各檔位的體積差別，用圖片尺寸調整試一張就知道。
寫進 HTML
通欄大圖的寫法：
<img src="hero-1200.jpg"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="100vw" width="1920" height="1080" alt="...">正文配圖把 sizes 改成實際寬度，比如 sizes="(max-width: 840px) 100vw, 800px"。width 和 height 屬性一定寫，瀏覽器據此預留位置，頁面不會跳。
做完這一步，再配合讓圖片載入更快裡的懶載入和壓縮建議，圖片這一塊的效能分基本就拿滿了。