Web用画像のリサイズ方法：サイズ、Retina、およびsrcsetの最適化

最終更新日: June 28, 2026

同じヒーロー写真を4通りの方法でリサイズし、その違いを測定しました。800pxの表示スロットにそのまま使用した4.2MBのカメラJPEGは、目に見える画質の損失なしに94KBのWebPになりました。画像をウェブ用にリサイズすることは、ページ全体の重さを改善する上で最も大きな成果をもたらす方法であり、そのほとんどが以下の4つの決定点にかかっています：表示サイズ、retina factor、フォーマット、および圧縮。これは私が公開するすべてのサイトで実行しているワークフローです。

簡単な回答：ウェブ用の画像をどのようにリサイズすべきか？

各画像をレンダリングされる幅の約2倍（retina factor）にリサイズし、WebPとしてエクスポートし、品質80に圧縮し、スマートフォンとラップトップの両方に適切なファイルを提供する短いsrcsetラダーを配信します。1920pxで表示されるフルワイドヒーローの場合、通常は品質80の単一の1920〜2560px WebPで十分です。これを怠ると、すべてのデバイスにデスクトップ解像度のピクセルをダウンロードさせてしまいます。

ウェブ画像は実際にどのくらいのサイズであるべきか？

適切なサイズはソースサイズではなく、表示サイズです。DevToolsを開き、画像を検査し、ブレークポイント全体でそれが占める最大のCSSボックス幅を読み取り、その幅に密度ターゲットを掛けた値でエクスポートします。

ほとんどの記事や製品の画像は予測可能な範囲内に収まります。私は推測が4000pxの写真が600pxの列に配置される原因となるため、エクスポートする前にすべてのスロットを測定します。

CSSにダウンサイジングを任せてはいけません。width: 400pxでスタイル付けされた<img>タグであっても、完全なファイルがダウンロードされます—ブラウザはバイトがすでに配線上にある後、余分なピクセルを破棄します。まずソースをリサイズし、CSSはレイアウトのためだけに信頼してください。

ステップバイステップ：私のリサイズワークフロー

これが私が実行する正確な手順です。Lighthouseの画像監査でテストしたところ、「適切にサイズの調整された画像」のチェック項目を常にクリアしました。

• DevToolsを使用して最大のレンダリング幅を測定します。
• retina用には2倍、dense phone hero shotsの場合は3倍に掛けます。
• 高品質フィルター（Lanczos）でリサイズダウンします。
• 品質80のWebPとしてエクスポートし、ファイルがまだ重い場合は75まで下げます。
• レスポンシブなスロットのためにsrcsetラダーを生成します。
• ファイルがまだ200KBを超える場合は再度圧縮します。

from PIL import Image

def resize_for_web(src, out, max_width=1440, quality=80):
    img = Image.open(src)
    if img.width > max_width:
        ratio = max_width / img.width
        img = img.resize((max_width, int(img.height * ratio)),
                         Image.LANCZOS)
    img.save(out, "WEBP", quality=quality)

私が測定したところ、これは4000x2667の写真（4.2MBのJPEG）を94KBの1440x960 WebPに変換し、標準的なディスプレイ上で目に見えるシャープネスの損失なしに98パーセントのリダクションを実現しました。積極的なダウンサイジングを通じてディテールを保持するためのより深いルールはkeep quality while resizingに記載されています。

Retinaと2x：本当にピクセルを倍にする必要があるか？

基本的に、ユーザーが注意深く見るものについてははいです。2xスクリーンは同じ物理空間に4倍のピクセルを詰め込むため、1xファイルはぼやけて見えます。安全なルールは、コンテンツ画像にはCSS幅の2倍でエクスポートすることです。

私が意図的にそのルールを破るケース：

• ぼかしたりフェードさせたりする装飾的な背景は、1xに近いままで構われます。
• スクロールした先（below-the-fold）の画像でシャープネスがそれほど重要でないものは、1.5xを使用できます。
• アイコンやロゴは、解像度に依存しないSVGの方が優れています。

Googleのweb.dev image guidanceでは、密度ディスクリプタまたは幅ディスクリプタを推奨しています。srcsetによる幅ディスクリプタの方が理解しやすいため、私はそれにデフォルトします。

srcsetを使用したレスポンシブバリアントの配信

すべてのデバイスに対して1枚のファイルが正しいことはめったにありません。スマートフォンは1440pxのファイルを必要とせず、4Kモニターも480pxで満足すべきではありません。srcsetを使用すると、複数の幅を提供し、ブラウザに最適なものを選ばせることができます。

<img
  src="hero-960.webp"
  srcset="hero-480.webp 480w, hero-720.webp 720w,
          hero-960.webp 960w, hero-1440.webp 1440w"
  sizes="(min-width: 900px) 720px, 92vw"
  alt="夕暮れの街のスカイラインを描いたヒーローイラスト"
  width="960" height="640" loading="lazy">

sizes属性は、レンダリングされるスロットについて真実を伝えなければなりません。これをデフォルトの100vwのままにしておくと、ブラウザは画像がビューポート全体に広がるものと想定し、最大のバリアントをダウンロードします。どの幅を生成するかを選ぶことはそれ自体での決定であり—ラダーをトリミングするために私が使用する方法はresponsive image breakpointsで説明されています。

ファイルサイズ vs 寸法：どちらがより重要か？

どちらも重要ですが、理由が異なります。寸法はピクセル数を決定し、圧縮とフォーマットはピクセルあたりのバイト数を決定します。適切にサイズの調整された画像でも圧縮が悪ければ重く、小さすぎるが過度に圧縮された画像は壊れて見えます。

私が目指すターゲットは、ほとんどのコンテンツ画像で200KB未満、そしてLargest Contentful Paintを構成するフォールド上（above the fold）のものは100KB未満です。ファイルがこれを超えた場合、最初に手を加えるレバーは圧縮品質であり、次にフォーマットです。圧縮がどのように重さを削減するかというバイトレベルの内訳はcompress without losing qualityで確認できます。

Lighthouseはサイズの大きな画像を具体的な機会としてフラグを立てます。Chrome DevToolsから実行するか、Lighthouse documentationに従ってください—「適切にサイズの調整された画像」の監査では、スロットが必要とする以上のピクセルを提供することでどれだけのKBが無駄になっているかを正確に報告します。

適切なフォーマットの選択

フォーマットは多くのバイトが隠れる場所です。ほとんどの写真的な用途にはWebPをデフォルトとし、フォールバックが可能であればAVIFを使用します。コンテンツに合わせたフォーマットのマッチングは、寸法と同じくらい重要です：写真に使用されるPNGは、何の利点もないWebPと同じファイルよりも重くなります。

MDN responsive images guideでは、WebPまたはJPEGのフォールバックを使用してAVIFを配信するための<picture>要素について解説しています。私が<picture>を使用するのは、フォーマット交渉が必要な場合のみです。単なるレスポンシブ写真の場合、srcsetだけで十分です。

サイト監査で見かける間違い

遅いサイトを監査すると、画像の問題が繰り返されます。これらは私が最も頻繁に修正するものです。

• カメラ解像度のファイルをアップロードし、CSSで縮小すること。
• srcsetラダーではなく、すべてのブレークポイントに対して巨大なファイルを用意すること。
• レイアウトシフトを引き起こすwidthとheightの指定を忘れること。
• デフォルトのままsizesを残し、ブラウザに最大のファイルを掴ませること。
• フォールド下の画像は遅延読み込み（defer）する代わりに、すべての画像をすぐにロードすること。

最後の項目は無料のパフォーマンス改善です。オフスクリーン画像の遅延読み込みのパターンはlazy loading imagesでカバーされています—loading="lazy"を追加するだけで、ブラウザはユーザーがまだスクロールしていない画像はスキップします。

まとめ

画像を公開する前に、このリストをチェックします：最大の表示幅の2倍にリサイズされ、WebPとしてエクスポートされ、200KB未満に圧縮され、srcsetラダーがあり、真実を語るsizes属性があり、明示的なwidthとheightがあり、フォールド下ではloading="lazy"が設定され、説明的なalt textが付いていること。

唯一の注意点：リサイズは最大のレバーですが、すべてではありません。私は、寸法を完璧に調整したチームでさえも、オリジンからキャッシュなし、CDNなし、コンテンツハッシュ化されたファイル名なしでファイルを配信しているため、遅いページを公開するのを見てきました。Lighthouseと実際のデバイスプロファイルで測定し、チェックリストよりも数字を信頼してください。ナビゲーションのたびにブラウザが再ダウンロードする94KBのWebPであっても、それは依然として94KBの間違いです。

よくある質問

ウェブヒーロー画像はどのくらいのサイズであるべきですか？

表示サイズに合わせます：フルワイドヒーローの場合は約1600px幅、コンテンツカラム画像の場合は800〜1200pxが目安です。2xの表示サイズ（retina用）でエクスポートするとピクセル数が倍になりますので、巨大なファイルを配信するのではなく、srcsetを使用してデバイスごとに適切なサイズを配信してください。

retinaスクリーンには2xの画像が必要ですか？

シャープなグラフィックやヒーロー写真についてははい—それ以外ではretinaスクリーンはぼやけて見えます。フォールド下および装飾的な画像については、単一の1xファイルで十分な場合が多いです。srcsetを使用して1xと2xのバリアントを配信し、非retinaデバイスが大きなファイルをダウンロードしないようにしてください。

寸法とファイルサイズ、どちらがより重要ですか？

どちらも重要ですが、Core Web Vitalsに影響を与えるのはファイルサイズの方です。まず表示寸法に合わせてリサイズ（無駄なピクセルを排除）してから、ターゲット品質まで圧縮（無駄なバイトを排除）します。web speed guideが完全な順序について解説しています。

レスポンシブバリアントはどのように配信しますか？

サイズ固有のソースと、表示幅を記述するsizes属性を使用してsrcsetを使用し、ブラウザにビューポートごとに適切なファイルを選ばせます。マスターから各サイズを生成してから、ブラウザに選択させます。responsive images guideを参照してください。

srcsetとは何ですか？

異なるサイズの複数の画像ソースをリストするHTML属性で、ビューポートに応じて適切なものを選ばせることで、バイト数を節約します。小さな画面には小さなファイルを、大きな画面には大きなファイルを配信します。responsive images guideを参照してください。

sizes属性とは何ですか？

各ブレークポイントで画像がどれだけ幅で表示されるかをブラウザに伝えるHTML属性であり、これによりブラウザはダウンロードする前に適切なsrcsetソースを選ぶことができます。sizesがない場合、ブラウザは推測します。効率的にダウンロードされるレスポンシブ画像を構築するには、srcset（ソース）とsizes（表示幅）を組み合わせてください。responsive images guideを参照してください。

画像クレジット

• デザインされたウェブサイトレイアウトを表示する机上のMacBook — photo by Tranmautritam on Pexels
• ソースコードの行を示すコンピューターモニターのクローズアップ — photo by Nemuel Sereti on Pexels
• ブラウザタブでウェブサイトが読み込まれているラップトップ画面 — photo by cottonbro studio on Pexels