When to Use Base64 Encoded Images (And When Not To)

3年前、私はチームの若手開発者がReactアプリケーションのすべてのコンポーネントにBase64エンコードされた画像を追加するのを見ました。「速い！」と彼は主張し、インライン画像がHTTPリクエストを排除すると述べた記事を指さしました。2週間後、私たちのバンドルサイズは8.7MBに膨れ上がり、3Gでの初期ページロードは14秒かかり、CDNコストは謎のうちに3倍になっていました。その高価なミスは、Base64エンコーディングは理論上は素晴らしそうに聞こえる道具の一つですが、誤って適用すると負担になることを学ばせてくれました。

私はサラ・チェンで、ここ12年間、貧弱なスタートアップからフォーチュン500企業まで、さまざまな会社でパフォーマンスエンジニアとして過ごしてきました。5000万人の月間ユーザーを抱えるeコマースプラットフォームから、誰も最適化が必要だと思わなかった内部ダッシュボード（その通りでした）まで、さまざまなものを最適化してきました。その間に、Base64エンコーディングを見事に使用したことも、アプリケーションパフォーマンスを破壊されたことも見てきました。違いは常に、どう機能するかだけでなく、いつ実際に意味があるかを理解することに帰着します。

この記事は、私が始めたときに持っていればよかったと思うメンタルフレームワークを提供する試みです。私たちはBase64エンコーディングの技術的現実に深く掘り下げ、これが輝く特定のシナリオを探求し、より重要なことに、実際に有害となる状況を特定します。最後には、「速いと読んだ」という理由を越えた、実際の、測定可能な推論を持つ意思決定プロセスを持つことができるでしょう。

技術的現実: Base64が実際に画像に与える影響

始めに、多くの開発者が軽視する不快な真実から始めましょう: Base64エンコーディングはあなたの画像をおおよそ33%大きくします。時々ではありません。常にです。これはバグや実装の詳細ではなく、基本的な数学です。

バイナリ画像データをBase64にエンコードするとき、8ビットのバイトを安全なASCIIのサブセットから6ビットの文字に変換しています。3バイトのバイナリデータは4つのBase64文字になります。これが33%のオーバーヘッドの由来です: 4/3 = 1.33。30KBのJPEGは40KBのBase64文字列になります。100KBのPNGは133KBに膨れ上がります。このサイズの増加は、圧縮される前、ネットワーク転送される前、他の何かが起こる前のことです。

実際に画像をBase64エンコーディングすると何が起こるかというと、元のバイナリファイル——例えば、45KBの製品画像——が生のバイトとして読み込まれます。各バイトは0から255の数値です。エンコーディングアルゴリズムは、3バイトずつ（合計24ビット）を取り、それを4つの6ビットのチャンクに分割します。各6ビットのチャンクは、安全なASCII文字の64のうちの1つ（A-Z、a-z、0-9、+、/）にマッピングされます。その結果は次のような長い文字列になります: "/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a..."

この文字列は、HTML、CSS、またはJavaScriptに直接埋め込むことが安全です。それが利点です。しかし、その安全性はサイズとの交換です。そして、サイズはほとんどの開発者が理解しているよりも重要です。特に、モバイルネットワークでは、すべてのキロバイトが実際のミリ秒のロード時間に変換されるからです。

2つ目の技術的現実: Base64文字列はバイナリデータほど効率的に圧縮できません。HTTPで通常のJPEGをgzip圧縮して提供すると、サイズが15-20%削減されることがあります。同じJPEGのBase64エンコードバージョンをgzipすると、サイズ削減は5-10%になるかもしれません。エンコーディングプロセスは、圧縮しにくいパターンを作成します。したがって、33%のサイズペナルティは、圧縮が考慮されると40-45%のペナルティになることがよくあります。

私は昨年、10KBから200KBの製品画像500点のデータセットでテストを実施しました。Base64エンコーディングとgzip圧縮の後の平均サイズ増加は37%でした。5KB未満の画像では、ペナルティは42%に近い結果でした。100KBを超える画像でも35%のままでした。数学から逃れることはできません。

唯一の真の利点: HTTPリクエストの排除

では、なぜ誰もがBase64エンコーディングを使用するのでしょうか？特定のシナリオでは、HTTPリクエストを排除することがサイズペナルティよりも価値があるからです。このことが実際に真実である場合について正確に述べましょう。

"Base64エンコーディングはHTTPリクエストを排除するのではなく、それをJavaScriptバンドル内に隠すだけであり、パフォーマンスを最適化するのはずっと難しい方法で影響を与えます。"

すべてのHTTPリクエストにはオーバーヘッドがあります。ブラウザはDNSルックアップ（キャッシュされていない場合）を行い、TCP接続を確立し、TLSハンドシェイク（HTTPS用）を実行し、リクエストヘッダーを送信し、サーバーの応答を待ち、応答ヘッダーを受信し、最終的にコンテンツをダウンロードします。HTTP/1.1では、このオーバーヘッドはかなりのものであり、良好な接続では通常100-300ms、高遅延のモバイルネットワークでは500-1000msです。

小さな画像をBase64としてインラインすると、これらすべてを排除できます。画像データは、それを含むHTML、CSS、またはJavaScriptファイルと共に到着します。別のリクエストはなく、追加のラウンドトリップもなく、接続のオーバーヘッドもありません。小さな画像——アイコン、小さなロゴ、UI要素——の場合、特に高遅延接続では、レンダリングが速くなる可能性があります。

私は23の小さなアイコン（各アイコンの平均が2.1KB）を、別のPNGファイルとしてロードしたダッシュボードアプリケーションでこの効果を測定しました。300msの遅延を持つシミュレートされた3G接続では、すべてのアイコンを読み込むのにかかる合計時間は、接続のオーバーヘッドとブラウザのリクエストキューイングのために4.7秒でした。それらをBase64に変換し、CSSにインラインすると、同じアイコンがスタイルシートのダウンロードの一部として1.2秒で読み込まれました。これは33%のサイズ増加にもかかわらず、3.5秒の改善です。

しかし、ここに重要な詳細があります: この利点は、HTTPリクエストのオーバーヘッドが追加バイトのコストを超えた場合にのみ存在します。2KBのアイコンの場合、Base64の667バイトのオーバーヘッドは300msの遅延に比べて微小です。200KBの画像の場合、66KBのオーバーヘッドは致命的であり、どれだけの遅延を節約しても補うことはできません。

私のさまざまなネットワーク条件でのテストに基づくクロスオーバーポイントは、4KBと10KBの間にあります。4KB未満では、Base64エンコーディングがしばしば勝ちます。10KBを超えると、ほぼ常に負けます。4KBと10KBの間では、特定の遅延プロファイルやキャッシング戦略によって異なります。

重要な使用ケース: 小さなUI要素のためのデータURI

Base64エンコーディングの最も正当な使用方法は、初期表示に不可欠な小さくて頻繁に使用されるUI要素です。私は、アイコン、小さなロゴ、ローディングスピナー、ユーザーが即座に目にする必要がある重要なグラフィックスについて話しています。

私が金融サービス会社のために取り組んだプロジェクトでは、折りたたみ部に表示される15の小さなアイコンを持つダッシュボードがありました。これらのアイコンはコアナビゲーションの一部であり、ページロードの最初の1.5秒以内に表示される必要がありました（私たちのパフォーマンス予算）。各アイコンは約1.8KBのSVGファイルでした。

私たちには、別々のファイルとして提供する、スプライトシートにまとめる、またはBase64データURIとしてインラインするという3つの選択肢がありました。WebPageTestを使用して50の異なるネットワークプロファイルでこの3つのアプローチをテストしました。結果は明確でした: 重要なCSS内のBase64データURIは、私たちのスピードインデックスを平均して0.4秒短縮し、高遅延のモバイル接続での改善が最も顕著でした。

この作業を可能にした重要な要素は、サイズ（各2KB未満）、重要性（最初のレンダリングに必要）、頻度（すべてのページで使用）の3つでした。これらの要素の1つでも異なっていたら、決定は変わっていたでしょう。