与简单地链接到服务器上的硬文件相比,使用 base64/line 显示图像要快多少?
url(data:image/png;base64,.......)
我还没有找到任何类型的性能指标。
我有几个担忧:
- 您不再获得缓存的好处
- base64 的大小不是比 PNG/JPEG 文件大很多吗?
让我们将“更快”定义为:用户看到完整呈现的 HTML 网页所需的时间
“更快”是一个很难回答的问题,因为有许多可能的解释和情况:
Base64 编码将图像扩大三分之一,这将增加带宽利用率。另一方面,将它包含在文件中将删除另一个 GET 往返服务器。因此,与使用不同的图像文件相比,具有高吞吐量但低延迟的管道(例如卫星互联网连接)可能会更快地加载具有内联图像的页面。即使在我的(农村、慢速)DSL 线路上,需要多次往返的站点也比那些相对较大但只需要几个 GET 的站点加载时间要长得多。
如果您对每个请求的源文件进行 base64 编码,您将使用更多的 CPU,破坏您的数据缓存等,这可能会损害您的服务器响应时间。(当然,您总是可以使用 memcached 等来解决该问题)。
这样做当然会阻止大多数形式的缓存,如果经常查看图像,这可能会造成很大的伤害 - 例如,显示在每个页面上的徽标,通常可以由浏览器缓存(或代理缓存,如 squid 或无论如何)并要求每月一次。它还将阻止 Web 服务器使用 sendfile(2) 等内核 API 提供静态文件的许多优化。
基本上,这样做会在某些情况下有所帮助,而在其他情况下会受到伤害。您需要确定哪些情况对您很重要,然后才能真正确定这对您来说是否值得。
我对包含 1800 个单像素图像的两个 HTML 页面进行了比较。
第一页声明了图片内联:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAANSURBVBhXYzh8+PB/AAffA0nNPuCLAAAAAElFTkSuQmCC">
在第二个中,图像引用了一个外部文件:
<img src="img/one-gray-px.png">
我发现当多次加载同一张图片时,如果它被声明为内联,浏览器会对每张图片执行一次请求(我想它对每张图片进行一次base64解码),而在另一种情况下,图片被请求一次每个文档(请参见下面的比较图像)。
带有内嵌图像的文档在大约 250 毫秒内加载,带有链接图像的文档在 30 毫秒内完成。
(经铬 34 测试)
具有相同内联图像的多个实例的 HTML 文档的场景事先没有多大意义。但是,我发现插件jquerylazyload默认为所有“惰性”图像定义了一个内联占位符,其src
属性将设置为它。然后,如果文档包含大量惰性图像,则可能会发生上述情况。
您不再获得缓存的好处
这是否重要会根据您对缓存的依赖程度而有所不同。
另一个(也许更重要)的事情是,如果有很多图像,浏览器不会同时获取它们(即并行),但一次只能获取几个——所以协议最终变得很健谈。如果存在一些网络端到端延迟,那么许多图像一次除以几张图像乘以每个图像的端到端延迟会导致在加载最后一张图像之前有一段明显的时间。
base64 的大小不是比 PNG/JPEG 文件大很多吗?
文件格式/图片压缩算法是一样的,我拿它,就是PNG。
使用 Base-64,每个 8 位字符代表 6 位:因此二进制数据以 8 比 6 的比例被解压缩,即只有大约 35%。
它快多少
定义“更快”。您是指 HTTP 性能(见下文)还是渲染性能?
您不再获得缓存的好处
实际上,如果您在 CSS 文件中执行此操作,它仍然会被缓存。当然,对 CSS 的任何更改都会使缓存失效。
在某些情况下,这可以用作对许多 HTTP 连接的巨大性能提升。我说一些情况是因为你可能会利用图像精灵之类的技术来处理大多数东西,但在你的武器库中拥有另一个工具总是好的!