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

Question

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

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

我无法在此找到任何类型的性能指标.

我有一些顾虑:

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

让我们定义"更快",如下所示:用户查看完整呈现的HTML网页所需的时间

Answer 1

"更快"是一件难以回答的事情,因为有许多可能的解释和情况:

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

如果您对每个请求的源文件执行base64编码,您将耗尽更多CPU,破坏数据缓存等,这可能会损害您的服务器响应时间.(当然你总是可以使用memcached等来解决这个问题).

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

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

Answer 2

我在两个包含1800个单像素图像的HTML页面之间进行了比较.

第一页声明图像内联:

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

在第二个中,图像引用外部文件:

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

我发现当多次加载相同的图像时,如果它是内联声明的,浏览器会对每个图像执行一个请求(我认为它对每个图像进行base64解码一次),而在另一个场景中,图像被请求一次每个文件(见下面的比较图).

带有内嵌图像的文档加载大约250毫秒,带有链接图像的文档在30毫秒内加载.

(用铬34测试)

具有相同内联图像的多个实例的HTML文档的场景在先验上没有多大意义.但是,我发现插件jquery lazyload默认为所有"懒惰"图像定义了一个内联占位符,其src属性将设置为它.然后,如果文档包含许多惰性图像,则可能发生类似于上述情况的情况.

Answer 3

您不再获得缓存的好处

是否重要取决于您对缓存的依赖程度。

另一个（也许是更重要的）事情是，如果有很多图像，浏览器将不会同时（即并行）获取它们，而是一次只能获取几个图像-因此该协议最终变得很闲谈。如果存在一些网络端到端延迟，则一次将许多图像除以几张图像再乘以每张图像的端到端延迟将导致在加载最后一张图像之前需要花费明显的时间。

base64的大小不是大于PNG / JPEG文件的大小吗？

我接受了文件格式/图像压缩算法，即PNG。

使用Base-64时，每个8位字符代表6位：因此，二进制数据以8到6的比率进行解压缩，即只有大约35％。

Answer 4

它快多快了

定义'更快'.您是指HTTP性能(见下文)还是渲染性能？

您不再获得缓存的好处

实际上,如果你在CSS文件中这样做,它仍然会被缓存.当然,对CSS的任何更改都会使缓存失效.

在某些情况下,这可以用作许多HTTP连接的巨大性能提升.我说一些情况,因为你可以利用像图像精灵这样的技术来处理大多数事情,但是在你的武器库中拥有另一个工具总是好的!