将原始图像数据放在 Src Attr 中是否更有效？
我最近发现图像的 src 属性允许您将原始的 Base 64 图像数据直接放入其中。我是否正确地认为这在技术上比单独的图像文件更有效，因为不必对图像提出额外的请求？或者开销太小以至于不值得？
另外，假设我最终这样做了，获取原始数据的最佳方法是什么？ （比如说，是我用颜料画出来的图像？）
I recently found out that the src attribute of an image allows you to put raw base 64 image data straight into it. Am i right in supposing this is technically more efficient than a separate image file as additional requests for the images don't have to be made? Or is the overhead so small that it's not worth it?
Also, assuming i ended up doing this, what would be the best way to get that raw data? (out of, say, an image i whipped up in paint?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这取决于您所说的“更高效”是什么意思。如果你的衡量标准是时间，那么它会更有效率。
您所指的技术是使用数据URI。通常，您获取图像数据并base64 编码，使其仅包含 ASCII 字符。 Base64 编码数据的效果是使其增大 33%（每 6 位变为 8 位）。
因此，这适用于小图像，但对于大图像，33% 的溢价可能太多了。
这可能是一个好主意的原因是延迟通常是浏览器请求的限制因素。过去（过去）带宽是限制，因此常见的建议是分割资源，但现在情况已不再如此。使用数据 URI 图像，浏览器无需进行第二次往返。
除此之外，您还必须考虑浏览器支持。在版本 8 之前，IE 不支持数据 URI。在 IE 8 中，数据的上限为 32KB。
希望这有帮助！
It depends on what you mean by "more efficient". If your measure is time, then it can be more efficient.
The technique you're referring to is using a data URI. Typically you take the image data and base64 encode it so it contains only ASCII characters. base64 encoding data has the effect of making it 33% larger (every 6 bits become 8).
So this works for small images, but for large ones, the 33% premium may be too much.
The reason why it might be a good idea is that latency is often the limiting factor for browser requests. It used to be (back in the day) that bandwidth was the restriction, so the common advice was to split up your resources, but that's not true anymore. With a data URI image, the browser doesn't have to make a second round trip.
Aside from all that, you have to consider browser support. Prior to version 8, IE has no support for data URIs. And in IE 8, there's an upper limit of 32KB of data.
Hope this helps!
这有一个大小限制。我不太确定，但 2K 似乎是正确的。
请记住，对某些内容进行 Base64 编码会产生开销。如果您有 500 字节的图像，这可能没问题，但对于其他情况则不然。
但实际上，您现在不应该为了兼容性而这样做。也许在未来几年...
There is a size limit to this. I don't know for certain off the top of my head, but 2K seems about right.
Remember that there is overhead for base64 encoding something. If you have a 500 byte image, this might be fine, but for other things, no.
Really though, you shouldn't be doing this right now for compatibility. Maybe in the coming years...
这取决于您要发送的图像数量以及请求图像的频率。拥有 Base 64 的图像绝对比 30 个 http 请求更有效。
如果频繁请求，您还可以对每个图像进行缓存。这是我们在我的工作场所实施的。我们将 base64 存储在临时目录中并检查它们是否已被编码。如果是这样，我们的响应时间会更快，否则它们会在 PHP 脚本中动态创建。更受欢迎的页面将很快在缓存中预热。
It depends on how many images you're going to be sending and how often they get requested. Having the images in base 64 is absolutely more efficient then 30 http requests.
You could also implement caching of each image if they get requested frequently. This is something we've implemented in my workplace. We store the base64 in a temp directory and check if they've already been encoded. If so, we have an even faster response time, otherwise they get created on the fly in the PHP script. The more popular pages will be warmed up in the cache very quickly.