批次圖片壓縮：網頁開發者指南 | Bulk Image Compressor

Published December 18, 2025

圖片是多數網站中最佔資源的素材。在平均一個頁面中，圖片佔了總體積的 40% 到 60%。如果你是一名網頁開發者卻沒有壓縮圖片，無論你的程式碼寫得多乾淨，你傳送的仍然是臃腫的頁面。

問題不在於要不要壓縮，而是在你的工作流程中該在哪個環節進行壓縮，以及每種情況適合哪種工具。

圖片壓縮在開發工作流程中的定位

在開發過程中，有三個主要環節可以進行圖片壓縮：

提交前。 在圖片進入版本控制前，先在本地端進行優化。這樣可以保持你的儲存庫精簡，並且讓每個環境（測試環境、正式環境、其他開發者的電腦）都能自動取得優化後的版本。

建置過程中。 使用 Vite 或 webpack 這類建置工具，在資源管線中處理壓縮。原始圖片在儲存庫中保持完整品質，建置過程會產生優化後的版本供部署使用。

CDN 層。 Cloudflare、Imgix 或 Cloudinary 等服務會根據請求的裝置和瀏覽器，即時轉換並壓縮圖片。

每種方法各有取捨，你也可以將它們組合使用。

線上工具 vs 建置插件

對於快速的一次性任務，例如為一篇部落格文章壓縮一批截圖，或優化一組圖示，線上工具是最快的選擇。開啟 Bulk Image Compressor，放入檔案，調整品質，下載。一分鐘內搞定。

建置插件則可以自動處理持續性的優化。以下是實際運作的方式。

Vite

Vite 使用者可以使用 vite-plugin-imagemin 或類似的插件：

// vite.config.js
import imagemin from 'vite-plugin-imagemin';

export default {
  plugins: [
    imagemin({
      mozjpeg: { quality: 80 },
      webp: { quality: 80 },
      pngquant: { quality: [0.7, 0.8] },
    }),
  ],
};

這會在 vite build 期間壓縮圖片。原始檔案保持不變，輸出目錄會得到優化後的版本。

webpack

使用 webpack 時，image-minimizer-webpack-plugin 可以完成同樣的工作：

const ImageMinimizerPlugin = require('image-minimizer-webpack-plugin');

module.exports = {
  optimization: {
    minimizer: [
      new ImageMinimizerPlugin({
        minimizer: {
          implementation: ImageMinimizerPlugin.sharpMinify,
          options: {
            encodeOptions: {
              jpeg: { quality: 80 },
              webp: { quality: 80 },
            },
          },
        },
      }),
    ],
  },
};

何時該使用哪一種

使用線上工具的情況：

你正在為專案加入少量圖片，希望立刻優化
你處理的是客戶或設計師寄來的未優化檔案
你的專案沒有建置步驟（靜態 HTML、簡單網站）
你想在提交前先視覺化檢查壓縮結果

使用建置插件的情況：

你的專案已經有建置管線
多位開發者貢獻圖片，你需要一致的優化效果
你需要格式轉換（例如自動產生 WebP 版本）
你希望原始圖片在儲存庫中維持完整品質，以便未來重新處理

CI/CD 圖片優化

建置插件在本地建置時執行，但你也可以將圖片優化加入 CI/CD 管線。這樣可以攔截漏網之魚的未優化圖片，無論是誰提交的。

一個簡單的做法是在 CI 管線中執行腳本檢查圖片檔案大小：

# 如果任何圖片大於 500KB，則讓建置失敗
find public/images -type f \( -name "*.jpg" -o -name "*.png" -o -name "*.webp" \) -size +500k | tee oversized.txt
if [ -s oversized.txt ]; then
  echo "發現過大圖片。請在部署前壓縮。"
  exit 1
fi

若要在 CI 中進行自動化壓縮，可以使用 sharp-cli 或 imagemin-cli 這類工具，在建置步驟中處理圖片。這樣可以確保沒有未壓縮的內容進入正式環境。

延遲載入與響應式圖片

僅靠壓縮是不夠的。圖片的載入方式同樣重要。

延遲載入 會將螢幕外的圖片延後到使用者滾動到該處才載入。為所有摺疊線以下的圖片加上 loading="lazy"。但不要對英雄圖片或任何在初始頁面載入時就可見的內容使用延遲載入，因為這會損害你的 Largest Contentful Paint 分數。

響應式圖片 會根據螢幕寬度提供不同尺寸的圖片。手機不需要為桌面螢幕設計的 2400px 圖片。使用 srcset 和 sizes 屬性讓瀏覽器選擇正確的版本：

<img
  src="product-800.webp"
  srcset="product-400.webp 400w, product-800.webp 800w, product-1600.webp 1600w"
  sizes="(max-width: 640px) 400px, (max-width: 1024px) 800px, 1600px"
  alt="產品照片"
  width="1600"
  height="1067"
  loading="lazy"
>

在建置過程中或使用批次工具上傳前產生這些尺寸變體。

CDN 傳送

CDN（內容傳遞網路）從地理位置上接近訪客的伺服器提供圖片，這能減少延遲。但有些 CDN 更進一步提供即時圖片優化功能。

Cloudflare Image Resizing 可以根據訪客的瀏覽器自動調整圖片尺寸並轉換為 WebP 或 AVIF 格式。你不需要自行產生各種變體。

Imgix 和 Cloudinary 是專用的圖片 CDN。你上傳一個高品質的原始檔，它們就能透過 URL 參數產生你需要的任何尺寸、格式和品質。這功能很強大，但會按每張圖片計費。

對大多數專案來說，在上傳前壓縮圖片，然後透過標準 CDN（Cloudflare、Fastly、AWS CloudFront）傳送就已經足夠。專用圖片 CDN 在你擁有數千張使用者上傳的圖片、需要動態調整尺寸時才值得考慮。關於壓縮對網頁重要性的背景知識，我們的指南為什麼網站圖片需要壓縮涵蓋了基礎原理。

開發者常犯的錯誤

提交未優化的圖片。 一個 5MB 的 JPEG 一旦進入你的儲存庫，就會永遠留在 git 歷史中，即使你後來把它替換掉了。提交前記得壓縮。

對照片使用 PNG。 PNG 適合圖形、截圖和需要透明度的圖片。用 PNG 儲存的照片，檔案大小通常是相同圖片的 JPEG 或 WebP 的 3 到 5 倍。根據內容類型選擇正確的格式。請參閱我們的格式比較指南了解詳細資訊。

省略寬度和高度屬性。 沒有明確的尺寸，瀏覽器在圖片載入前無法知道要保留多少空間。這會導致佈局位移，損害你的 CLS 分數並干擾使用者。

過度壓縮。 為了獲得極小的檔案而將品質降到 30% 或 40%，會產生明顯的瑕疵。對於網頁圖片，75% 到 82% 的品質能在尺寸和外觀之間取得良好的平衡。

忽略圖片尺寸。 將一張 4000px 的照片壓縮到 80% 品質是好事，但如果它在你的頁面上只顯示為 600px 寬，你仍然傳送了比所需多出許多的像素。先調整到顯示尺寸，再進行壓縮。

不使用 WebP。 瀏覽器對 WebP 的支援現在已經很普遍。如果你仍然只提供 JPEG 和 PNG，你就白白損失了 25% 到 35% 的檔案大小節省空間。

務實的做法

對大多數網頁專案來說，以下方法效果很好：

在提交前使用 Bulk Image Compressor 這類線上工具或本地端腳本，調整尺寸並壓縮圖片。
加入建置插件作為安全網，攔截任何漏網之魚。
在 HTML 中使用延遲載入和響應式圖片。
透過 CDN 傳送。

你不需要第一天就全部做到。從第一步開始。光是這一步就能讓你的頁面載入時間有明顯的改善。

Ready to compress your images?

Bulk compress JPEG, PNG, WebP, and AVIF images right in your browser. No uploads, no sign-ups.

Try Bulk Image Compressor