2025年のレスポンシブ画像設計 — srcset/sizes 実践ガイド

公開: 2025年9月18日 · 読了目安: 2 分 · 著者: Unified Image Tools 編集部

はじめに

レスポンシブ画像は、単に「複数サイズを用意する」では不十分です。sizes をレイアウトに合わせ、ブラウザの選択アルゴリズムに正しいヒントを渡すのが本質です。本稿は運用のための実戦ガイドです。

まず sizes を決める（核心）

sizes は「この条件では表示幅はこれくらい」と宣言する属性です。ここが正しければ、ブラウザは最適な srcset の候補を選べます。

// 単一カラムの記事レイアウト（最大 768px）
// 768px 以下では 100vw、超えたら 768px 固定
sizes="(max-width: 768px) 100vw, 768px"

// カード 2→3 列（ギャップ含む実効 46vw/31vw 程度）
sizes="(max-width: 640px) 100vw, (max-width: 1024px) 46vw, 31vw"

代表幅は 1.5〜2 倍刻みが扱いやすいです。例: 480/720/960/1280/1536。

srcset を支えるビルド

srcset は生成を自動化し、ヒューマンエラーを排除します。Sharp 例:

import sharp from 'sharp'
const WIDTHS = [480, 720, 960, 1280, 1536]
async function buildSet(input: string, base: string) {
  for (const w of WIDTHS) {
    await sharp(input).resize({ width: w, withoutEnlargement: true })
      .webp({ quality: 78 })
      .toFile(`${base}-${w}.webp`)
  }
}

Next.js Image を使う場合は sizes を正しく書くだけで、出し分けは自動です。詳細は 2025年のリサイズ設計 — レイアウトから逆算して 30–70% の無駄を削る。

LCP とプリロード

ヒーロー画像など LCP 候補は、適切な sizes に加えて以下を検討します:

• priority / fetchPriority="high"
• 先読み <link rel="preload" as="image" imagesrcset="..." imagesizes="...">
• 過剰な解像度を避ける（上限幅×DPR のルールを厳守）

基礎的な圧縮の考え方は 画像圧縮 完全戦略 2025 ─ 画質を守りつつ体感速度を最適化する実践ガイド を参照。

アートディレクションと picture

アスペクトや構図をサイズごとに変えたい場合は picture を使います。

<picture>
  <source media="(min-width: 1024px)" srcset="/hero-wide-1280.webp 1280w, /hero-wide-960.webp 960w" sizes="(min-width:1024px) 960px">
  <source media="(max-width: 1023px)" srcset="/hero-tall-720.webp 720w, /hero-tall-480.webp 480w" sizes="(max-width:1023px) 92vw">
  <img src="/hero-tall-720.webp" alt="...">
</picture>

注意: picture を用いても sizes の思想は同じです。メディア条件ごとに「表示幅は何 px（何 vw）」かを宣言します。

アイコンと SVG

• 単純なロゴやアイコンは SVG を第一候補に。CSS カラー適用やメディアクエリで柔軟に対応可能。
• PNG が必要な場合でも、小サイズ向けに 1x/2x を明示して srcset を分けると配信効率が良くなります。

<img src="/icons/icon-32.png" srcset="/icons/icon-32.png 1x, /icons/icon-64.png 2x" width="32" height="32" alt="">

PWA 用アイコンやマニフェストは ファビコン＋Manifestパック と ファビコン生成 を参照。

よくある失敗

• sizes を 100vw 固定で済ませる → 実際はカード列で 33vw なのに過配信
• breakpoints と列数の変更に追従しない → デザイン更新で突然重くなる
• 代表幅を細かくしすぎる → キャッシュ効率が落ち、効果が薄い

チェックリスト（運用）

• [ ] 各テンプレートの最大表示幅と DPR を定義したか
• [ ] sizes がレイアウトと一致しているか（Storybook/ブラウザで実測）
• [ ] LCP 画像に priority など適用したか
• [ ] 代表幅は 3〜5 段で十分か
• [ ] picture は本当に必要か（まずは sizes で解決できないか）

仕上げに、リサイズ設計の全体最適は 2025年のリサイズ設計 — レイアウトから逆算して 30–70% の無駄を削る を、フォーマット選定は フォーマット変換の戦略 2025 — WebP/AVIF/JPEG/PNG を使い分ける指針 を参照してください。

診断とデバッグのコツ

• DevTools の Network パネルで実際に取得された画像の寸法/転送量を確認（想定と一致しているか）
• Elements パネルで img の computed size と currentSrc を確認（sizes が効いているか）
• モバイル/デスクトップで DPR を変えて再検証（2x/3x 端末の過取得を検出）
• LCP 候補は Performance パネルで特定し、preload の効果をプロファイル

応用パターン（コンポーネント）

• グリッドカードの列数を props で受け取り、sizes を自動生成
• picture + media でアートディレクション。CSS の breakpoints 定義と 1 箇所で同期
• loading="lazy" と viewport-in のタイミング最適化を組み合わせ、CLS を 0 に保つ

ハンズオン: 既存ページの棚卸し

1. 最大表示幅（本文・サイドバー・カード列）を洗い出す
2. 画像ごとに上限ピクセルと 3〜5 段の代表幅を定義
3. LCP 候補を優先実装（preload/priority も同時に）
4. 実測で転送量・LCP を比較し、sizes の条件を微調整

FAQ

• Q. sizes はどのくらい細かく書くべき？
  • A. 実表示幅が変わる境界（ブレークポイント）に限定し、2〜4 条件に収めると保守しやすいです。
• Q. picture と sizes のどちらを優先？
  • A. まず sizes で十分か検討し、アートディレクションが必要なときのみ picture を使います。
• Q. Next.js <Image> で必要なことは？
  • A. 正しい sizes の宣言と、必要なら priority/fetchPriority の付与です。srcset は自動生成に任せて OK です。