Base64は本来、使うべき技術ではない｜それでも使う条件

:::note ※Base64を使うか迷っている人のための「入口」記事です :::

正直に言うと、私はBase64を常用しない

Base64は便利な技術だと言われている。画像をHTMLに埋め込める。リクエスト数を減らせる。

でも正直に言うと、私はBase64を常用しない。仕方なく使う技術だと思っている。

理由は単純。33%肥大化する。キャッシュが効かない。デバッグしにくい。

この記事は、それでもBase64を使う条件と、使わない条件をまとめたもの。

🚀 今すぐ変換 → Base64エンコーダーを開く

「リクエスト減らせる」と思って、アイコン画像をCSSにBase64で埋め込んだ。

20個のアイコン。1個10KBだから合計200KB。Base64化して約270KB。

**CSSファイルが300KB超えた。**初回読み込みが遅くなった。キャッシュも効きにくい。

外部ファイルにしてCDNに置いた方が速かった。

APIでBase64エンコードした画像を受け取っていた。ある日、画像が表示されなくなった。

原因を調べた。Base64文字列の途中に改行が入っていた。どこかの処理で混入した。

**Base64は文字列なので、どこで壊れたか分かりにくい。**外部ファイルなら「ファイルが壊れている」と分かる。Base64は「文字列のどこかがおかしい」としか分からない。

クライアントから「画像はBase64で送ってください」と言われた。仕様だから従った。

10MBの画像をBase64化した。約13MB。JSONに入れた。レスポンスが遅い。タイムアウトした。

Base64は「小さいファイルを埋め込む」技術。大きいファイルに使うと破綻する。

迷ったら外部ファイル。Base64は「仕方なく使う」技術。

使う条件は限られている。

これは仕様。100KBのファイルが133KBになる。避けられない。

HTMLやCSSに埋め込むと、画像だけキャッシュできない。HTML全体をキャッシュすることになる。

外部ファイルなら「この画像が壊れている」と分かる。Base64は「この長い文字列のどこかがおかしい」としか分からない。

「リクエスト数を減らせる」はHTTP/1.1時代の話。HTTP/2では並列取得が効率化されている。

Base64は「便利な技術」ではなく「仕方なく使う技術」。

10KB以下のアイコン、インライン必須の場面でのみ使う。それ以外は外部ファイル。

迷ったら外部ファイル。Base64は最終手段。