Web開発者のためのバッチ画像圧縮 | Bulk Image Compressor

Published December 18, 2025

画像はほとんどのWebサイトで最も重いアセットです。平均的なページでは、全体の重量の40〜60%を占めています。Web開発者で画像を圧縮していないなら、どれだけコードがきれいでも、肥大化したページを配信していることになります。

問題は圧縮するかどうかではありません。ワークフローのどの段階で圧縮を行うべきか、そしてどのツールが各状況に適しているかです。

開発ワークフローにおける画像圧縮の位置づけ

開発中に画像を圧縮できる主なポイントは3つあります：

コミット前。 バージョン管理に入れる前にローカルで画像を最適化します。これによりリポジトリを軽量に保ち、すべての環境（ステージング、本番、他の開発者のマシン）で自動的に最適化バージョンを取得できます。

ビルド時。 Viteやwebpackなどのビルドツールが、アセットパイプラインの一部として圧縮を処理します。ソース画像はリポジトリにフルクオリティのまま保持され、ビルドプロセスがデプロイ用の最適化バージョンを生成します。

CDN層で。 Cloudflare、Imgix、Cloudinaryなどのサービスが、リクエスト元のデバイスやブラウザに基づいて画像をその場で変換・圧縮します。

各アプローチにはトレードオフがあり、組み合わせることも可能です。

オンラインツール vs ビルドプラグイン

ブログ記事のスクリーンショットを一括圧縮したり、アイコンセットを最適化するような、一回限りの簡単なタスクにはオンラインツールが最速です。Bulk Image Compressorを開き、ファイルをドロップし、品質を調整してダウンロードするだけ。1分もかかりません。

ビルドプラグインは継続的な最適化を自動的に処理します。実際の例を見てみましょう。

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 などのツールがビルドステップとして画像を処理できます。これにより、未圧縮のまま本番環境に送られることがなくなります。

遅延読み込みとレスポンシブ画像

圧縮だけでは十分ではありません。画像の読み込み方法も同様に重要です。

遅延読み込み（Lazy loading） は、画面外の画像をユーザーがスクロールするまで延期します。ファーストビューより下のすべての画像に 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です。1つの高品質ソースをアップロードすると、URLパラメータで要求したサイズ、フォーマット、品質を生成します。これは強力ですが、画像ごとにコストがかかります。

ほとんどのプロジェクトでは、アップロード前に画像を圧縮し、標準的なCDN（Cloudflare、Fastly、AWS CloudFront）を通じて配信するだけで十分です。専用の画像CDNは、何千ものユーザーアップロード画像があり、動的なリサイズが必要な場合に意味を持ちます。Webにおける圧縮の重要性の背景については、ウェブサイトの画像に圧縮が必要な理由のガイドをご覧ください。

開発者がよくやる間違い

未最適化画像のコミット。 リポジトリ内の5MBのJPEGは、後で置き換えてもgitの履歴に永遠に残ります。コミット前に圧縮しましょう。

写真にPNGを使用する。 PNGはグラフィック、スクリーンショット、透過画像向けです。写真をPNGで保存すると、同じ画像のJPEGやWebPよりも通常3〜5倍大きくなります。コンテンツタイプに適したフォーマットを使用しましょう。詳細はフォーマット比較ガイドをご覧ください。

width属性とheight属性の省略。 明示的な寸法がないと、ブラウザは画像が読み込まれるまで確保するスペースがわかりません。これによりレイアウトシフトが発生し、CLSスコアを悪化させ、ユーザーをイライラさせます。

過度な圧縮。 小さなファイルを目指して品質を30〜40%に下げると、目に見えるアーティファクトが発生します。Web画像の場合、75〜82%の品質がサイズと見た目の適切なバランスです。

画像寸法の無視。 4000pxの写真を80%品質で圧縮するのは良いですが、ページ上で600px幅で表示するなら、必要なピクセル以上のデータを送信していることになります。まず表示寸法にリサイズしてから圧縮しましょう。

WebPを使用しない。 WebPのブラウザサポートは現在普遍的です。JPEGとPNGだけを配信し続けるなら、25〜35%のファイルサイズ削減の機会を逃しています。

実践的なアプローチ

ほとんどのWebプロジェクトでは、以下の方法が効果的です：

コミット前にBulk Image Compressorなどのオンラインツールやローカルスクリプトで画像をリサイズ・圧縮する。
ビルドプラグインをセーフティネットとして追加し、すり抜けたものをキャッチする。
HTMLで遅延読み込みとレスポンシブ画像を使用する。
CDNを通じて配信する。

初日から4つすべてを行う必要はありません。最初のステップから始めましょう。それだけでもページの読み込み時間に目に見える違いが現れます。

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