2026 年 8 月 17 日
網站圖片縮小全攻略:2026 年完整指南
慢的頁面,常常只是因為某張 hero 圖多出幾百 KB。 新一年的首次頁面速度稽核,可能在六個月前還能通過的同一頁 突然亮紅燈——因為 Google 的 Core Web Vitals 門檻, 隨著平均頁面權重與瀏覽行為的改變又收緊了。 這份指南涵蓋所有能縮小檔案尺寸的選擇:哪個格式、 哪個品質、哪個尺寸、哪個載入模式、哪個替代文字。 一次做到位,2026 年跑得快。
選對格式
格式選擇決定了圖片重量的 50-70%。沒有單一正解;端看它是 照片、插畫還是動畫。
- WebP:大多數照片的預設選擇。比同等品質 JPG 小 25-35%,支援 alpha 通道、無損壓縮與動畫。所有現代瀏覽器 (Chrome、Firefox、Safari 14+、Edge)都能順暢讀。
- AVIF:壓得更兇——多數情境比 WebP 再小 20-30%—— 但編碼慢,Safari 支援也較新。適合伺服器端編碼;不適合 瀏覽器內 WASM 即時生成。
- JPG:相容性最廣。若要餵給很舊的瀏覽器 (尤其是 Android 8 以下)或社群分享時要轉出的檔案,留在 JPG。
- PNG:無損,所以適合透明 logo、螢幕截圖、 邊緣銳利的插畫。照片用會太大。
- SVG:向量素材(icon、logo、圖形)用。 極小、無限縮放、可用 CSS 上色。
不確定是照片還是插畫?有銳利邊緣與大塊平面色,從 PNG / WebP 起手;是照片,走 JPG / WebP / AVIF。
品質設定:80 幾乎永遠是甜蜜點
多數照片在品質 75-85 的範圍屬於「看起來一樣、位元組少很多」 的甜蜜區。降到這以下,JPEG / WebP 區塊化瑕疵開始可見—— 特別是膚色、柔順漸層、低對比紋理。升到這以上,檔案 急速膨脹,但感知到的品質只增加一點點。
下表是 1920×1280 風景照的概略大小:
| 格式 | 品質 | 大小(約) | 備註 |
|---|---|---|---|
| JPG | 60 | ~120 KB | 瑕疵已可見。 |
| JPG | 75 | ~180 KB | 可分享,有輕微問題。 |
| JPG | 82 | ~260 KB | 多數用途的甜蜜點。 |
| WebP | 80 | ~180 KB | 視覺等同 JPG 82。 |
| AVIF | 60 | ~140 KB | 更小但編碼慢。 |
對的尺寸:不要超過螢幕像素
圖片壓縮最簡單的紅利,是把寬度縮到內容實際需要。Mac 上 一張「2400 像素」的照片要塞進部落格側邊欄,先縮到 800 像素 就讓檔案變成 3-4 倍小——通常比把品質調低 1 點更有效。
挑對尺寸的快速方法:
- 用開發者工具量測某個 viewport 的實際渲染寬度。
- 為 Retina 乘以 2(高 DPI 螢幕要 2 倍真實像素)。
- 用 CSS
max-width: 100%搭配那個寬度發佈。
現代瀏覽器支援用 srcset 與 sizes提供多種解析度——400w、800w、1200w、1600w。瀏覽器會依裝置 螢幕與密度,挑選最小夠用的來源。
延遲載入:把視窗外往後挪
loading="lazy" 屬性告訴瀏覽器:螢幕外的圖片, 等使用者靠近時才載入。除了首屏 hero,其他所有圖片都應該 用它當預設。
簡單的規則:首屏圖用 loading="eager" +fetchpriority="high";其餘所有圖片用loading="lazy" 並帶上正確的width / height 屬性(避免版面位移)。
替代文字、標題與 SEO
圖片最佳化不只是像素。Google 圖片搜尋把 alt 文字當作排名 信號與無障礙需求。每個 <img> 都要寫描述性alt;裝飾性圖片留空。檔名也別再用IMG_4829.jpg——改成像landscape-vacation-dubai-evening.jpg 這種 有意義的名稱,搜尋引擎會感謝你。
量測與驗證
靠「感覺」最佳化,每次結果都不一樣。Lighthouse、 PageSpeed Insights、GTmetrix、WebPageTest 都會回報 LCP(Largest Contentful Paint)與總頁面權重。快速檢查清單:
- hero 圖的 LCP 在 2.5 秒以下嗎?
- 每頁總下載量低於 1.5 MB 嗎?
- 所有
<img>都帶alt、width、height屬性嗎? - 沒有任何圖片寬度超過螢幕像素的 2 倍嗎?