为网站使用内联/base64 图像比仅链接到硬文件快多少？

Posted 2023-02-16

【中文标题】为网站使用内联/base64 图像比仅链接到硬文件快多少？

【英文标题】：How much faster is it to use inline/base64 images for a web site than just linking to the hard file?

【发布时间】：2010-12-07 04:38:29

【问题描述】：

与简单地链接到服务器上的硬文件相比，使用 base64/line 显示图像要快多少？

url(data:image/png;base64,.......)

我无法找到任何类型的性能指标。

我有几个问题：

您不再获得缓存的好处 base64 的大小不是比 PNG/JPEG 文件大很多吗？

让我们将“更快”定义为：用户看到完整呈现的 HTML 网页所需的时间

【参考方案1】：

“更快”是一个很难回答的问题，因为有许多可能的解释和情况：

Base64 编码将图像扩展三分之一，这将增加带宽利用率。另一方面，将它包含在文件中将删除另一个 GET 往返服务器。因此，与使用不同的图像文件相比，具有高吞吐量但低延迟的管道（例如卫星互联网连接）可能会更快地加载具有内联图像的页面。即使在我的（农村、慢速）DSL 线路上，需要多次往返的网站也比那些相对较大但只需要几个 GET 的网站加载时间要长得多。

如果您对每个请求的源文件进行 base64 编码，您将使用更多 CPU，破坏您的数据缓存等，这可能会损害您的服务器响应时间。 （当然你总是可以使用 memcached 之类的来解决这个问题）。

这样做当然会阻止大多数形式的缓存，如果经常查看图像，这可能会造成很大的伤害 - 例如，显示在每个页面上的徽标，通常可以由浏览器缓存（或代理缓存像鱿鱼或其他东西）并要求每月一次。它还将阻止 Web 服务器使用 sendfile(2) 等内核 API 提供静态文件的许多优化。

基本上，这样做会在某些情况下有所帮助，而在其他情况下会受到伤害。您需要确定哪些情况对您很重要，然后才能真正确定这对您来说是否值得。

【讨论】：

让我们将“更快”定义为：用户看到完整呈现的 html 网页所需的时间

服务器端的缓存/性能可能不是那么成问题。您仍然可以将页面部分缓存到文件中，因此无需重复将图像转换为 base64。如果您的页面不经常更改，您还可以告诉浏览器缓存 html 文件本身。

说得好。在较小的服务器中，最好从单独的文件服务器加载图像

'让我们将“更快”定义为' 什么用户？他们的烟斗是什么样的。他们多久访问一次您的页面？使用了哪些缓存策略？关键是没有单一的“更快”指标，也没有单一的答案。

【参考方案2】：

我对两个包含 1800 个单像素图像的 HTML 页面进行了比较。

第一页声明图片内联：

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAANSURBVBhXYzh8+PB/AAffA0nNPuCLAAAAAElFTkSuQmCC">

在第二个中，图像引用外部文件：

<img src="img/one-gray-px.png">

我发现当多次加载同一张图片时，如果它被声明为内联，浏览器会为每张图片执行一个请求（我想它对每张图片进行一次base64解码），而在另一种情况下，图片每个文档请求一次（参见下面的比较图）。

带有内嵌图像的文档在大约 250 毫秒内加载，带有链接图像的文档在 30 毫秒内完成。

（使用 Chromium 34 测试）

HTML 文档具有相同内联图像的多个实例的场景在先验中没有多大意义。但是，我发现插件jquery lazyload 默认为所有“惰性”图像定义了一个内联占位符，其src 属性将设置为它。然后，如果文档包含大量惰性图像，就会发生上述情况。

【讨论】：

你启用缓存了吗？

如果你把 base64 图像放到 CSS 类而不是 img 标签中，它会很快，而且你可以控制缓存和生命周期。

如果我在CSS 中使用base64 图像作为background-image，这会影响我的页面速度吗？ （这会在服务器上请求查找图像吗？）

【参考方案3】：

您不再获得缓存的好处

这是否重要会根据您对缓存的依赖程度而有所不同。

另一个（也许更重要）的事情是，如果有很多图像，浏览器不会同时获取它们（即并行），但一次只能获取几个——所以协议最终是@987654321 @。如果存在一些网络端到端延迟，那么许多图像一次除以几张图像乘以每张图像的端到端延迟会导致在加载最后一张图像之前有一段明显的时间。

base64 的大小不是比 PNG/JPEG 文件大很多吗？

文件格式/图片压缩算法是一样的，我拿，就是PNG。

使用 Base-64，每个 8 位字符代表 6 位：因此二进制数据以 8 比 6 的比例被解压缩，即仅约 35%。

【讨论】：

如果您的服务器使用 gzip 或 deflate 服务（大多数都这样做），这几乎是一种清洗，因为 base64 压缩而图像通常不会。对 214312 字节图像的随机测试是 213879 gzip，base64 是 285752，gzip 到 215779。因此，如果您计算多个请求的标头开销，它实际上是差不多的。

【参考方案4】：

速度快多少

定义“更快”。您是指 HTTP 性能（见下文）还是渲染性能？

您不再获得缓存的好处

实际上，如果您在 CSS 文件中执行此操作，它仍然会被缓存。当然，对 CSS 的任何更改都会使缓存失效。

在某些情况下，这可以用作对许多 HTTP 连接的巨大性能提升。我说一些情况是因为你可能会利用图像精灵之类的技术来处理大多数东西，但在你的武器库中拥有另一个工具总是好的！

【讨论】：

您也将从减少的 HTTP 请求数量中受益匪浅。

让我们将“更快”定义为：用户看到完整呈现的 HTML 网页所需的时间