画像最適化の基本 2025 — 勘に頼らない土台づくり

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

はじめに

画像最適化は「やれば速くなる」のではなく、「設計が正しければ安定して速くなる」領域です。この記事では、既存の記事（例: 画像圧縮 完全戦略 2025 ─ 画質を守りつつ体感速度を最適化する実践ガイド）で扱っている実務レベルの深さを踏襲しつつ、最初に押さえるべき土台を体系化します。

TL;DR（迷ったらここから）

• まずリサイズ、次に圧縮。転送コストはピクセル数 × 符号化効率で決まる。
• コンテンツ別にフォーマットを選ぶ（写真は WebP/AVIF、UI/ロゴは PNG/ロスレス WebP）。
• レスポンシブ配信は srcset/sizes が主役。LCP 候補だけを優先読み込み。
• 高品質マスターを保ち、変換はワンパス。再圧縮の連鎖は厳禁。
• ビルド/CDNで自動化し、長期キャッシュ + 指紋付けで配信を安定化。

なぜ今も画像最適化が効くのか

Core Web Vitals の改善はテキストやJS削減だけでなく、画像の「面積削減と選択の正しさ」に強く依存します。特に LCP 画像はユーザーの初期体験を左右するため、最初の 1〜2 秒でのダウンロード量を抑えつつ、視覚品質を落とさない設計が必要です。

原則（設計の三本柱）

1. 面積（ピクセル）を減らす: レイアウトから最大表示幅を逆算し、過剰解像度をやめる。
2. フォーマット/品質を揃える: コンテンツ種別に合わせ、過度な損失を避ける。
3. 配信を最適化する: srcset/sizes、遅延読み込み、優先度制御、長期キャッシュ。

この順番を崩さない限り、後からの拡張（例: P3 対応やアニメーション最適化）も破綻しません。リサイズの指針は 2025年のリサイズ設計 — レイアウトから逆算して 30–70% の無駄を削る に詳しく書きました。

リサイズの実務（レイアウトから逆算）

記事レイアウトのカラム幅と想定 DPR（1.5〜2 程度）から上限ピクセルを見積もり、3〜5 本の代表幅を用意します。

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

Next.js を使う場合、sizes を合っている値にするだけで過配信を一気に減らせます。

// 単一カラム記事で最大 768px を想定する例
<Image
  src="/hero-1536.avif"
  alt="ヒーロー"
  width={1536}
  height={864}
  sizes="(max-width: 768px) 100vw, 768px"
  priority
  fetchPriority="high"
/>

リサイズの計画段階では、インタラクティブな試行で上限幅の感覚を掴むと効率的です（必要に応じて 画像リサイズ を併用すると議論が早く進みます）。

フォーマット選択の基礎

• 写真: 既定は WebP、追加検証として AVIF。エッジ/肌/グラデで破綻がなければ AVIF 採用。
• UI/ロゴ/図: 透過・エッジ優先のため PNG またはロスレス WebP。
• 透過不要の写真: JPEG から WebP/AVIF へ移行するだけで大幅削減が期待できます。

本文中で図解やベンチを示す際、変換の試行は単発なら 形式変換 が便利です。大量変換やメタデータ保持の方針は後述の「自動化」へ。

圧縮品質（q）の決め方

画質劣化は「目に付く場所」で評価します。文字の縁、髪・肌の階調、空のグラデーション。ここで問題があれば q を段階的に上げ、LCP 画像のみ特別扱い（多少低めでも可）とするのが現実解です。戦略の全体像は 画像圧縮 完全戦略 2025 ─ 画質を守りつつ体感速度を最適化する実践ガイド を参照してください。

自動化の最小構成（Node.js / sharp）

小規模サイトでも回る最小構成の例です。幅の候補を配列で管理し、WebP/AVIF を吐き出します。ファイル名は指紋付け（hash）に置き換えるとキャッシュが安定します。

// scripts/build-images.ts
import sharp from 'sharp'
import fg from 'fast-glob'
import { join, basename, extname } from 'node:path'
import { mkdirSync } from 'node:fs'

const OUT = '.dist/images'
const WIDTHS = [640, 960, 1280, 1536, 1920]
mkdirSync(OUT, { recursive: true })

const files = await fg(['assets/images/**/*.{jpg,jpeg,png}'])
for (const file of files) {
  const name = basename(file, extname(file))
  for (const w of WIDTHS) {
    const p = sharp(file).resize({ width: w, withoutEnlargement: true })
    await p.webp({ quality: 78 }).toFile(join(OUT, `${name}-${w}.webp`))
    await p.avif({ quality: 58 }).toFile(join(OUT, `${name}-${w}.avif`))
  }
}

大量の既存素材がある場合は、メタデータの扱い（EXIF プライバシーや回転）を組み合わせると安全です。方針は 安全なメタデータ方針 2025 — EXIF 削除・自動回転・プライバシー保護の実務 を参照。

レスポンシブ配信の設計

srcset/sizes は「ブラウザがどの幅を選ぶか」の規約です。sizes がレイアウトとずれていると、永遠に重くなります。よくある型と落とし穴は 2025年のレスポンシブ画像設計 — srcset/sizes 実践ガイド にまとめました。LCP 候補だけ priority/preload を検討し、その他は遅延読み込みで十分です。

品質検証（人間 + 指標）

人間の目でエッジや肌の劣化を見たうえで、SSIM/PSNR/ΔE のような指標で裏取りします。簡易 ΔE の概算は以下のように書けます（厳密な CIEDE2000 ではありません）。

import sharp from 'sharp'

function dE(a: number[], b: number[]) {
  const [L1, a1, b1] = a, [L2, a2, b2] = b
  const dL = L1 - L2, da = a1 - a2, db = b1 - b2
  return Math.sqrt(dL * dL + da * da + db * db)
}

async function meanDeltaE(src: string, tgt: string) {
  const A = await sharp(src).toColorspace('lab').raw().ensureAlpha().toBuffer({ resolveWithObject: true })
  const B = await sharp(tgt).toColorspace('lab').raw().ensureAlpha().toBuffer({ resolveWithObject: true })
  if (A.info.width !== B.info.width || A.info.height !== B.info.height) throw new Error('size mismatch')
  let sum = 0, n = 0
  for (let i = 0; i < A.buffer.length; i += 4) {
    sum += dE([A.buffer[i], A.buffer[i + 1], A.buffer[i + 2]], [B.buffer[i], B.buffer[i + 1], B.buffer[i + 2]])
    n++
  }
  return sum / n
}

ビジュアル比較は横並びが王道です。必要に応じて比較用 UI を用意すると、合意形成が速まります（たとえば比較スライダーに寄り道して検証する、という使い方は自然です）。

ありがちな失敗と対策

• 画像の再圧縮チェーン: マスターを保持し、派生は常にワンパスで。
• sizes がレイアウトと不整合: ブレークポイントとカラム幅を見直す。
• ICC/色の破綻: まず sRGB に正規化し、例外だけ P3 を併用。詳細は 正しいカラー管理とICCプロファイル戦略 2025 ─ Web画像の色再現を安定させる実践ガイド。
• メタデータ漏れ: 位置情報等は既定で削除、必要項目だけ保持。

FAQ（要点だけ）

Q. AVIF は常に最小ですか？

A. 写真では小さくなりがちですが、エッジ/文字でアーティファクトが目立つ場合があります。WebP をベースに、AVIF を検証して採用可否を決めるのが現実的です。

Q. LCP 画像の品質はどこまで下げて良い？

A. まずはレイアウト上の最大幅を正しくし、sizes を合わせること。そのうえで q を段階的に下げ、視覚検証で問題なければ採用します。

まとめ

画像最適化は「ピクセル → フォーマット/品質 → 配信」の順で決めるとブレません。最初に土台を固めておくと、各論（圧縮戦略、色、メタデータ、アニメーション）を拡張しても破綻しません。次はリサイズ設計の詳細へ進んでください: 2025年のリサイズ設計 — レイアウトから逆算して 30–70% の無駄を削る。