2025年のリサイズ設計 — レイアウトから逆算して 30–70% の無駄を削る

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

はじめに

同じピクセルをそのまま運ぶか、必要最小限だけに減らして運ぶか。体感速度の差はここで決まります。本稿では「レイアウトから逆算する」という原則のもと、再現可能なリサイズ設計をまとめます。

レイアウトから逆算する理由

画像の適正サイズは、コンテンツの表示領域と端末の DPR（Device Pixel Ratio）で決まります。推測ではなく、カラム幅やブレークポイントから式で定義することで、チームで共有できるルールになります。

上限ピクセル = min(コンテナ幅, ビューポート幅) × 想定DPR

例: 記事本文カラム 768px、DPR=2 を上限とするなら 1536px が上限。代表幅を 640/960/1280/1536 と決めて srcset を構成します。

srcset/sizes の基本パターン

sizes は「このレイアウトではこの幅で表示される」という宣言です。ここが間違っていると、ブラウザは大きすぎる画像を選び続けます。

// 単一カラム記事
sizes="(max-width: 768px) 100vw, 768px"

// カードグリッド（2列→3列）
sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw"

Next.js の <Image> を使う場合でも同じです。sizes をレイアウトと一致させるだけで、過配信を劇的に減らせます。詳しいパターンは 2025年のレスポンシブ画像設計 — srcset/sizes 実践ガイド を参照してください。

代表幅の決め方（実務）

• 上限幅をまず決める（例: 1536px）
• 3〜5 段の代表幅を用意（640/960/1280/1536 など）
• JPEG/WebP/AVIF の生成はビルドで自動化（ワンパス原則）

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

LCP 画像の特別扱い

LCP 候補（ヒーローや主要ビジュアル）は、priority/fetchPriority="high"/preload を検討します。ただし「必要以上に大きい画像を作らない」という前提が最優先。品質の下げ幅は視覚検証で判断します（基礎は 画像圧縮 完全戦略 2025 ─ 画質を守りつつ体感速度を最適化する実践ガイド）。

よくある落とし穴

• デザイン余白を含めて上限幅を大きく見積もる → 実効描画領域はもっと小さい
• sizes を固定文字列のまま放置 → レイアウト変更で過配信化
• 高解像度マスターの欠如 → 変換が再圧縮チェーン化

事前計画と台帳化

• ページタイプごとに最大表示幅（本文/ヒーロー/カード列）を記録
• DPR とレイアウトの関係から上限ピクセルを算出し、代表幅 3〜5 段を台帳化
• コンポーネントごとに sizes の宣言テンプレを用意し、デザイン変更に合わせて更新

自動化のすすめ

• Sharp などで代表幅の一括書き出しをスクリプト化（CI 実行）
• LCP 候補の prefetch/preload を条件付きで自動注入
• 差分検知（代表幅の欠落・過剰生成）を CI でチェック

LCP 改善プレイブック

• まず上限ピクセルの設計を正しく。次に priority/fetchPriority を適用
• 画像の表示領域を早期に確保（width/height 指定または CSS アスペクト比）で CLS=0 を目指す
• sizes の条件を実測し、過剰サイズ配信を避ける（転送量を最小化）

よくある質問（FAQ）

• Q. 代表幅は何段が良い？
  • A. 多くのケースで 3〜5 段で十分です。キャッシュ効率と運用コストのバランスを取りましょう。
• Q. sizes の更新が大変です
  • A. コンポーネント化して列数やブレークポイントから自動生成すると保守が楽になります。

実運用ケーススタディ

• ブログ本文（最大768px）
  • 代表幅: 640/960/1280/1536、sizes="(max-width: 768px) 100vw, 768px"
  • LCP 候補なし。loading="lazy" で十分
• トップのヒーロー（最大1440px、DPR=2 を考慮）
  • 上限ピクセル: 1440×2=2880、代表幅: 1280/1600/1920/2240/2560/2880
  • priority + fetchPriority="high" + Preload を評価
• カード 3 列（コンテナ 1100px）
  • 列幅 ≒ 31vw → 代表幅: 480/720/960/1280/1536、sizes="(max-width: 640px) 100vw, (max-width: 1024px) 46vw, 31vw"

代表幅テンプレ（目安）

• 480/720/960/1280/1536（一般的な本文・カード）
• 640/960/1280/1536/1920（広い本文や横長）
• 1280/1600/1920/2240/2560/2880（大型ヒーロー）

計測手順（現場向け）

1. DevTools で currentSrc と表示幅を確認（sizes の条件と一致？）
2. Lighthouse/WebPageTest で LCP・転送量の変化を比較
3. 代表幅の段数を増減し、キャッシュヒット率と転送量のトレードオフを評価
4. 画像の width/height 指定 or CSS aspect-ratio で CLS を 0 に維持

トラブルシュート

• いつも大きい画像が選ばれる → sizes の条件が過大。実表示幅を再測定
• モバイルでボケる → 代表幅の最小段が不足。480/640 を追加
• LCP が改善しない → Preload の as/image と imagesrcset/imagesizes が一致しているかを確認

まとめ

リサイズは「最初の一手」。上限ピクセルの設計→代表幅の段構成→sizes の整合という順で固めれば、過配信を 30–70% 抑えつつ画質を保てます。計測で微調整し、LCP 候補に限って priority/Preload を適用しましょう。続きはパターン集へ: 2025年のレスポンシブ画像設計 — srcset/sizes 実践ガイド。