データURIサイズ：インライン化vs外部ファイルの判断

データURIのサイズトレードオフ

データURIの中心的な問題は：HTTPリクエストの排除がBase64エンコーディングによる追加バイトよりも時間を節約するのはいつかということです。答えはファイルサイズ、ネットワーク状況、キャッシュ動作に依存します。

33%ルール

Base64エンコーディングは常にデータサイズを約33%増加させます。これはエンコーディングアルゴリズムに固有です：3バイトのバイナリが4文字のBase64出力を生成します。

損益分岐分析

HTTP/1.1接続の場合：

• リクエストあたりの平均HTTPオーバーヘッド: 500-2000バイト
• 損益分岐点: 4-6 KB未満のファイルがインライン化で恩恵を受ける

HTTP/2接続の場合：

• マルチプレクシングによるリクエストあたりのオーバーヘッド削減
• 損益分岐点が低くなる: 2-4 KB未満のファイルがインライン化で恩恵を受ける

サイズ閾値と推奨

元のサイズ	アクション	理由
1 KB未満	常にインライン化	HTTPオーバーヘッドが支配的
1-4 KB	通常インライン化	ほとんどのネットワークでパフォーマンスゲイン
4-10 KB	コンテキストを考慮	クリティカルレンダーパスのみインライン化
10-32 KB	インライン化を避ける	Base64オーバーヘッドが大きすぎる
32 KB超	インライン化しない	キャッシュ付き外部ファイルを使用

圧縮への影響

Base64テキストは圧縮率が低く、gzipが効果的に圧縮できない高エントロピー出力を生成します。gzip圧縮されたドキュメントにおけるBase64データURIの実際のオーバーヘッドは、Base64文字列が周囲の構造化テキストよりもgzipアルゴリズムの効率が低いため、33%を超える可能性があります。