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

How much faster is it to use inline/base64 images for a web site than just linking to the hard file?

提问by Tim

How much faster is it to use a base64/line to display images than opposed to simply linking to the hard file on the server?

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

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

I haven't been able to find any type of performance metrics on this.

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

I have a few concerns:

我有几个顾虑：

• You no longer gain the benefit of caching
• Isn't a base64 A LOT larger in size than what a PNG/JPEG file size?

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

Let's define "faster" as in: the time it takes for a user to see a full rendered HTML web page

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

回答by Hyman Lloyd

'Faster' is a hard thing to answer because there are many possible interpretations and situations:

“更快”很难回答，因为有很多可能的解释和情况：

Base64 encoding will expand the image by a third, which will increase bandwidth utilization. On the other hand, including it in the file will remove another GET round trip to the server. So, a pipe with great throughput but poor latency (such as a satellite internet connection) will likely load a page with inlined images faster than if you were using distinct image files. Even on my (rural, slow) DSL line, sites that require many round trips take a lot longer to load than those that are just relatively large but require only a few GETs.

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

If you do the base64 encoding from the source files with each request, you'll be using up more CPU, thrashing your data caches, etc, which might hurt your servers response time. (Of course you can always use memcached or such to resolve that problem).

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

Doing this will of course prevent most forms of caching, which could hurt a lot if the image is viewed often - say, a logo that is displayed on every page, which could normally be cached by the browser (or a proxy cache like squid or whatever) and requested once a month. It will also prevent the many many optimizations web servers have for serving static files using kernel APIs like sendfile(2).

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

Basically, doing this will help in certain situations, and hurt in others. You need to identify which situations are important to you before you can really figure out if this is a worthwhile trick for you.

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

回答by pau.moreno

I have done a comparison between two HTML pages containing 1800 one-pixel images.

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

The first page declares the images inline:

第一页声明图像内联：

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

In the second one, images reference an external file:

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

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

I found that when loading multiple times the same image, if it is declared inline, the browser performs a request for each image (I suppose it base64-decodes it one time per image), whereas in the other scenario, the image is requested once per document (see the comparison image below).

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

The document with inline images loads in about 250ms and the document with linked images does it in 30ms.

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

(Tested with Chromium 34)

（用铬 34 测试）

The scenario of an HTML document with multiple instances of the same inline image doesn't make much sense a priori. However, I found that the plugin jquery lazyloaddefines an inline placeholder by default for all the "lazy" images, whose srcattribute will be set to it. Then, if the document contains lots of lazy images, a situation like the one described above can happen.

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

回答by ChrisW

You no longer gain the benefit of caching

您不再获得缓存的好处

Whether that matters would vary according to how much you depend on caching.

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

The other (perhaps more important) thing is that if there are many images, the browser won't get them simultaneously (i.e. in parallel), but only a few at a time -- so the protocol ends up being chatty. If there's some network end-to-end delay, then many images divided by a few images at a time multiplied by the end-to-end delay per image results in a noticeable time before the last image is loaded.

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

Isn't a base64 A LOT larger in size than what a PNG/JPEG file size?

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

The file format / image compression algorithm is the same, I take it, i.e. it's PNG.

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

Using Base-64, each 8-bit character represents 6-bits: therefore binary data is being decompressed by a ratio of 8-to-6, i.e. only about 35%.

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

回答by roryf

How much faster is it

有多快

Define 'faster'. Do you mean HTTP performance (see below) or rendering performance?

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

You no longer gain the benefit of caching

您不再获得缓存的好处

Actually, if you're doing this in a CSS file it will still be cached. Of course, any changes to the CSS will invalidate the cache.

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

In some situations this could be used as a huge performance boost over many HTTP connections. I say some situations because you can likely take advantage of techniques like image sprites for most stuff, but it's always good to have another tool in your arsenal!

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