一句話說清楚
壓網站圖片卻不掉畫質，關鍵不是一開始就把品質滑桿拉到「還能忍」的最低值。真正的起點，是這張圖在頁面裡到底做什麼用。首屏 Hero、可放大的商品圖、部落格配圖、頭像、介面截圖與背景紋理，各自需要不同的尺寸、格式和品質。
一條好用的規則是：先縮到實際展示的最大尺寸，然後在「在版面裡看不出變化」的範圍內適度壓縮。 一張部落格圖在頁面上寬 760 CSS 像素顯示，高密度螢幕下 1500–1600 px 的原始圖通常就夠了。5000 px 的相機原圖就是浪費資料；反過來，直接輸出 760 px 又會在 Retina 上偏軟。合適的檔案在兩個極端之間。
「不損失畫質」也需要一個務實的定義。放在網頁語境裡，通常指的是在訪客真正看到的尺寸下沒有可見的畫質損失，而不是數學意義上的像素級完全一致。壓縮後的 WebP 與原檔並不相同，但在頁面裡可以做到視覺上分辨不出。
先判斷這張圖屬於哪一類
在選 WebP、AVIF、JPEG、PNG 或一個品質數值之前，先把這張圖歸類：
| 圖片角色 | 常見展示尺寸 | 起手格式 | 起手品質 | 需要重點看的地方 |
|---|---|---|---|---|
| LCP 首屏 Hero | 寬 1200–2400 px | AVIF + WebP/JPEG 備援 | AVIF 45–65，WebP 78–85 | 天空、皮膚、陰影、品牌色 |
| 部落格/內文配圖 | 原始圖寬 1200–1600 px | WebP，JPEG 備援 | WebP 78–85 | 細節與漸層 |
| 商品列表縮圖 | 原始圖寬 500–900 px | WebP | WebP 70–78 | 文字標籤、邊緣、紋理 |
| 商品詳細圖 | 原始圖寬 1200–2000 px | WebP 或 AVIF | WebP 82–88，AVIF 50–70 | 放大後的細節與色彩還原 |
| UI 截圖 | 實際顯示尺寸或 2x | PNG 或無損 WebP | 涉及文字用無損 | 文字、圖示、鋭利邊緣 |
| Logo 或圖示 | 盡量用向量 | SVG | 不適用 | 縮放時保持清晰 |
| 背景紋理 | 只按展示尺寸輸出 | WebP 或 JPEG | 60–75 | 色帶與拼接縫 |
這張表故意帶態度。網站圖片壓得差，大多情況就是把所有素材當同一件事處理。首頁 Hero 會影響 Largest Contentful Paint；商品詳細圖會影響信任與轉換；裝飾性背景沒人細看，可以做得輕很多。
先縮放：尺寸做了大部分工作
壓縮降低的是「儲存這張固定像素網格」所佔的位元組；縮放改變的是像素網格本身。當原始圖的像素遠多於頁面能顯示的量，縮放才是最乾淨的省法。
一條簡單的定尺公式：
目標原始圖寬度 = 最大 CSS 顯示寬度 × 裝置像素比
例如：
- 卡片圖以 320 CSS px 展示，2x 螢幕對應 640 px 原始圖。
- 部落格圖以 760 CSS px 展示，原始圖 1500–1600 px。
- 接近 1200 CSS px 的整寬 Hero，視裁切與受眾裝置可能需要 2000–2400 px 原始圖。
不要機械地給每張圖都用 3x。web.dev 提到，DPR 和版面是一起起作用的；在很多情況下，使用者根本感知不到超高 DPR 圖源帶來的好處。2400 px 的 Hero 可能合理；「像素多總沒錯」的 5000 px Hero，大多只是在燒頻寬。
PhotoTools 把這兩件事分開：需要精確像素或縮短長邊時用 Resize，然後在 Compress 裡挑 JPEG、WebP 或 AVIF，微調品質。
動品質之前先選格式
格式決定了「哪種細節可以被乾淨地移除」。
- 多數網頁照片用 WebP。 現代瀏覽器廣泛支援，視覺畫質相近時通常比 JPEG 更小。Google 的 WebP 文件給出的對比數據是：相較同品質 JPEG 有 25–34% 的體積節省。
- 對位元組錙銖必較時用 AVIF。 AVIF 在大幅照片素材上可以壓過 WebP，但編碼更慢，也會讓交付鏈更複雜。要搭配備援格式使用，不要當作唯一輸出。
- JPEG 當作相容備援。 電子郵件、老 CMS 流程、下載派送以及
<img>的備援來源，JPEG 還是有用武之地。 - 截圖與文字類內容用 PNG 或無損 WebP。 有損的 JPEG/WebP 會讓 UI 小字發糊，也會在銳利邊緣周圍出現色雜訊。
- Logo 與圖示用 SVG。 點陣 Logo 轉 WebP 或許比 PNG 更小，但一個乾淨的 SVG 通常更清晰、也更輕。
如果用 <picture>，把最省的格式放前面，內層的 img 留一個相容備援：
<picture>
<source
type="image/avif"
srcset="/images/hero-1200.avif 1200w, /images/hero-2000.avif 2000w"
sizes="100vw"
/>
<source
type="image/webp"
srcset="/images/hero-1200.webp 1200w, /images/hero-2000.webp 2000w"
sizes="100vw"
/>
<img
src="/images/hero-1200.jpg"
width="1200"
height="800"
alt="裝修完成的廚房，胡桃木櫥櫃配自然光"
/>
</picture>
img 仍然重要——它承載備援來源、alt、width、height。不要把無障礙資訊或版面資訊藏在 source 裡。
實際能落地的品質檔位
「品質數值」並沒有跨工具的統一標準。一個編碼器裡的 JPEG 品質 80，跟另一個編碼器裡的 80 未必等價；WebP 80、JPEG 80、AVIF 50 之間也不能畫等號。把品質當成起手值，再看輸出結果。
| 輸出 | 起手值 | 需要調高的時候 | 需要調低的時候 |
|---|---|---|---|
| JPEG 備援 | 82–88 | 商品細節、人臉、圖上文字 | 裝飾性照片、背景、檔案仍然過大 |
| WebP 照片 | 78–85 | Hero、商品、作品集圖 | 縮圖、列表圖、簡單背景 |
| WebP 縮圖 | 70–78 | 文字或紋理看起來發軟 | 圖很小但檔案還是不輕 |
| AVIF 照片 | 45–65 | 出現色帶，皮膚／布料／細節崩掉 | 大 Hero 依然太重 |
| PNG | 不涉及有損品質 | 需要清晰邊緣的截圖或透明素材 | 只有目標端支援時才考慮 WebP/AVIF |
一個常見誤區是「為了保險」把所有圖都輸出到 95 或 100。多數網頁照片裡，那些多出來的位元組只會出現在網路瀑布圖上，頁面上並看不出差別。另一個誤區是為了硬湊某個體積目標把品質壓到 50 以下。如果得壓這麼狠，先別繼續拉低品質，而是先縮尺寸或換格式。
依頁面角色分的體積目標
這些不是 Google 規則，也不是決定排名的魔法門檻。它們是實用的複審目標，幫你抓出明顯過重的圖。
| 素材 | 健康的工作目標 | 備註 |
|---|---|---|
| 頭像／作者頭像 | 10–40KB | 通常 160–400 px 展示 |
| 卡片縮圖 | 15–60KB | 列表圖尺寸應保持一致 |
| 部落格內文圖 | 60–180KB | 與寬度和細節量有關 |
| 商品列表圖 | 50–150KB | 標籤必須清楚可讀 |
| 商品詳細圖 | 120–300KB | 為放大與紋理留餘裕 |
| 首屏 Hero | 150–450KB | 更大也可能合理，但要測 LCP |
| 全螢幕作品集照片 | 250–700KB | 有時候畫質比嚴格體積更重要 |
| UI 截圖 | 30–250KB | 文字清晰度勝過省幾個位元組 |
一張 760 px 的部落格圖如果 900KB，多半有問題。一張整寬作品集照片 410KB 但效果極好，硬壓到 90KB 反而是走錯方向。
LCP 與 Hero 圖的壓縮
最值得下功夫的圖，往往就是首屏最大的那張。用 Core Web Vitals 的說法，它常常就是 Largest Contentful Paint 圖。壓小它有幫助——前提是它還要能被「早發現、早載入」。
處理 Hero 圖時：
- 按頁面裡實際使用的長寬比裁切。
- 輸出多檔響應式寬度，例如 1200 px 與 2000 px。
- 如果技術棧支援，AVIF 放前面，WebP/JPEG 作為備援。
- 不要給 Hero 或首屏其他 LCP 候選加 lazy-load。
- 加上
width與height，讓瀏覽器提前保留版面空間。 fetchpriority="high"只用在最有可能成為 LCP 元素的那一張上。
備援 img 範例：
<img
src="/images/hero-1200.jpg"
srcset="/images/hero-1200.jpg 1200w, /images/hero-2000.jpg 2000w"
sizes="100vw"
width="1200"
height="800"
fetchpriority="high"
alt="裝修完成的廚房，胡桃木櫥櫃配自然光"
/>
不要給整個圖庫都掛 fetchpriority="high"。優先度提示是把鋒利的刀——留給那一張真的要最先到達的圖。
怎麼比較壓縮結果
正確的比較不是「原圖 vs 壓縮圖，100% 縮放」。那種比法只會讓你說服自己繼續發過大的圖。要在訪客真正看到的尺寸與情境裡比。
按這個流程走一遍：
- 把壓縮後的圖放到真實頁面，或同寬的測試版面裡。
- 桌面寬與手機寬都看一遍。
- 重點看容易出問題的區域：人臉、皮膚、天空、漸層、布料、商品標籤、小字，以及高對比邊緣。
- 在渲染尺寸下切換原圖與壓縮版。
- 只在很短的時間裡 100% 放大，用來抓明顯的偽影，不是為了追求沒人會看到的完美。
不同格式的壓縮偽影各有個性：JPEG 常見塊狀邊緣、振鈴、色雜訊；過壓的 WebP 會把紋理糊成一片；AVIF 推太狠會出現色帶與塑膠感；PNG 截圖則容易走到另一頭——看起來完美，但重得離譜。
一個 PhotoTools 的網頁圖處理流程
PhotoTools 適合放在圖片進入 CMS、CDN 或程式碼倉庫之前。它取代不了完整的建置管線，但對小型網站、部落格文章、給客戶的預覽稿以及一次性素材，它提供了一條乾淨的手動流程。
- 保留原始來源檔，不動。
- 定角色：Hero、內文圖、商品圖、截圖、縮圖或背景。
- 原圖遠大於展示尺寸時，先用 Resize。
- 打開 Compress，選 JPEG、WebP 或 AVIF，WebP/JPEG 從品質 80 附近起手。
- 按下 “Compress all”，逐張看原始體積、輸出體積、節省比例。
- 下載結果，放回頁面情境裡檢查。
- 視覺上不過關，就回到原圖或縮過的中間稿，換更高品質重新輸出。
- 還是過重，就先縮尺寸，再考慮把品質壓進偽影區。
不要反覆對已經壓過的下載稿再壓縮——有損偽影會疊加。回到母檔或乾淨的縮放中間稿再來。
中繼資料與隱私
相機檔案常常帶 EXIF 中繼資料：GPS 座標、拍攝時間、機身型號、鏡頭、編輯軟體等。這些對訪客看圖並無幫助，反而可能洩漏私人資訊。
PhotoTools 的壓縮流程是：解碼檔案、把像素畫到瀏覽器的 canvas 上，然後輸出一份新檔案。MDN 文件提到，OffscreenCanvas.convertToBlob() 可以為支援有損壓縮的格式指定圖片類型與品質。由於輸出是由 canvas 上的像素生成的，相機中繼資料通常不會被帶入新檔案。
涉及敏感照片時，請在發布前用中繼資料檢查工具再驗一次最終下載稿。隱私不只是檔案大小的問題。
會讓圖看起來變差的常見錯誤
- 壓縮早於縮放： 你在試圖從「版面根本不會展示的像素」裡省位元組。
- 給照片用 PNG： 對相機圖，PNG 通常大得離譜。
- 給帶文字的截圖用 JPEG： 體積或許更小，但文字會糊。
- 在錯誤尺寸下判斷： 全解析度放大會把無害的偽影渲染得觸目驚心。
- 給所有裝置只出一張巨大的 Hero： 手機使用者白白下載了自己用不上的桌面像素。
- 給 Hero 加 lazy-load： 首屏以外的圖可以 lazy-load，LCP 圖不行。
- 不寫
width與height： 圖片載入時頁面可能跳動。 - 對線上已壓過的檔案再壓： 能回原檔就回原檔。
一份精簡的發布前清單
上傳一張網站圖之前，走一遍：
- 這個格式適合當前內容類型嗎？
- 原始圖寬度是不是基於真實展示寬度與合理 DPR 定的？
- 若行動版 Hero 有不同裁切，是否準備了更小的行動版候選？
- 品質檔能不能撐住人臉、標籤、漸層、商品細節？
- 檔案大小對它的角色而言算合理嗎？
- 頁面上有沒有
width、height、有意義的alt，以及在需要時的響應式srcset/sizes？ - LCP 圖是否 eager 載入並優先，首屏之外的圖是否 lazy-load？
- 有沒有把輸出的圖放回真實版面裡看過？
- 是否留了原始來源檔？
好的壓縮流程是那種「合理地無聊」：挑對像素、挑對格式、用合理品質輸出、放回真實頁面裡看、在圖開始顯出「加工感」之前收手。
參考的技術資料
本文對照了 PhotoTools 目前的壓縮與縮放實作、web.dev 的圖像效能指南、Chrome 的「Improve image delivery」洞察、Chrome 的「Properly size images」建議、MDN 的 OffscreenCanvas.convertToBlob() 文件、MDN 的圖像檔案類型指南 以及 Google 的 WebP 文件。