正しいパターンを選ぶ
解像度スイッチング（resolution switching）は構図を同じに保ち、複数のファイル幅を提供します。これは製品写真、記事の図版、カードで一般的なパターンです。レンダリング幅がレイアウトで変わる場合は 480w や 1200w のような幅（w）ディスクリプタを使ってください。数値はファイルの実際のピクセル幅であり、端末のターゲットや CSS 指令ではありません。
密度スイッチング（density switching）は固定の CSS スロットに対して、高密度表示用により多くのソースピクセルを提供します。ディスクリプタは 1x、1.5x、2x のようになり、たとえば常に 160 CSS ピクセル幅のロゴやアイコンに適します。1 つの srcset 内で幅（w）と密度（x）のディスクリプタを混ぜないでください。
コンポーネントが伸縮する場合は w ディスクリプタと sizes を使う。
レンダリングされる CSS サイズが安定している場合のみ x ディスクリプタを sizes なしで使う。
sizes が選択にどう影響するかを理解する
幅ディスクリプタを使う場合、ブラウザは画像をダウンロードする前に sizes を評価します。各エントリは（任意の）メディア条件と長さを組にしており、最初に一致した条件がソースサイズを供給します。最後の無条件の長さはフォールバックです。sizes は選択のヒントであり、CSS の規則ではありません。
ブラウザはそのソースサイズと候補幅を比較して実効的な密度を計算し、表示密度、ズーム、ネットワーク状況などを考慮する場合があります。数学的に最も近いファイル名を選ぶ義務はありません。正直な候補と信頼できるスロット見積もりを提供してください。最終的な選択はユーザーエージェントの判断に委ねられます。
最初に一致するメディア条件が勝つので、リストはその最初の一致が正しくなる順で書く。
ビューポート幅として記述した 1/3 のデスクトップカードは不必要に大きな候補を選ばせる可能性がある。
実際のレイアウトから候補を導く
ページ単位ではなくコンポーネントを棚卸ししてください。ヒーロー、記事図版、商品ギャラリー、検索サムネイル、フッターロゴはそれぞれ異なるスロット幅を持つことが多いです。それぞれについて狭い状態と最大レンダリング幅、アスペクト比、トリミング挙動、初期画面での可視性を記録します。
コンポーネントの有意なスロット範囲に沿って幅を生成し、詳細が正当化される場合は高密度表示用にさらに大きいオプションを用意します。ほとんど同じファイルが多数あるとビルドとキャッシュが複雑になります；極端に小さいファイルと非常に大きいファイルだけが妥協を強いるべきです。画像変換が機能する前提で進めず、生成した URL を実際にテストしてください。
有効な src のフォールバックと、配信された比率に合う width と height 値を維持してください。これらはスペースを確保しますが、レスポンシブな CSS が最終的な寸法を変えるのを妨げはしません。
800w と表記された候補は実際に 800 ピクセル幅でなければならない。
スロットと候補計画をテンプレートやデザインの変更とともに維持する。
アートディレクションには picture を使う
アートディレクションはファイルサイズだけでなく構図を変えます。広い横長の写真は、狭い画面で主題を見えるようにするために縦長の切り抜きが必要になることがあります。picture 要素はメディアごとのソースオプションを提供し、その後に img のフォールバックを置けます。ブラウザは各 source の media、type、srcset 情報を考慮し、img は代替テキスト、寸法、フォールバック動作を担います。
各トリミングは編集上とアクセシビリティ上のレビューを行ってください。モバイル用の切り抜きが製品の詳細や alt テキストで言及している人物を削る可能性があります。alt は img に置き、画像が伝える情報や機能を説明してください。装飾目的の画像のみ alt="" を使ってください。リンクされた画像やボタン画像では外観ではなく動作を説明します。構図が変わらない場合に picture を導入しないでください：単純な幅ベースの srcset の方が簡潔です。
多くの要素が詰まったデスクトップヒーローは、スマートフォンで別の縦長トリミングを必要とする。
picture の source は type ヒントを与えつつ、幅広く使える img フォールバックを保てる。
高コストな読み込みやマークアップの間違いを避ける
よくある無駄は sizes="100vw" をすべての画像にコピーすることです。それは狭い全幅のフィギュアには合うかもしれませんが、幅が制限されたコンテナやデスクトップカードには合いません。その逆の失敗はリデザイン後に sizes が古いままであることです。CSS と sizes を一緒に更新してください。
初期表示コンテンツで重要な画像を遅延読み込み（lazy-load）してはいけません。遅延読み込みはフォールド下の画像に推奨され、視認可能なヒーローは優先的に読み込むべきです。fetch-priority は本当に重要な画像を優先できますが、広範囲の high-priority や preload ルールはパフォーマンスを損なう可能性があります。ファイル名やキャッシュ結果を証拠として頼りにしないでください。
CMS、プロキシ、またはキャッシュが誤ったディスクリプタや意図しない画像リクエストを隠すことがある。
重要なページテキストをアートディレクティッドな切り抜きにのみ依存させないでください。
リクエスト、トリミング、修正をテストする
グリッドのブレークポイントをまたぐ幅（その直上と直下を含む）で代表的なページをテストしてください。高密度設定、広いデスクトップ、スロットを変える状態も含めます。レンダリングされた寸法、トリミング、代替テキスト、視覚的なシャープネスを確認します。
Chrome DevTools では Network を開き、キャッシュを無効にしてリロードするか「Empty Cache And Hard Reload」を使い、画像リクエストをフィルタして URL、転送サイズ、ヘッダ、イニシエータ、タイミングを検査します。スロットルして遅延や無駄な処理を露呈させてください。ビューポート、デバイススケールファクタ、スロット、候補、転送バイト数、期待結果を記録します。
テンプレート、ブレークポイント、CDN、アセットパイプラインが変わるときは、これをリリースゲートにしてください。狭く修復してください：sizes を訂正し、ディスクリプタを直し、切り抜きを再生成し、フォールバックを復元するか不要な preload を削除します。空キャッシュ再読み込みで再テストしてください。
Network パネルは実際に要求された候補を記録する。
これは画像配信の挙動を検証するものであり、オリジンの容量、CDN の可用性や全体的な稼働率は検証しない。
SIU（可用性）レジリエンス管理として適用する
レスポンシブ画像は不要な転送を減らしますが、リクエスト成功を保証するものではありません。オリジンエラー、変換の未提供、サードパーティホスト、および CDN 障害には別個の継続性と回復計画が必要です。
SIU の観点では、テスト記録を使って配信の回帰を早期に検出し、責任あるテンプレートや変換ルールを特定し、リリース前に最小限の安全な修正を行ってください。可用性の事前検証とロールバック計画を併せて用意します。
失敗チェックごとにコンポーネントと画像パイプラインの所有者を割り当てる。