Web画像のファイルサイズと形式の実践ガイド
すべての画像がネットワーク、デコード、メモリー、描画の資源を使います。有用な予算はページ固有で、画像の役割、利用者、キャッシュ、ビューポート、品質要件を考慮します。以下の範囲はテストの出発点であり、万能な合否基準ではありません。
用途別の開始予算
以下は抑制的なWeb配信予算の例です。JPEG、WebP、AVIFの結果は上下し得るため、素材、エンコーダー、表示サイズ、実地性能、目視確認に応じて調整してください。
| 用途 | ピクセル幅 | 目標ファイルサイズ | 推奨フォーマット |
|---|---|---|---|
| 全幅ヒーローバナー | 1600〜1920px | 100〜200 KB | WebP または AVIF |
| ブログ本文画像 | 800〜1200px | 60〜150 KB | WebP |
| 商品画像（メイン） | 800〜1000px | 80〜150 KB | WebP |
| 商品サムネイル | 300〜400px | 20〜50 KB | WebP |
| カード・プレビュー画像 | 400〜600px | 30〜80 KB | WebP |
| アバター・プロフィール写真 | 64〜128px | 5〜15 KB | WebP または JPEG |
| ロゴ | 可変 | 5〜30 KB | SVG（推奨）または PNG |
| アイコン | 24〜48px | 1〜5 KB | SVG |
| 背景パターン | 200〜400px（タイル） | 10〜30 KB | WebP または PNG |
| SNSシェア用（OG画像） | 1200 × 630px | 80〜150 KB | JPEG または WebP |
開始範囲を自分の予算に変える方法
HTTP Archiveのページ重量レポートには現在の分布データがありますが、世界の中央値はあなたの利用者ではありません。Googleが公表する「良好」なLCPしきい値は訪問の第75パーセンタイルで2.5秒です。実地データとウォーターフォールを使い、サーバー応答、リソース検出、転送、デコード、描画遅延へ時間を配分します。
ページ全体の転送予算から始め、利用者価値の高い画像に多く割り当てます。レイアウト、画像数、利用者、品質要件が変わったら表の範囲を見直してください。
形式は主要な変数の一つ
同じ素材でもエンコーダーと品質目標によりサイズは大きく変わります。この表は比較すべき挙動であり、1200ピクセルの写真に共通するベンチマーク結果ではありません。
| フォーマット | 例：1200px写真 | 相対サイズ |
|---|---|---|
| 可逆PNG写真 | 写真内容では大きくなりがち | 基準 |
| JPEG（品質80） | 適切な品質設定なら効率的 | 互換性の基準として使用 |
| WebP（品質80） | JPEGより小さくなる場合があるため見た目を比較 | 素材とエンコーダーによる |
| AVIF（品質65） | 効率的な場合があるが符号化と対応状況も重要 | 素材とエンコーダーによる |
比較によってはWebPやAVIFがJPEG出力より小さくなりますが、全素材とエンコーダーに通用する固定割合はありません。どちらの現代形式も透明度に対応します。詳しくはWebPとAVIFのガイドをご覧ください。
JPGからWebP、掲載された入力形式向けのAVIF変換、またはツールに表示された形式向けの一括変換で候補を作成できます。
ピクセル寸法：見落とされがちな倍増効果
ピクセル数、画像内容、ビット深度、メタデータ、形式、エンコーダー、設定がサイズに影響します。不要な寸法を減らすと、エンコーダーが表現するデータを大幅に減らせることがよくあります。
4000 × 3000画像は12 MP、1200 × 900画像は1.08 MPで、ピクセル数が91%少なくなります。チャンネル数と精度が同じならエンコーダーに渡す非圧縮ラスターが大幅に減りますが、最終的なバイト削減は内容と設定にもよります。
レスポンシブの目安：想定表示幅と密度に近い候補を用意します。表示枠が720 CSSピクセルなら1440px候補が2×画面に合う場合がありますが、ズーム、切り抜き、レイアウト変更、より高い密度で選択は変わります。srcsetとsizesで選択肢を記述します。
Vizuaの画像サイズ変更でレイアウトに必要な候補を作り、用途に応じてJPEGまたはPNG圧縮を試します。すでに最適化された素材は小さくならない場合があります。
圧縮品質：最適なバランスを見つける
フォーマットとサイズが決まったら、最後の調整が圧縮品質です。3つの要素を組み合わせた実例を見てみましょう。
例示手順：4000 × 3000のマスターから始め、配信用セットの外に保管します。
- 表示枠と対象密度に合う場合、1200 × 900などの候補へサイズ変更する
- 選んだ開始品質でWebP候補を書き出し、実ファイルを確認する
- 対応する構成ならAVIF候補を書き出し、サイズ、見た目、符号化コストを比較する
用途を満たす最小の候補を選びます。最終的な削減と見た目の差は実際の素材と出力から決まり、例の寸法だけでは決まりません。
フォーマット別の品質設定の詳細は、品質を落とさずに画像を圧縮する方法をご覧ください。
特殊なケース
ECサイトの商品ページ
商品写真はストアが対応するズームでも役立つ必要があります。保護したマスターからレスポンシブ候補を作り、細部を確認し、一覧、メイン表示、ズームに別々の予算を設定します。マーケットプレイスのアップロード要件はストア配信と異なる場合があります。
写真ポートフォリオ
ポートフォリオはレスポンシブなプレビューを配信し、適切なら意図した高解像度表示を提供できます。レイアウトと想定画面から寸法とバイト予算を決め、質感、グラデーション、カラープロファイルを確認します。
SNSシェア用（Open Graph）
Open Graph画像の推奨事項と対応形式はプラットフォームごとに異なり、変わる可能性があります。1200 × 630のJPEGまたはPNGは一般的な出発点ですが、現在の配信先ガイドとプレビューを確認してください。クローラーはページの遅延読み込みとは別に取得します。
ページあたりの総画像予算
性能目標からページ予算を作ります。テスト用の初期配分例は次のとおりです。
- ヒーロー画像 1枚：約150 KB
- コンテンツ画像 3〜4枚：各約100 KB、合計300〜400 KB
- サムネイル・アバター・アイコン：合計約50 KB
この例は速度を保証しません。ギャラリーや商品一覧では画面外の適切な画像を遅延できますが、遅延画像も要求時にはデータを使い、スクロールへ影響し得ます。代表的な端末と回線で初期性能と操作時性能を測定してください。
よくある質問
Webサイト画像に適したファイルサイズはどれですか？
万能なKB目標はありません。ページの性能目標、画像数、ビューポート、利用者の回線、キャッシュ動作、必要品質から予算を決めます。メイン画像はサムネイルより多くのバイトを使う価値がある場合もありますが、検出時期や優先度もサイズと同じほど重要です。一律の上限ではなく、実地LCPを測り代表的なファイルを確認してください。
品質を落とさず画像ファイルを小さくするには？
マスターを保管し、表示枠と端末密度に合う寸法を生成し、適切な形式を比較しながら実際の出力を見てエンコーダーを調整します。品質尺度はエンコーダーごとに異なり、見分けられない結果を保証する設定はありません。非可逆再圧縮の繰り返しは避けます。
Googleが推奨する画像の最大ファイルサイズはありますか？
Googleは画像に共通するKB上限を公表していません。PageSpeed Insightsはテストしたページの転送削減候補やLCP問題を示せますが、適切な予算は読み込み経路全体によります。ラボ診断と自分の利用者の実地データを併用してください。
画像ファイルのサイズはSEOに影響しますか？
画像が大きい、検出が遅い、デコードが遅い、安定した寸法なしで描画される場合、利用体験やCore Web Vitalsに影響します。Googleはより広いランキングシステムの中でページ体験シグナルを使いますが、1ファイルの削減が順位変更を保証するわけではありません。画像が本当にボトルネックか測定してください。
商品画像にはどのピクセル寸法を使うべきですか？
最大表示枠、ズーム動作、ストアが対応する端末密度に候補を合わせます。固定幅1枚ではなくレスポンシブなソースを使い、想定ズームで商品詳細を確認し、ページと利用者からバイト予算を決めます。マーケットプレイスの取り込み要件はストアの配信サイズと異なる場合があります。