在网站上使用内联/base64 图像比仅链接到硬文件要快多少？
使用 base64/line 来显示图像比简单地链接到服务器上的硬文件要快多少？
url(data:image/png;base64,.......)
我还没有找到任何类型的性能指标。
我有一些担忧：
- 您不再获得缓存的好处
- Base64 的大小不是比 PNG/JPEG 文件大小大很多吗？
让我们将“更快”定义为：用户查看完整呈现的 HTML 网页所需的时间
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?
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?
Let's define "faster" as in: the time it takes for a user to see a full rendered HTML web page
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
“更快”是一个很难回答的问题，因为有许多可能的解释和情况：
Base64 编码会将图像扩展三分之一，这将提高带宽利用率。另一方面，将其包含在文件中将删除另一个到服务器的 GET 往返行程。因此，具有较高吞吐量但较低延迟的管道（例如卫星互联网连接）可能会比使用不同图像文件更快地加载包含内联图像的页面。即使在我的（农村、慢速）DSL 线路上，需要多次往返的站点的加载时间也比那些相对较大但只需要几次 GET 的站点要长得多。
如果您对每个请求都从源文件进行 Base64 编码，您将使用更多的 CPU、破坏数据缓存等，这可能会影响服务器的响应时间。 （当然，您始终可以使用 memcached 等来解决该问题）。
这样做当然会阻止大多数形式的缓存，如果经常查看图像，这可能会造成很大的伤害 - 例如，每个页面上显示的徽标，通常可以由浏览器缓存（或代理缓存，如鱿鱼或无论如何）并要求每月一次。它还会阻止 Web 服务器使用 sendfile(2) 等内核 API 来提供静态文件的许多优化。
基本上，这样做在某些情况下会有所帮助，但在其他情况下会受到伤害。您需要先确定哪些情况对您来说很重要，然后才能真正确定这对您来说是否值得。
'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.
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).
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).
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.
我对两个包含 1800 个单像素图像的 HTML 页面进行了比较。
第一页声明图像内联：
在第二个页面中，图像引用外部文件：
我发现当多次加载同一图像时，如果声明内联，浏览器会对每个图像执行请求（我认为它是base64-）每个图像解码一次），而在另一种情况下，每个文档请求一次图像（请参见下面的比较图）。
包含内嵌图像的文档加载时间约为 250 毫秒，包含链接图像的文档加载时间为 30 毫秒。
（使用 Chromium 34 进行测试）
具有同一内嵌图像的多个实例的 HTML 文档的场景从先验来看没有多大意义。但是，我发现插件 jquery lazyload 定义了一个默认情况下，所有“惰性”图像的内联占位符都会被设置为它的 src 属性。然后，如果文档包含大量惰性图像，则可能会发生上述情况。
I have done a comparison between two HTML pages containing 1800 one-pixel images.
The first page declares the images inline:
In the second one, images reference an external file:
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).
The document with inline images loads in about 250ms and the document with linked images does it in 30ms.
(Tested with Chromium 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 lazyload defines 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.这是否重要取决于您对缓存的依赖程度。
另一件事（也许更重要）是，如果有很多图像，浏览器不会同时获取它们（即并行），而是一次只能获取几个图像 - 所以协议最终是 闲聊。如果存在一些网络端到端延迟，则一次将许多图像除以几个图像，再乘以每个图像的端到端延迟，就会导致加载最后一个图像之前需要一段明显的时间。
文件格式/图像压缩算法是相同的，我接受，即它是PNG。
使用 Base-64，每个 8 位字符代表 6 位：因此二进制数据按 8 比 6 的比例解压缩，即仅约 35%。
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.
The file format / image compression algorithm is the same, I take it, i.e. it's 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%.
定义“更快”。您指的是 HTTP 性能（见下文）还是渲染性能？
实际上，如果您在 CSS 文件中执行此操作，它仍然会被缓存。当然，对 CSS 的任何更改都会使缓存失效。
在某些情况下，这可以大大提高许多 HTTP 连接的性能。我说某些情况是因为您可能可以利用图像精灵等技术来处理大多数内容，但在您的武器库中拥有另一个工具总是好的！
Define 'faster'. Do you mean HTTP performance (see below) or rendering performance?
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.
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!