圖片通常是頁面上最重的東西，這讓它成為你能掌控的最大提速槓桿。把它們的尺寸和檔案體積弄對，頁面就像瞬間載入；弄錯了，無論你的程式碼多幹淨，都過不了 Core Web Vitals。下面是目標值，以及達標的工作流。
尺寸目標
讓圖片的畫素尺寸與它實際出現的位置匹配。大致指南：
- 通欄主視覺： 1600–2000 px 寬覆蓋大多數桌面佈局。再寬很少有幫助，卻要花很多位元組。
- 正文內配圖： 你的內容欄寬度，常見 800–1200 px。
- 縮圖／卡片圖： 300–500 px。
- 頭像／圖示： 按顯示尺寸 48–200 px。
把一張 4000px 的圖塞進 800px 的位置，意味著瀏覽器下載並解碼了它永遠顯示不出來的 25 倍畫素。這是純粹的浪費——而且解碼大圖還會卡住主執行緒。
體積目標
尺寸設定上限，壓縮決定實際體積。目標：
- 主視覺圖： 小於 200 KB（最好 100–150 KB）。
- 正文內配圖： 80–150 KB。
- 縮圖： 10–30 KB。
- 每頁圖片總量： 儘量讓整頁控制在 約 1 MB 以內。
如果單張圖超過約 300 KB，就當成一個需要排查的 bug。
為什麼這會左右 Core Web Vitals
Google 的 Largest Contentful Paint（LCP，最大內容繪製）衡量螢幕上最大元素多久渲染出來——而在大多數頁面上，那個最大元素就是圖片（通常是主視覺）。一張又重又大的主視覺直接拉高 LCP。良好的 LCP 是小於 2.5 秒；一張臃腫的主視覺在行動網路下光靠自己就能衝破這個線。
還有兩個與圖片相關的收益：
- 設定 width 和 height 屬性，讓瀏覽器預留空間——這保護你的 Cumulative Layout Shift（CLS，累積佈局偏移）分數。
- 優先載入主視覺（不要對 LCP 圖片做懶載入），對首屏以下的一切做懶載入。
兩步工作流
第一步——縮到真實顯示寬度。 用圖片尺寸調整工具把每張圖縮到它出現的尺寸。鎖定寬高比，高質量縮小。單這一步往往就能砍掉 80–90% 的體積。
第二步——壓縮。 把縮放後的檔案餵給圖片壓縮工具：照片用質量 75–85（視覺無損），PNG 用 256 色量化。它絕不會輸出比原圖更大的檔案，支援批次，還有可選的寬度上限，所以你實際上可以一遍搞定兩步。對現代瀏覽器，把照片轉成 WebP 還能再擠出 25–35%。
用測量代替猜測
圖片最佳化好之後，確認頁面真的變快了。IMG.DIY 的頁面體檢工具透過 Google PageSpeed Insights 審計一個線上 URL，並報告頁面的圖片體積，讓你揪出任何仍然過重的檔案。一點提醒：頁面體檢需要聯網——與圖片工具不同，它呼叫 Google 的 PageSpeed API，所以無法離線執行。部署後用它來檢查你真實的 LCP 和圖片預算。
預設保護隱私
縮放、壓縮、轉換工具都用 Canvas 和 WebAssembly 完全在你的瀏覽器裡執行——什麼都不上傳，首次訪問之後它們就被快取，可以離線使用。你可以在沒有網路的情況下備好整站的圖片，等頁面上線後再聯網跑一次頁面體檢。
快速回顧：把尺寸調對，壓到體積目標，為 LCP 優先載入主視覺，再用頁面體檢驗證。