2026年のWeb画像圧縮テクニック：速度・画質・Core Web Vitals

ハウツー

このガイドの使い方

1

現在の画像の重さを監査する

ブラウザーのDevToolsやページ速度ツールを使って、ページの重みに最も寄与している画像を特定します。ファーストビュー内の画像、特にLCP候補を優先してください。

2

画像の種類ごとに適切なフォーマットを選ぶ

写真にはWebPを使用します。スクリーンショット、ロゴ、UIグラフィックにはPNGを使用します。アイコンやイラストには可能な限りSVGを使用します。

3

品質目標を設定し視覚的にテストする

写真のWebPは品質80から始めます。圧縮後の出力を、意図した表示サイズで元画像と比較してください。差が見えなければ下げ、見える劣化があれば上げます。

4

圧縮する前にリサイズする

800px幅で表示される画像に3000px分のデータは不要です。まず実際の表示サイズにリサイズし、その後で圧縮します。このステップだけで、フォーマット変換単体よりもファイルサイズを削減できることがよくあります。

5

デプロイしてCore Web Vitalsを検証する

圧縮した画像をデプロイした後、PageSpeed Insightsテストを実行してLCPスコアを確認します。LCP要素が画像ベースであれば、改善は測定可能なはずです。

目次

• はじめに：なぜ2026年も画像圧縮がCore Web Vitalsの重要なシグナルであり続けるのか
• なぜ画像圧縮が依然として重要なのか
• ロスレスとロッシー：判断ガイド
• フォーマット別の圧縮率
• 品質しきい値のテスト
• ページ速度の前後比較
• サーバー側とブラウザー側の圧縮
• ツールの比較
• 画質を落とさずに一括圧縮する方法

---

はじめに：なぜ2026年も画像圧縮がCore Web Vitalsの重要なシグナルであり続けるのか

毎年、「画像はもうWebのパフォーマンスのボトルネックではなくなる」という予測が飛び交います。ブロードバンドの速度は上がりました。モバイルネットワークは改善されました。CDNは普及しました。HTTP/2やHTTP/3によって並列アセット配信はより効率的になりました。それでも2026年、画像の重さは大多数のコンテンツサイト、eコマースストア、メディアにおいて、ページ読み込み時間への最大の要因であり続けています。

これが変わらない理由は、画像への需要が配信能力と同じペースで成長したからです。かつて2、3枚だった画像を含むページは、今では10枚や15枚になりました。ヒーロー画像は800px幅から1600px以上に成長し、Retinaディスプレイに対応しています。かつて1枚の写真しか表示しなかった商品ページは、今では8つの角度を表示します。画像の総転送量は、それを配信するインフラの成長よりも速く伸びました。

その結果、画像圧縮は「解決済みの問題」でも「過去の懸念」でもありません。それは今日のWebパフォーマンスにおける最もてこ効きの大きい技術的選択の一つであり、圧縮の詳細は「圧縮するかどうか」と同じくらい重要です。このガイドでは、2026年に最良の結果をもたらすテクニック、ツール、判断フレームワークを解説します。

---

なぜ画像圧縮が依然として重要なのか

LCPとCore Web Vitals

2021年以降、検索順位に影響を与えているGoogleのCore Web Vitalsフレームワークには、主要な指標としてLargest Contentful Paint（LCP）が含まれています。LCPは、ページの読み込み開始から最も大きな可視要素の描画が完了するまでの時間を測定します。ほとんどのコンテンツページでは、最も大きな可視要素は画像——ヒーロー画像、注目の商品写真、記事のイラスト——です。

LCPは実際のユーザーセッションで測定されるため（実験室条件ではなく）、そのパフォーマンスはLCP画像の実際のダウンロード時間に大きく左右されます。最適化されていない1.2MBのJPEGヒーロー画像は、信号が中程度の地域の4G接続では、適切に圧縮された400KBのWebP同等品よりも大幅に長くダウンロードに時間がかかります。LCPスコアが「Poor（4秒超）」か「Good（2.5秒未満）」かの違いは、しばしば画像の重さだけで決まります。

モバイルユーザーと現実の帯域幅

ブロードバンド速度は絶対値として向上しましたが、Webトラフィックの相当部分は依然として、帯域幅が変動するセルラー接続のモバイル端末から来ています。通勤中に公共交通機関で閲覧する人、混雑した商店街の買い物客、接続環境の薄い地域のユーザー——こうしたユーザーはすべて、画像の重さが目に見える遅延を生む接続環境にいます。

平均的なケースに合わせて設計すると、遅い接続のユーザーの末尾は常に苦しみます。3〜5 Mbpsの接続で快適に読み込めるほど十分に圧縮することで、より速い接続のユーザーを含め、すべてのユーザーに高速な体験を提供できます。

エネルギー消費

画像の重さには、あまり議論されませんが実際の環境への影響があります。不必要に大きな画像を配信すると、ファイルを送信するデータセンター、それを運ぶネットワークインフラ、それを受信して描画する端末の、あらゆる段階でエネルギーを無駄にします。トラフィックの多いサイトでは、適切な画像圧縮による総合的エネルギー節約は無視できません。これは、サステナビリティ目標を持つ大組織にとってますます重要になる考慮事項です。

---

ロスレスとロッシー：判断ガイド

圧縮における根本的な決定は、ロスレス（可逆）とロッシー（非可逆）のどちらを使うかです。これを正しく行うことは、どの特定のツールを選ぶかよりも重要です。

ロスレス圧縮

ロスレス圧縮は、情報を一切捨てずに、画像データをより効率的に符号化することでファイルサイズを削減します。展開された画像は元画像と同一です。PNGはロスレス圧縮を使用します。ロスレスWebPやロスレスAVIFも選択肢として存在します。

ロスレスが適しているのは：

• テキスト、UI要素、図表を含むスクリーンショット——導入されたノイズが見えて気を散らすような場合
• ロゴやブランドグラフィック——色の正確さとエッジのシャープさが要件となる場合
• さらに編集されるソースファイル——編集前にソースをロッシーで圧縮すると、各編集サイクルで蓄積するノイズが生じる
• 特定のピクセル値に意味がある画像——科学画像、医療画像、技術図表

ロスレス圧縮の制限は、写真のような複雑な画像に対して、ロッシー圧縮ほどのファイルサイズ削減ができないことです。写真のロスレスPNGはすべての元データを含み、うまく調整されたロッシー圧縮が達成できるものに比べて压缩率が低くなります。

ロッシー圧縮

ロッシー圧縮は、人間の観察者が気づきにくい画像データを特定して削除することで、ファイルサイズを削減します。JPEGはロッシーです。ロッシーWebPやロッシーAVIFはその現代的な同等品です。ロッシー圧縮の背後にある知覚モデルは、人間の視覚が色、輝度、詳細をどう知覚するかの研究に基づいています——たとえば、低コントラスト領域の高周波詳細は、知覚画質への寄与が最小であるため削除されます。

ロッシー圧縮が適しているのは：

• 写真や写真的な画像
• ヒーロー画像、商品撮影、編集用画像
• 表示サイズで10〜20％の知覚品質低下が見えないが、ファイルサイズを50〜70％削減できるような画像

重要な原則は、ロッシー圧縮の劣化はソース解像度ではなく表示サイズで評価されるということです。100％のネイティブ解像度で画像を確認したときに見えるノイズも、ブラウザーで400px幅で表示されれば完全に見えなくなることがあります。

---

フォーマット別の圧縮率

典型的な圧縮率を理解することは、現実的な期待値を設定するのに役立ちます。以下の表は、広範な写真コンテンツのサンプルにおける典型的な範囲を示しています。

フォーマット	圧縮タイプ	非圧縮に対する典型的なサイズ	備考
JPEG（品質80）	ロッシー	非圧縮の8-15％	長年使われるベースライン
PNG	ロスレス	非圧縮の30-60％	写真よりグラフィック向け
WebP（品質80）	ロッシー	非圧縮の5-10％	JPEGより25-35％小さい
WebP（ロスレス）	ロスレス	非圧縮の20-40％	場合によりPNGより大きい
AVIF（品質60-70）	ロッシー	非圧縮の3-7％	WebPより30-50％小さい

これらの範囲は目安であり正確ではありません。実際の圧縮率は画像の内容に大きく依存します。平坦な色の画像は複雑なテクスチャよりよく圧縮され、低ノイズ画像は高ISO写真よりよく圧縮され、大きな均一領域を持つ画像は全体に高周波詳細を持つ画像よりよく圧縮されます。

実践的な要点：Web写真には、品質80のWebPが信頼できる出発点です。同等の品質設定のAVIFは、さらに明らかに小さいファイルになります。インターフェース画像やスクリーンショットには、PNGまたはロスレスWebPのロスレス圧縮が適しています。

---

品質しきい値のテスト

ロッシー圧縮機の品質設定は、ファイルサイズと視覚的忠実度のトレードオフを制御する主要なダイヤルです。自分のコンテンツに合わせてこのダイヤルをどう校正するかを理解することは、一般的な品質推奨に従うことよりも価値があります。

見えない劣化の原則

ロッシー圧縮は、品質設定を下げるほど目立つ視覚的ノイズを導入します。しかし品質設定と知覚される劣化の関係は線形ではなく、表示条件に強く依存します。画像編集ソフトで100％ズームで確認したときに明らかに見えるノイズも、同じ画像を意図したWebのサイズで通常表示したときには完全に見えないことがあります。

つまり、品質は常に実際の表示サイズでテストすべきです。圧縮した画像をブラウザーで開き、実際に表示される寸法で見て、元画像と視覚的に比較してください。画像編集ソフトでフル解像度のファイルを見て品質を評価しないでください——そうすると品質を不必要に高く設定し、ファイルサイズ削減の機会を逃すことになります。

下限を見つける

最適な品質設定を見つける実践的な手順：

1. 写真は品質80から始めます。
2. 表示寸法で圧縮後の出力を元画像と比較します。
3. 表示サイズで画像が視覚的に同一なら、品質を5下げて繰り返します。
4. 視覚的な劣化が明らかなら、品質を5上げてその値を受け入れます。
5. 最適な品質は、表示サイズで劣化が見えない最も低い値です。

ほとんどのWeb写真では、このプロセスは品質70〜85の間に落ち着きます。複雑な高周波テクスチャ（草、布、髪）の画像は、なめらかなグラデーションや平坦な面の画像よりも高い品質設定を必要とする傾向があります。

コンテンツタイプによる違い

異なるコンテンツタイプは異なる品質下限を持ちます。ポートレート写真の肌の色は圧縮ノイズに特に敏感です——なめらかな肌の部分のバンディングは、風景写真よりも低い品質設定で目立つようになります。色の正確さと食欲を引く見た目に依存するフードフォトは、無地の背景の商品撮影よりも高い品質設定を必要とする傾向があります。自分の公開コンテキストに特有の品質要件を理解することで、より精密な最適化が可能になります。

---

ページ速度の前後比較

画像圧縮がページ速度に与える実際の影響を測定することは、作業を検証しその価値を伝えるために不可欠です。以下のツールとアプローチは、信頼できる前後測定を提供します。

何を測定するか

追跡する主要な指標はLCP——最も大きな可視要素を描画する時間——です。画像の多いページでは、これはほぼ常に画像です。二次的な指標には、画像圧縮の影響を受けないTotal Blocking Time（TBT）や、寸法が指定されていない場合に画像の影響を受ける可能性があるCumulative Layout Shift（CLS）があります。

絶対的なページの重さについては、ブラウザーのNetworkタブに表示される画像の合計重さを追跡します。「Img」タイプのリクエストでフィルターし、最適化の前後の転送サイズ合計をメモします。

測定ツール

PageSpeed Insights（WebインターフェースまたはAPI）は、ラボデータとフィールドデータの両方を提供します。最適化前にテストを実行し、LCP値と画像ごとの具体的なサイズ推奨を記録し、最適化を適用してデプロイし、再度テストを実行します。「Opportunities」セクションには、実装前にフォーマット変換と圧縮による期待節約が表示され、どの画像を最初に最適化するかを優先するのに役立ちます。

ブラウザーのDevTools内のLighthouseは、同じ測定をローカルで提供し、デプロイ前のテストに役立ちます。「Properly size images」と「Serve images in next-gen formats」の監査は、画像最適化が解決する問題に特に対応しています。

結果の解釈

LCPが600msから400msに改善すると、LCPスコアが33％改善され、「改善が必要」と「良好」の分類の違いになることがあります。しきい値が重要です：2.5秒未満は良好、2.5〜4秒は改善が必要、4秒超は不良です。ページを2.6秒から2.3秒に動かす最適化は、2.0秒から1.7秒に動かす最適化よりも、絶対的な改善が小さくても順位への影響が大きくなります。

---

サーバー側とブラウザー側の圧縮

画像圧縮は、ワークフローのいくつかのポイントで発生できます：画像の作成時またはアップロード時、ビルドプロセス中、CDNエッジでのオンデマンド、あるいはJavaScriptツールを使ったブラウザー内です。それぞれのアプローチには異なるトレードオフがあります。

サーバー側の圧縮

サーバー側の圧縮——ビルドプロセス中、CMSアップロードパイプラインの一部、またはCDNエッジのいずれであれ——は、最も一貫性がありスケーラブルなアプローチです。一度実行され、結果はキャッシュされます。すべての訪問者は、デバイスや接続に関係なく最適化された画像を受け取ります。クライアントリソースを消費しません。継続的にコンテンツを公開するサイトにとって、サーバー側の圧縮が正しい長期的アーキテクチャです。

ビルドパイプラインに統合されたツール（Node.js環境のSharpや、Astroの組み込み画像最適化など）を使ったビルド時圧縮は、デプロイプロセスの一環として画像を変換・圧縮します。実行時のオーバーヘッドはゼロで、予測可能でバージョン管理された出力を生成します。

CDNベースの圧縮とフォーマット変換はエッジで実行され、ビルド時処理より柔軟になることがあります——リクエスト側デバイスのAcceptヘッダーやビューポート幅に基づいて、異なるフォーマットとサイズのバリアントを配信できます。トレードオフはコストと、CDN変換ルールの設定の複雑さです。

ブラウザー側の圧縮

ブラウザー側の圧縮——JavaScriptとCanvas APIを使ってブラウザー内で圧縮アルゴリズムを実行する——は、さまざまなシナリオに適しています。ユーザーが入力と出力を制御する単発のファイルに便利です。ユーザーがアップロードに同意する前にサーバーに保存したくない、ユーザー送信コンテンツには正しい選択です。サーバー側パイプラインを設定せずに、特定の品質設定でのファイルの見え方を手早く確認したい開発者に便利です。

ブラウザー側の圧縮の制限は、クライアントのデバイス上で実行され、そのCPUとメモリを消費することです。大きな画像の大量バッチでは遅くなることがあります。また、ユーザーが明示的に処理したファイルにのみ影響し、Webサイト上の既存コンテンツの配信は改善しません。

/tools/image-compressor/ のImgKit Image Compressorは、圧縮をローカルで実行するブラウザー側ツールであるため、ファイルがサーバーにアップロードされることはありません。機密性の高い画像や秘密の画像を圧縮する場合に特に関係します。

---

ツールの比較

画像圧縮ツールの状況は大きく成熟しました。主なツールカテゴリは、異なるワークフローコンテキストに対応しています。

ビルドツールの統合

現代的なフレームワーク（Astro、Next.js、Nuxtなど）で構築されたサイトでは、画像最適化は第一級のフレームワーク機能またはよく保守されたプラグインとして利用できます。Astroの <Image /> コンポーネントは、ビルド時に画像を自動的に変換・最適化します。Next.jsのImageコンポーネントは、最適化と遅延読み込みの両方を処理します。これらの統合は、技術スタックが対応しているサイトにとって最良の選択です——最小限の設定で済み、通過するすべての画像に自動最適化を提供します。

CDN画像サービス

画像変換機能を持つ画像CDNやサービスは、エッジでフォーマット変換と圧縮を処理します。変換パラメータ付きの標準画像URLを受け取り、適切な出力を配信します。これらのサービスはコストを追加しますが柔軟で、異なるブラウザに異なるフォーマットを配信するためにコード変更を必要としません。ビルド時処理が遅くなるような、大規模な画像ライブラリを持つ高トラフィックサイトに適しています。

ブラウザーベースのツール

ブラウザーベースの圧縮ツールは、個別のファイルや小さなバッチ——単発の最適化タスク、アップロード前の画像準備、異なる品質設定での見え方のテスト——に最も役立ちます。インストール、サーバー、ビルド設定は不要です。主な制限はスループットです。ブラウザーで数百の画像を処理するのは非現実的です。

---

画質を落とさずに一括圧縮する方法

ロッシー圧縮の文脈での「画質を落とさない」とは、数学的にロスレスという意味ではなく、表示サイズで知覚できる品質低下がないという意味です。目標は、それを下回ると劣化が見え始める品質しきい値を見つけ、ファイルサイズを最大限削減しながらその上に留まることです。

ステップ1：現在の画像の重さを監査する

ブラウザーのDevTools、Lighthouse監査、またはページクロールツールを使って、最も重い画像を特定します。ファイルサイズで並べ替え、ページの重みに最も寄与する画像を優先します。ファーストビュー内の画像とLCP候補に最も注意を払うべきです。

ステップ2：表示寸法にリサイズする

圧縮する前に、画像を表示される最大寸法にリサイズします。800px幅で表示され、3000px幅のソースから読み込まれる画像は、必要なピクセルデータの4倍を持っています。/tools/image-resize/ の画像リサイズツールまたはビルドツールの統合を使って、800px（2x Retinaの場合は1600px）にリサイズします。

ステップ3：フォーマットと品質を選ぶ

写真：品質80のWebPを出発点にします。表示サイズで知覚できる劣化がないことが視覚確認できれば、70まで下げます。インターフェース画像やスクリーンショット：硬いエッジのコンテンツにはPNG、代替としてロスレスWebP。

ステップ4：処理して検証する

ブラウザーベースのツールの場合は、ファイルを処理し、それぞれをブラウザーウィンドウで開いて実際の表示寸法での品質を確認します。ビルドツールの統合の場合は、ビルドを実行し、デプロイ環境で出力を元画像と比較します。

ステップ5：デプロイして測定する

最適化されたページに対してPageSpeed InsightsまたはLighthouseを実行し、LCPの改善を確認します。問題が解決されたことを確認するため、「Efficiently encode images」と「Properly size images」の監査をチェックします。

画像圧縮と検索エンジンパフォーマンスの交差点に関する詳しいガイダンスについては、画像圧縮によるSEOとページ速度のガイドを参照してください。フォーマット固有のガイダンスについては、Webサイトの最適な画像サイズと、eコマース向けの商品画像の圧縮のガイドを参照してください。

よくある質問

WebP圧縮にはどの品質設定を使うべきですか？

写真のWebPでは品質75〜85が適切な開始範囲です。品質80であれば、一般的な表示サイズでは元画像と見た目の差がほとんどわかりません。最終決定する前に、実際の表示サイズでテストしてください。

ロスレス圧縮とロッシー圧縮の違いは何ですか？

ロスレス圧縮は画像データを一切捨てずにファイルサイズを削減します。ロッシー圧縮は人間の目に気づかれにくいデータを削除します。スクリーンショットやUIグラフィックにはロスレス、写真にはロッシーが適しています。

圧縮でLCPスコアはどのくらい改善できますか？

LCP要素がヒーロー画像であるページでは、非圧縮のJPEGから適切に圧縮されたWebPに変えることで、LCP要素のダウンロード時間を40〜70％短縮でき、LCP分類が「Poor」から「Good」へ改善することがよくあります。

画像はサーバー側とブラウザー側のどちらで圧縮すべきですか？

サーバー側の圧縮（ビルドツールやCDN画像サービスを使用）は一貫性があり、すべての訪問者をカバーできます。ブラウザー側の圧縮は、単発のファイルやサーバーパイプラインを管理していない場合に便利です。

画像を圧縮するための最良の無料ブラウザーツールは何ですか？

ImgKit Image Compressorはブラウザー内でローカルに動作するため、ファイルがサーバーにアップロードされることはありません。JPG、PNG、WebPに対応し、品質コントロールと目標ファイルサイズのオプションがあります。

リサイズは圧縮と同じくらい効果がありますか？

むしろそれ以上の場合が多いです。両方の次元で必要なサイズの2倍の大きさの画像は、ピクセルデータを4倍持っています。圧縮前に表示サイズにリサイズすることは、最も効果的なファイルサイズ削減ステップになることがよくあります。