Base64图片：方便的陷阱还是有用的工具？

你可以直接在HTML或CSS中嵌入图片。不需要单独的文件。不需要额外的HTTP请求。

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA..." />

很方便。但它带来的代价并不是立即显而易见的。

工作原理

Base64把二进制数据编码为ASCII文本。任何图片都变成你可以复制粘贴的字符串。

这个字符串比原始文件大约33%。一个30KB的图片变成40KB的字符串。

Base64何时有帮助

小图标。 200字节的图标用Base64可以节省一个HTTP请求。HTTP/2让这个不那么重要了，但对很小的图片仍然有效。

邮件HTML。 邮件客户端会阻止外部图片。嵌入的图片无需"加载图片"提示就能显示。

单文件分发。 分享离线可用的HTML。所有东西在一个文件里。

CSS中的Data URI。 嵌入在样式表中的背景图片。减少HTTP请求，代价是更大的CSS文件。

Base64何时有害

大图片。 33%的大小增加会累积。100KB的图片变成133KB的文本。

缓存。 外部图片单独缓存。Base64图片是HTML/CSS的一部分——如果页面变化，整个东西都要重新加载。

解析时间。 浏览器必须在渲染前解码Base64。比直接加载二进制文件处理更多。

维护。 更新嵌入的图片意味着编辑代码。更新外部文件更简单。

HTTP/2因素

HTTP/1.1有昂贵的连接开销。多个小图片意味着多个慢请求。

HTTP/2高效地多路复用请求。"节省HTTP请求"的论点现在更弱了。

如果你的服务器支持HTTP/2（大多数都支持），外部图片通常更好。

实用指南

1KB以下： 考虑Base64。开销很小。

1-10KB： 逐案评估。关键图标可能受益，装饰性图片可能不会。

10KB以上： 使用外部文件。大小损失不值得。

频繁更新： 外部文件。避免为图片更新而更改代码。

跨页面共享： 外部文件。缓存使多个页面加载受益。

性能测试

别猜。测试。

比较使用和不使用Base64嵌入的总页面重量。测量实际加载时间。

"正确"的答案取决于你的具体情况——图片大小、缓存策略、HTTP版本、更新频率。

替代方案

雪碧图。 把小图标组合成一张图片，用CSS显示部分。一个请求，正常缓存。

图标字体。 作为字体的矢量图标。可缩放，可用CSS样式化。

内联SVG。 对于矢量图形，内联SVG比Base64 PNG提供更多灵活性。

---

Base64图片用文件大小换取方便。这种权衡只对很小的图片或邮件这样的特殊情况有意义。对于大多数网页使用，外部文件性能更好。