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

三年前，我看到我团队的一位初级开发者在我们 React 应用程序的每个组件中添加 Base64 编码的图像。“这更快！”他坚持说，并指着他找到的一篇文章，声称内联图像消除了 HTTP 请求。两周后，我们的捆绑包大小膨胀到 8.7MB，初始页面加载在 3G 网络上花费了 14 秒，而我们的 CDN 成本神秘地增加了三倍。这个代价高昂的错误让我学到了宝贵的东西：Base64 编码是一种理论上听起来很聪明但在错误应用时变成负担的工具。

我是 Sarah Chen，在过去的 12 年里，我在从小型创业公司到财富 500 强企业的公司担任性能工程师。我优化过的内容包括每月服务 5000 万用户的电子商务平台，以及内部仪表板（没有人认为需要优化，实际上确实需要）。在这段时间里，我看到 Base64 编码的出色用法，也看到它破坏了应用程序性能。区别始终在于了解它不仅如何工作，还在于它何时真正有意义。

本文是我试图给您一个我希望在开始时拥有的思维框架。我们将深入探讨 Base64 编码的技术现实，探索它闪光的具体场景，更重要的是，识别它在何种情况下是有害的。到最后，您将拥有一个决策过程，超越“我读到它更快”的实际可衡量的推理。

技术现实：Base64 实际上对您的图像做了什么

让我们从许多开发者忽视的不舒服事实开始：Base64 编码使您的图像大约增加 33%。不是偶尔，而是总是。这不是一个错误或实现细节——这是基本数学。

当您将二进制图像数据编码为 Base64 时，您是在将 8 位字节转换为安全 ASCII 子集中的 6 位字符。三字节二进制数据变成四个 Base64 字符。这就是 33% 开销的来源：4/3 = 1.33。一个 30KB 的 JPEG 变成一个 40KB 的 Base64 字符串。一个 100KB 的 PNG 膨胀到 133KB。这种大小增加是在任何压缩、网络传输或其他情况发生之前。

当您 Base64 编码一个图像时，实际发生的是这样的。您的原始二进制文件——假设是一个 45KB 的产品照片——作为原始字节读取。每个字节是一个从 0 到 255 的数字。编码算法按照每三个字节（总共 24 位）将这些字节分成四个 6 位块。每个 6 位块映射到 64 个安全 ASCII 字符之一（A-Z、a-z、0-9、+、/）。结果是一个看起来像这样长字符串：“/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a...”

这个字符串现在可以安全地直接嵌入 HTML、CSS 或 JavaScript 中。这是好处。但您为这种安全性付出了大小的代价。而大小对大多数开发者来说比想象的更重要，尤其是在移动网络上，每个千字节转化为真实的加载时间毫秒。

第二个技术现实：Base64 字符串无法像二进制数据那样有效地压缩。当您通过 HTTP 以 gzip 压缩提供常规 JPEG 时，您可能会看到 15-20% 的大小减小。当您压缩同一 JPEG 的 Base64 编码版本时，您可能只看到 5-10% 的减小。编码过程创建了不易压缩的模式。因此，一旦考虑到压缩，您的 33% 大小罚款常常变成 40-45% 的罚款。

我去年进行了这方面的测试，数据集包含 500 张产品图像，大小从 10KB 到 200KB。Base64 编码和 gzip 压缩后的平均大小增加为 37%。对于小于 5KB 的图像，罚款接近 42%。对于超过 100KB 的图像，它仍然是 35%。这数学是无法逃避的。

唯一真正的优势：消除 HTTP 请求

那么为什么还有人使用 Base64 编码？因为在特定场景中，消除 HTTP 请求的价值大于大小罚款。让我精准地说明何时确实如此。

"Base64 编码并没有消除 HTTP 请求——它只是在您的 JavaScript 捆绑包中隐藏了它们，在这里，它们以更难优化的方式损害性能."

每个 HTTP 请求都有开销。浏览器必须执行 DNS 查找（如果没有缓存）、建立 TCP 连接、进行 TLS 握手（对于 HTTPS）、发送请求头、等待服务器响应、接收响应头，最后下载内容。对于 HTTP/1.1，这个开销是相当可观的——通常在良好连接上100-300毫秒，在高延迟的移动网络上则是 500-1000 毫秒。

当您将小图像以内联方式作为 Base64 时，您消除了所有这一切。图像数据与包含它的 HTML、CSS 或 JavaScript 文件一起到达。没有单独的请求，没有额外的往返，没有连接开销。对于小图像——图标、小徽标、UI 元素——这可能导致更快的渲染，尤其是在高延迟连接上。

我测量了这一效果，在一个仪表板应用中，有 23 个小图标（平均 2.1KB 各）作为单独的 PNG 文件加载。在一个模拟的 3G 连接（300 毫秒延迟）下，加载所有图标的总时间为 4.7 秒，由于连接开销和浏览器请求排队。在将它们转换为 Base64 并在 CSS 中内联后，这些图标在样式表下载中加载仅需 1.2 秒。这是一个 3.5 秒的改善，尽管增加了 33%的大小。

但这里有一个关键细节：这种优势仅当 HTTP 请求的开销超过额外字节的成本时才存在。对于 2KB 的图标，667 字节的 Base64 开销与 300 毫秒的延迟相比微不足道。对于 200KB 的图像，66KB 的开销是毁灭性的，而任何延迟节省都无法弥补。

根据我在各种网络条件下的测试，交叉点处于 4KB 和 10KB 之间。低于 4KB 时，Base64 编码往往胜出。高于 10KB 时，它几乎总是失败。在 4KB 和 10KB 之间，取决于您的具体延迟配置和缓存策略。

关键用例：小 UI 元素的数据 URI

Base64 编码最合理的用途是用于小型、频繁使用的 UI 元素，这些元素对初始渲染至关重要。我说的是图标、小徽标、加载指示器和用户需要立即看到的基本图形。

在我为一家金融服务公司工作的项目中，我们有一个仪表板，上面有 15 个小图标，出现在页面的顶部。这些图标是核心导航的一部分，需在页面加载的前 1.5 秒内可见（我们的性能预算）。每个图标的大小约为 1.8KB，是一个 SVG 文件。

我们有三个选择：作为单独文件提供，将它们合并成雪碧图，或将它们内联为 Base64 数据 URI。我们在使用 WebPageTest 测试的 50 个不同网络配置上测试了这三种方法。结果清楚：关键 CSS 中的 Base64 数据 URI 平均减少了我们的速度指数 0.4 秒，在高延迟的移动连接上效果最为显著。

使这项工作得以实现的关键因素是大小（每个小于 2KB）、关键性（渲染初始时需要）、频率（在每个页面中使用）。如果任何一个因素有所不同，决定将会改变。