Next.js を使う場合、WebP 画像を配信するルートが 2 つあります: next/image にリクエスト時に自動変換させるか、デプロイ前に WebP に事前変換して直接ファイルを配信するかです。 どちらもブラウザに WebP を届けますが、パフォーマンス特性は大きく異なります。この記事では各 アプローチで実際に何が起きるかを詳細に分析し、どちらを選ぶべきかを解説します。
next/image のオンデマンド変換の仕組み
ブラウザが Next.js の画像最適化パイプラインを通じて画像をリクエストすると、サーバーは 最初のリクエストで以下を実行します:
- ディスクからソース画像を読み込むか、リモート URL から取得
- 画像を生のピクセルバッファにデコード
- リクエストされた品質とサイズで WebP に再エンコード
- 結果をディスクキャッシュに書き込み（通常
.next/cache/images/） - WebP レスポンスをブラウザにストリーミング
以降のリクエスト（同じ URL、同じ幅、同じ品質）では、Next.js はキャッシュされた WebP をディスクから読み込み、再エンコードをスキップします。キャッシュは URL + 幅 + 品質 + フォーマットでキー管理されるため、同じ画像の 400px と 800px レンダリングは別々にキャッシュされます。
コールドスタートのペナルティ
各画像バリアントの最初のリクエストは遅くなります。中級クラウド VM（vCPU 2 基）での典型的なエンコード時間:
| ソース画像 | サイズ | 初回リクエスト遅延 | キャッシュヒット遅延 |
|---|---|---|---|
| 2 MB JPEG | 3000×2000 → 800px | ~340 ms | ~4 ms |
| 5 MB PNG | 4000×3000 → 1200px | ~820 ms | ~6 ms |
| 500 KB JPEG | 1200×900 → 400px | ~90 ms | ~3 ms |
サーバーレスデプロイ（Vercel、AWS Lambda）では、インスタンスが起動するたびにコールドスタートが 発生します。高トラフィックページはキャッシュがすぐ温まりますが、低トラフィックやロングテール ページは、サーバーが冷えた状態で訪問するすべての新規ユーザーに遅い初回レンダリングを提供します。
事前変換 WebP: 静的アプローチ
代替策はビルド時変換ステップを実行することです — sharp、cwebp、または Picovert の PNG to WebP 変換ツールを使って — 結果の .webp ファイルをリポジトリにコミットするか、CDN にアップロードします。 その後、マークアップで .webp を直接参照します:
<img src="/images/hero.webp" width={1200} height={630} alt="Hero" />
または、Next.js のレスポンシブリサイズは使いたいがフォーマット変換は不要な場合、next/image に .webp ファイルを渡すと、オプティマイザーが WebP 入力を 検出して再エンコードをスキップし、必要に応じてリサイズのみ行います。
比較まとめ
| 要素 | next/image オンデマンド | 事前変換 WebP |
|---|---|---|
| 初回リクエスト遅延 | 遅い（エンコードオーバーヘッド） | 速い（静的ファイル） |
| 以降のリクエスト | 速い（ディスクキャッシュ） | 速い（CDN/静的） |
| レスポンシブリサイズ | 自動（srcset） | 手動またはカスタム |
| フォーマット交渉 | 自動（AVIF/WebP/JPEG） | フォーマットごとに手動 |
| デプロイの複雑さ | 追加ステップなし | ビルドステップが必要 |
| サーバーレスコールドスタート | 影響を受ける | 影響なし |
| ストレージコスト | バリアントごとにキャッシュ増加 | ビルド時に固定 |
next/image オンデマンド変換を使うとき
- ユーザー生成コンテンツ — 画像がランタイムにアップロードされ、ビルド時に 不明なため事前変換が不可能。
- 大規模な画像ライブラリ — 数百〜数千の商品画像をすべて事前変換すると CI に 数分かかる。
- 人気ページにトラフィックが集中 — 温かいキャッシュが実際にコールドスタートを 稀にする。
- AVIF サポートが必要 —
next/imageはブラウザごとに最適な フォーマットを交渉。ビルド時 AVIF 変換は遅く、対応ブラウザへの AVIF 配信と WebP フォールバックは オプティマイザーなしでは実装が複雑。
事前変換 WebP を使うとき
- マーケティング/ランディングページ — 画像数が少なく高トラフィックで、 TTFB の数ミリ秒が重要。
- CDN を使った SSG（静的サイト生成） — ビルド後、WebP ファイルはサーバー 処理なしでエッジノードから直接配信。
- 予測不可能なコールドスタートがあるサーバーレスデプロイ — エンコード遅延を 排除することで一貫した TTFB を保証。
- 頻繁に変更されない画像 — ロゴ、ヒーロー画像、OG サムネイルなど、 ビルドステップのコストが無視できるレベル。
ハイブリッドアプローチ
ほとんどのプロダクション Next.js アプリは両方の戦略を組み合わせると効果的です: クリティカルな above-the-fold 画像（ヒーロー、LCP 候補）の小セットを WebP に事前変換し、next/image に動的または重要度の低い画像のロングテールを処理させます。これにより、重要な画像でほぼゼロの LCP 遅延を実現しつつ、全画像カタログに対する大規模なビルドオーバーヘッドも避けられます。
まとめ
next/image のオンデマンド変換は、ほとんどのアプリで正しいデフォルトです。ただし、 クリティカルレンダーパスにある画像 — ヒーロー画像、above-the-fold サムネイル、OG 画像 — は WebP に事前変換することで、コールドスタートペナルティを完全に排除し、サーバーの状態に 関係なく一貫して速い初回レンダリングを提供できます。2 つの戦略は互いを補完します。