画像をBase64に変換

data URIとは、参照する場所そのものにファイルをインライン化したものです。src="logo.png"がブラウザに取得させたい別の何かを指す代わりに、画像のバイト列が属性の中に書き込まれます。リクエストなし、2つ目のファイルなし、404になり得るものもありません。

生のバイト列ではなくbase64である理由

こうした文字列の行き先——CSSファイル、HTML属性、JSONの値——はすべてテキストであり、PNGは違うからです。PNGのバイト列には、引用符、改行、ヌルバイトなど、文字列を終端させたりドキュメントを壊したりするものが含まれています。RFC 4648で定義されたBase64は、3バイトごとに4文字へ写像します。使うのはあらゆる場所で安全な64種の記号からなる文字集合で、入力が割り切れないときは=でパディングします。

3バイトにつき4文字——これが33%の正体です。より優れたエンコーダーが取り除けるオーバーヘッドではありません。算術の帰結です。

インライン化が得になるケース

すぐに使う小さなアセットが対象です。CSSルールの中のアイコン、1 × 1のスペーサー、外部画像がデフォルトでブロックされるHTMLメールの中のロゴ、ほかの何よりも先に表示されなければならないプレースホルダー。いずれの場合も、節約できる1リクエストのコストは、支払う33%を上回ります。リクエストにはDNS、接続の確立、往復レイテンシが伴います。モバイル回線では、1パケットで転送できたはずのファイルのために、数十ミリ秒を浪費することになります。

インライン化が間違いになるケース

大きいものや再利用するものには向きません。data URIは独立してキャッシュできません。スタイルシートに200 KBのヒーロー画像をインライン化すると、そのファイルのルールを1つでも変えるたびに、すべての訪問者が画像を再ダウンロードします。並列に取得することもできません。ドキュメントの一部なので、ドキュメントの読み込みが終わる前にダウンロードされ、高速化するはずだった描画を妨げます。さらに、遅延読み込みも、CDNによるリサイズも、対応ブラウザへのWebPでの配信もできません。

おおよその目安は数キロバイトです。それ未満なら、インライン化が通常は勝ちます。10 KB前後を超えると通常は負けます。境界を越えたとき、このページがその旨を表示します。

Content Security Policy

厳格なCSPは、許可しない限りdata URIをブロックします。画像にはimg-src 'self' data:が必要です。同じやり方でインライン化したフォントには、font-srcでもdata:の許可が必要です。インライン化したのに、CSPが強制される本番環境でだけ表示されない、という事態に遭う前に、知っておく価値があります。

Base64は暗号化ではない

はっきり言っておく価値があります。この誤解はよく見かけるからです。base64はエンコードであり、鍵は一切関係せず、誰でも元に戻せます。この方法でインライン化したものは、以前と同じ読みやすさのままです。何も隠しません。

このツールが動く場所

ブラウザ内です。ファイルはFileReaderで読み込まれ、ローカルでエンコードされます。アップロードは一切ありません。自分のソースコードに埋め込もうとしている画像にとって、これ以外の合理的なやり方はありません。