レスポンシブな画像ブレークポイント：実用的なWebPガイド

最終更新日: June 28, 2026

レスポンシブ画像ブレークポイントとは、スマートフォン、タブレット、ラップトップ、高密度スクリーンが実際にレンダリングするサイズに近いファイルをダウンロードできるように生成する画像幅のことです。少なすぎるとモバイルユーザーはデスクトップのピクセルを受け取ってしまいます。多すぎると、ビルド、キャッシュ、CDNが誰も必要としないバリアントで溢れてしまいます。

本ガイドでは、その実用的な中間点について解説します。レイアウトのスロットサイズを測定し、短いWebPラダーを生成し、srcsetとsizesを記述した後、ブラウザがCDNから正しいファイルを選択するかどうかを確認します。

簡単な回答: どのレスポンシブ画像ブレークポイントを使用すべきですか？

実際のレンダリングされる画像スロットに一致するブレークポイントを使用し、さらにRetinaスクリーン用に密度ヘッドルームを追加してください。多くの記事の画像の場合、有用なWebPラダーは480w, 720w, 960w, 1200w, and 1440wです。フル幅のヒーロー画像の場合は、デザインが実際にそれほど広い幅でレンダリングできる場合にのみ、1920wを追加してください。

CSSブレークポイントを盲目的にコピーしないでください。ページには1280pxのレイアウトブレークポイントがあるかもしれませんが、画像自体は720pxの記事カラム内にレンダリングされる場合があります。その場合、1440wの画像がすでに2xディスプレイをカバーしている可能性があり、1920wのバリアントは無駄になるかもしれません。

信頼できる方法はシンプルです。最大のCSSスロット幅を検査し、サポートしたい最も高い密度を掛け合わせ、適切な幅に丸め、ほぼ重複するものを削除します。次に、これらのファイルを正確なsizes属性とペアリングすることで、ブラウザが正しく選択できるようになります。

レスポンシブ画像ブレークポイントとは何ですか？

レスポンシブ画像ブレークポイントは、デザインのブレークポイントそのものではなく、生成されたファイル幅です。CSSブレークポイントはレイアウトを変更します。一方、画像ブレークポイントはブラウザに480w, 720w, 960w, および1440wのようなファイルのメニューを提供します。

MDNのresponsive images guideは、根本的な問題を説明しています。それは、レイアウトが完了する前に、ブラウザが必要なサイズの画像を選択するための十分な情報が必要だということです。srcset属性は候補をリストし、sizesは画像が占めるスロットを記述します。

この分離が重要です。もしsrcsetが正しいのにsizesが嘘をついている場合、ブラウザは必要以上の大きなファイルをダウンロードする可能性があります。逆に、sizesが正しくても生成されたファイルが有用な幅を飛ばしている場合、ブラウザには良い選択肢がありません。

フォーマット選択については、ブレークポイントを最新のWebフォーマットとペアリングすることが重要です。WebPは幅広いサポートのための安全なデフォルトであり、AVIFは大規模な写真ライブラリにとって追加する価値がある場合があります。フォーマットのトレードオフについては、AVIF vs WebP Comparisonで解説しています。

ブレークポイント幅はどのように選択しますか？

ソースファイルからではなく、レンダリングされるスロットから始めます。最大の可視スロットが760pxである場合、4000pxの商品写真は4000pxのWebバリアントを必要としません。必要なのは、関心のあるスクリーンでそのスロット内で鮮明に見えるのに十分なピクセル数です。

以下の順序を使用してください。

1. 最狭のモバイルレイアウト、一般的なタブレット幅、ラップトップ幅、そして広いデスクトップ幅でページを開きます。
2. CSSピクセル単位でレンダリングされる画像スロットを測定します。
3. 高密度サポートが必要な場合は、各スロットに1xと2xを掛けます。
4. 480, 720, 960, 1200, 1440, および1920のような小さなラダーに丸めます。
5. 約15パーセント未満の差がある幅は削除します。
6. デザインが使用できる最大の幅で止めます。

この記事の4つのグラフィックは、ローカルで1400 by 788としてWebPでエンコードしました。測定されたファイルはすべて35 KB未満です。アセットが平らな指導用グラフィックであるためです。同じ寸法のアメリカンカメラ写真は通常ははるかに大きくなるため、予算を設定する前に独自の出力を測定してください。

フォルダ全体にこれらの幅が必要な場合は、再現可能なリサイズステップを使用してください。Batch Resize Guideでは、マスターファイルを上書きせずに派生画像を生成するためのコマンドラインパターンを解説しています。

srcsetとsizesはどのような形であるべきですか？

ほとんどのレスポンシブコンテンツ画像には、sizesと一緒に幅記述子を使用してください。幅記述子は、各候補の実際のピクセル幅をブラウザに伝えます。一方、sizesの値は、レイアウト内で画像がどれだけ広くレンダリングされるかをブラウザに伝えます。

<img
  src="https://cdn.example.com/blog/photo-960.webp
  srcset="
    https://cdn.example.com/blog/photo-480.webp 480w,
    https://cdn.example.com/blog/photo-720.webp 720w,
    https://cdn.example.com/blog/photo-960.webp 960w,
    https://cdn.example.com/blog/photo-1440.webp 1440w"
  sizes="(min-width: 900px) 720px, 92vw"
  width="1440"
  height="810"
  alt="レスポンシブな記事レイアウトに表示される商品写真">

sizesの例は次のように述べています。ビューポートが少なくとも900px幅の場合、画像スロットは720pxであり、そうでない場合はビューポートの92パーセントです。390px幅のスマートフォンは、1440wファイルをダウンロードする代わりに、2xディスプレイのために約720wのファイルを選択できます。

web.devのresponsive imagesガイドは同じブラウザ選択の原則を示しています。つまり、画像リクエストが行われる前に、正確な候補とレイアウト情報を提供し、ブラウザに選択させることです。

切り抜きやフォーマットが変更される場合は<picture>要素を使用し、通常のサイズ変更ごとに使用するわけではありません。例えば、アートディレクションされたヒーロー画像は、モバイルで正方形のクロップ、デスクトップでワイドなクロップが必要になるかもしれません。単なる幅の変更は、通常、一つのimgと適切なsrcsetの方がシンプルです。

画像ブレークポイントは多すぎるとどうなりますか？

バリアントが多ければ自動的に良いわけではありません。追加の幅は、ビルド時間、ストレージ、キャッシュエントリ、CDN無効化の表面積、そしてレビュー作業を増やします。2つの候補が非常に近い場合、ブラウザによるバイト単位の節約が、別のファイルを正当化するには小さすぎる場合があります。

トラフィックと画像量がより細かい調整を正当化しない限り、コンパクトなセットを使用してください。記事やマーケティングページの場合、5つの幅で十分なことがよくあります。ズーム、グリッド、複数のクロップがある商品サイトではもっと必要になるかもしれませんが、手動ではなくパイプラインによって生成されるべきです。

ラダーが密すぎる兆候に注意してください：

• 同じ画像に対して640w, 700w, および760wが存在する。
• CDNログで、いくつかのバリアントがほとんど要求されないことが示されている。
• アップロードごとに10以上の派生画像を生成するため、ビルド時間が伸びる。
• エディターがどのファイルがフロントマター、Open Graph、および本文コンテンツのどれに属するか判断できない。
• QA（品質保証）がレンダリングされたページではなく、ファイル名をチェックし始める。

ラダーが疎すぎる兆候に注意してください：

• スマートフォンが通常の本文画像に対して1440wまたは1920wファイルをダウンロードする。
• デスクトップのRetinaスクリーンがソフトに見える（最大の候補が小さすぎるため）。
• ブラウザが常に同じフォールバックsrcを選択する。
• PageSpeedやLighthouseがモバイルでサイズの大きな画像をフラグ立てする。

Googleのimage SEO best practicesは、クロール可能な画像URL、有用な周囲のテキスト、および説明的なalt textを推奨しています。レスポンシブ配信はこの基本を維持する必要があります。インデックス化されるかページコンテンツとして理解される必要がある重要な画像をCSS背景に隠さないでください。

ブレークポイントはCore Web Vitalsにどのように影響しますか？

レスポンシブブレークポイントは、画像バイトがしばしば最初の画面を支配するため、パフォーマンスに影響を与えます。ヒーロー画像がLargest Contentful Paint要素でもある場合、間違ったブレークポイントは、最も重要なペイントを必要以上に大きなファイルで待機させる可能性があります。

web.devのoptimizing Largest Contentful Paintガイドでは、可能性の高いLCP画像を早期に発見可能にし、適切である場合に優先することを推奨しています。ブレークポイントはそれらの作業を置き換えるものではありません。優先されたファイルが正しいサイズであることを保証するだけです。

ファーストビューの画像について：

1. スペースを確保するために明示的なwidthとheightを設定します。
2. 可能性の高いLCP画像を遅延読み込み（lazy loading）することは避けます。
3. fetchpriority="high"は、本当にそれが必要な画像にのみ使用します。
4. 初期レイアウトのためにsizesを正確に保ちます。
5. DevToolsで選択されたcurrentSrcを確認します。

フォールトビューの画像について：

1. 通常のギャラリー画像や記事画像を遅延読み込みします。
2. より小さなクロップで十分な場合を除き、同じブレークポイントラダーを使用します。
3. リサイズする後で圧縮し、前ではありません。
4. alt textは可視の画像に特化させます。
5. デスクトップだけでなく、モバイルネットワークのウォーターフォールも確認します。

問題が主にヒーローアセットの発見遅延である場合は、Critical Image Extractionを読んでください。ファイルが単に重すぎる場合は、マークアップを変更する前にImage Compression Ratio Guideを実行してください。

公開前に実行すべきCDNチェックは何ですか？

ブレークポイントは、最終的なURLが機能するときにのみ完了します。クリーンなMarkdownドラフトであっても、CDNパスが間違っている場合、オブジェクトのコンテンツタイプが間違っている場合、またはページが誤ってローカルの/blog/...ファイルを参照している場合は失敗する可能性があります。

この公開前のチェックを実行してください：