Web のための画像圧縮：実際にどれくらい節約しますか？

サイトの Core Web Vitals が赤、Lighthouse スコアが 60 を超えて動かず、監査ツールが「画像のサイズを適切に」と「モダンな画像フォーマットを使用」を叫び続けます。最悪の違反者を圧縮し、ページ重量が 1.2 MB ドロップし、突然 LCP が 3.4 秒から 1.8 秒に。画像圧縮はあらゆる Web サイトに対する最高 ROI のパフォーマンス勝利の 1 つのままです —— ただし各レバーが実際に何をするかを理解する場合のみ。

このガイドは、現実の画像で節約された現実のバイト数で、JPG 品質 80、WebP、AVIF、アグレッシブリサイズがそれぞれ何を与えるかを測定します。「モダン」フォーマットへの再エンコードが節約するよりコストがかかるとき、そして Ai2Done の Image Compress ツール ですべてのこれをブラウザサイドで行う方法もカバーします。

TL;DR

• 圧縮前にリサイズ —— 800×600 で表示される 4000×3000 写真は、フォーマットに関係なくバイトの〜95% を無駄にします。最初にリサイズ；圧縮は 2 番目。
• JPG 品質 80 → 90 は写真のスイートスポット —— 品質 100 より 50〜70% 小さい、視覚的に同一。
• WebP は JPG より〜25〜35% 節約同じ視覚品質で。2020 年以降の普遍的ブラウザサポート。
• AVIF は JPG より〜50% 節約同じ視覚品質で、ただしエンコード時間を 5〜10 倍追加。高トラフィックページに価値あり。
• 画像サイズ対品質の並べてプレビューでブラウザサイド圧縮用に Ai2Done Image Compress を使用。

なぜ見た目より難しいのか

「この画像を圧縮」が単一の決定だと思うでしょう。実際には、画像圧縮は少なくとも 4 つの独立したレバーで、直感的でない方法で相互作用します：

1. 寸法（幅 × 高さ）—— 通常最も高インパクトのレバー。4000×3000 写真は 1000×750 の 16 倍のピクセルを持ちます。
2. フォーマット（JPG、WebP、AVIF、PNG）—— エンコーディング方法自体。
3. 品質設定（JPG/WebP には 1〜100、AVIF にはわずかに異なる）—— エンコーダーが情報をどれだけアグレッシブに破棄するか。
4. カラー深度とメタデータ（24 ビット対 8 ビット、EXIF 剥がし、ICC プロファイル）—— 通常小さいが無料の勝利。

ナイーブな「この画像を圧縮」ツールはレバー 3 のみに触れ、テーブルに最大の節約を残します。モダンツール —— 当社を含む —— は、少なくとも 4 つすべてを明示的に選べます。

複雑化のもう 1 つのソース：ブラウザサポートとオーディエンス。AVIF は Chrome、Edge、Firefox、Safari 16+ で素晴らしい；古い Safari には JPG フォールバックが必要。WebP は IE 11（Microsoft が 2022 年にサポートをドロップしたが、エンタープライズサイトはまだ見る）を除くどこでも。2026 年のほとんどの公開サイトには、WebP は安全；AVIF は JPG フォールバック付きの <picture> 要素が必要。

現実世界の測定：3 MB 写真、すべての方法で圧縮

代表的なテスト画像 —— 都市スカイラインの 4032×3024 iPhone ショット、カメラのデフォルト品質（〜92）で 3.1 MB JPG を取りました。各レバーが単独で何をするかは以下：

ヘッドライン：リサイズ + モダンフォーマットの組み合わせは、見える品質損失なしで 90〜95% の削減を与えます。どちらかのレバー単独で 30〜45% に到達します。これが Lighthouse 監査が「適切なサイズ」と「モダンな画像フォーマットを使用」の両方を主張する理由です —— 乗算します。

方法 1：Ai2Done Image Compress（ブラウザサイド、マルチレバー）

Ai2Done Image Compress ツール はブラウザで 4 つすべてのレバーを実行します：

1. 任意のモダンブラウザで /tools/image_compress を開く。
2. 画像をドロップ —— JPG、PNG、WebP、AVIF、HEIC を受け入れ。バッチアップロードは一度に最大数十のファイルで機能。
3. 出力フォーマットを選ぶ：JPG（普遍的）、WebP（モダン、25% 小さい）、AVIF（モダン、50% 小さい、より遅いエンコード）、または PNG（ロスレス、図表とスクリーンショットのみ）。
4. 品質を設定：80 が写真の普遍的スイートスポット。サムネイルには 70 にドロップ；ヒーロー画像には 90 に上げる。
5. オプションのリサイズ：最大幅または最大長エッジを設定。アスペクト比は自動的に保持。
6. 圧縮をクリック —— バッチジョブには、すべての最適化された画像の ZIP を取得。

サイドパネルは現在の設定で原本対圧縮の並べてプレビューを、両方のバイト数と視覚デルタ（PSNR、SSIM —— 知覚品質メトリック）でサイズを表示します。品質スライダーをライブで調整し、コミット前にリアルタイムでトレードオフを見ます。

すべてがブラウザで実行されます。写真は当社のものを含めサーバーにアップロードされません。エンコーダーは JPG 用 mozjpeg-wasm、WebP 用 libwebp-wasm、AVIF 用 libavif-wasm —— すべて実際の参照実装、WASM SIMD 加速でコンパイル。

方法 2：Squoosh.app（Google のオープンソースツール）

非常に正確なコントロールでの単一画像には、Google の Squoosh.app がフロントエンドコミュニティで最も愛されているツールです。同じアーキテクチャ（すべてブラウザ内）、画像一度に 1 つの UX、すべてのエンコーダーに非常に細粒度のノブ。バッチには遅い（並列処理なし）で UX は mozjpeg のクロマサブサンプリングが何をするか知っていると仮定しますが —— 稀な「1 つのヒーロー画像を完璧主義者として調整する必要」には、無敵です。

方法 3：ビルドパイプラインの imagemin

サイトビルドの一部としての自動最適化用：

npm install --save-dev imagemin imagemin-mozjpeg imagemin-webp imagemin-avif

# ビルドスクリプトで
import imagemin from 'imagemin';
import imageminMozjpeg from 'imagemin-mozjpeg';
import imageminWebp from 'imagemin-webp';

await imagemin(['src/images/*.{jpg,png}'], {
  destination: 'build/images',
  plugins: [
    imageminMozjpeg({ quality: 80 }),
    imageminWebp({ quality: 80 }),
  ]
});

これは画像を頻繁に更新する本格的なサイトの正しい答えです —— 最適化はビルドごとに実行、手動ステップなし。一度きりの画像バッチや「サイトに 1 つのヒーロー画像を追加した」には、ブラウザツールが速い。

方法 4：Next.js / Astro / フレームワーク組み込み画像最適化

モダンフレームワークは、「リサイズ + フォールバック付きモダンフォーマットを提供」パイプライン全体を処理する組み込み画像最適化を出荷します：

• Next.js：<Image> コンポーネントが srcset を自動生成、JPG フォールバック付き WebP/AVIF を提供、レイジーロード。
• Astro：<Image> コンポーネントが同じことを行う。
• Gatsby：gatsby-plugin-image が同じことを行う。
• Cloudflare Images：変換 URL を介して任意のソース画像を提供 —— ?width=800&format=auto で各訪問者に正しいサイズと正しいフォーマットを取得。

新しいサイトを構築しているなら、フレームワークの組み込みハンドラーを使ってください。静的またはレガシーサイトには、ブラウザ / CLI 圧縮がパスです。

ブラウザコンプレッサーをどう構築したか（技術的ディープダイブ）

Ai2Done Image Compress ツール は 3 つの WebAssembly エンコーダーモジュールに構築されています：

• mozjpeg-wasm（Mozilla の JPEG エンコーダー、同じ品質で libjpeg-turbo より〜10% 良い）
• libwebp-wasm（Google の参照 WebP 実装）
• libavif-wasm（AV1 画像フォーマットエンコーダー、JPG より〜5〜10 倍遅いが最小のファイルを生成）

デコーディング（入力側）には、JPG、PNG、GIF、WebP、BMP、ICO 用にブラウザの組み込み Image と createImageBitmap を使用 —— 追加依存関係なし。HEIC は libheif-wasm（〜5 MB 追加バンドル、HEIC アップロードが検出されたときのみ遅延ロード）を通過。

興味深いデザインの選択：並べてライブプレビュー。品質スライダーをドラッグするとき、両パネルが〜60fps（小さい画像）または〜10fps（大きい画像）で更新、UI が決してストールしないよう OffscreenCanvas と Web Worker のデバウンスされた再エンコードを使用。これがあなたが推測して確認するのではなく、数秒でスイートスポットを見つけられる理由です。

バッチジョブには、navigator.hardwareConcurrency - 1 にサイズ設定された Web Worker プールを使用するので、8 コアマシンで 8 画像が並列にエンコードされます。AVIF エンコーディングがボトルネック —— 低エンドデバイスを OOM するのを避けるために AVIF の並列性を 2 にキャップ。

FAQ

Q: すべてに常に AVIF を使うべきですか？ A: 常にではありません。AVIF は同じ視覚品質で〜50% 小さいファイルを与えますが、エンコーディングは JPG より 5〜10 倍長くかかります。静的高トラフィックページには、エンコーディングコストは一度きりで帯域幅節約は永遠 —— 価値あり。動的に生成された画像（ユーザーごとのコンテンツ、リアルタイムプレビュー）には、エンコーディングコストがより重要で、WebP がより良いトレード。

Q: WebP / AVIF はすべてのブラウザで機能しますか？ A: WebP は 2020 年以降に出荷されたすべてのブラウザで機能 —— Chrome、Edge、Firefox、Safari 14+、Opera。AVIF は Chrome、Edge、Firefox、Safari 16+ で機能。Safari <16 訪問者（2026 年のトラフィックの〜3%）には、<picture><source srcset="hero.avif" type="image/avif"><img src="hero.jpg"></picture> を介して JPG フォールバックを提供。

Q: 圧縮は EXIF / GPS / カメラデータを剥がしますか？ A: デフォルトで、当社のツールはすべてのメタデータを剥がします（より小さいファイル、GPS リークなし）。カメラ設定や方向タグを保ちたい場合は「EXIF を保存」をトグル。公開共有する画像には、デフォルト剥がしが正しい選択 —— ソーシャル共有写真の GPS メタデータは現実のプライバシーインシデントを引き起こしました。

Q: JPG 品質 80 と JPG 品質 90 の違いは何ですか？ A: 品質 90 では、ファイルはほとんどの写真で視覚的に同一の出力に対して品質 80 より〜50% 大きいです。品質 80 は「4 倍ズームしない限り違いを見られない」普遍的スイートスポットです。下流で再編集される画像にのみ 90+ を使用（各編集パスは品質損失を追加；品質 90 から始めるとより多くのヘッドルームが得られる）。

Q: 写真を JPG 品質 80 に圧縮することは SEO を傷つけますか？ A: 反対 —— 速いページロードは SEO を改善します。Google の Core Web Vitals（特に LCP）はランキングに織り込まれます。画像重量は通常 LCP の遅さの #1 原因です。50% 小さいヒーロー画像はしばしば 0.5 秒速い LCP を意味し、Google が報います。

Q: 私には E コマースサイト用の 1000 製品写真があります。すべてバッチできますか？ A: はい、ただしブラウザメモリプレッシャーを避けるために 50〜100 のバッチに分割。100 画像をドロップ、ZIP を取得、繰り返し。自動化パイプラインには、ビルドに imagemin を設定（方法 3 を参照）。

今試す

並べてプレビューで、数秒で Web 用に画像を圧縮：

Image Compress ツールを開く →

画像をドロップ、フォーマットを選び、品質スライダーをドラッグ、バイトがドロップするのを見る。アップロードなし、サインアップなし。

関連読み物

• HEIC to JPG 変換：すべてのデバイスでの正しい方法 —— 圧縮前にフォーマット変換が必要な iPhone 写真用
• ブラウザサイド AI で画像を 4× アップスケール（サインアップなし） —— より少ないではなくより多いピクセルが必要なとき
• 画像 OCR：任意の画像から 100+ 言語でテキストを抽出
• メインサイトのすべての 画像ツール を閲覧

最終更新 2026-06-14。Image Compress ツールはブラウザで 100% 動作 —— 写真はデバイスを離れません。処理するファイルを収集、ログ、または分析することは決してありません。