データURI vs 外部ファイル：完全比較
画像、フォント、その他のアセットについてデータURIと外部ファイル参照を比較。HTTP/2の影響、キャッシュ、CDNの利点、実際のシナリオを分析。
Performance
詳細な説明
データURI vs 外部ファイル
インラインデータURIと外部ファイル参照のどちらを選択するかは、ファイルサイズ、使用頻度、キャッシュ戦略、ネットワークプロトコルに依存する微妙な判断です。
機能比較
| 機能 | データURI | 外部ファイル |
|---|---|---|
| HTTPリクエスト | なし | ファイルごとに1 |
| ブラウザキャッシュ | 親ドキュメントと共に | 独立 |
| ファイルサイズ | +33%（Base64） | 元のサイズ |
| CDNサポート | 親ドキュメント経由 | 直接CDNキャッシュ |
| ページ間共有 | 各ページで重複 | 一度キャッシュ、どこでも使用 |
データURIが勝つ場合
- 小さなファイル（<4 KB） — HTTPオーバーヘッドがBase64オーバーヘッドを超える
- クリティカルレンダーパス — First Contentful Paint前に必要な画像
- 一回限りの画像 — 1つのページでのみ使用
- オフライン要件 — Service Workerがドキュメント全体をキャッシュ
外部ファイルが勝つ場合
- 大きなファイル（>10 KB） — 専用圧縮がより効率的
- 共有リソース — 複数ページの同じ画像がキャッシュの恩恵を受ける
- 頻繁に変更されるアセット — 独立したキャッシュ無効化
- HTTP/2環境 — リクエストマルチプレクシングがオーバーヘッドを削減
ハイブリッド戦略
最適なアプローチは両方を組み合わせることが多いです：
- インライン: クリティカルなファーストビューのアイコンとロゴをデータURIとして
- 外部: 大きな画像、共有アセット、ファーストビュー以下のコンテンツ
- ビルドツール自動化: WebpackやViteに閾値を自動処理させる
ユースケース
大規模なeコマースサイトのWebpackビルドパイプラインを設定しており、画像アセットの自動データURIインライン化の最適な閾値を設定する必要がある場合。