内联 base64 编码图像或 HTTP 请求？答案

【问题标题】：Inline base64-encoded images or HTTP request?内联 base64 编码图像或 HTTP 请求？
【发布时间】：2011-04-27 15:58:45
【问题描述】：

在 CSS 中使用图像至少有两种方法：

使用 HTTP 请求；

url(/path/to/image.png)
带有数据 URL。

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

但我想知道，由于 base64 编码的数据需要多 33% 的空间，因此加载时间要多 33%，是否值得，或者我应该只发出一个 HTTP 请求——如果有多个，则使用 sprite图片？

【问题讨论】：

标签： css optimization

【解决方案1】：

一个单独的请求几乎总是更可取的，因为使用data: URI，

它在旧版 IE 中不起作用，在 IE8 中限制为 32k
可以说它违背了样式和内容的分离
样式表文件被炸毁，如果浏览器的开发人员从没想过 CSS 文件会达到这种大小，这可能会导致麻烦

只有在没有其他选择的时候才会使用它。

【讨论】：

我会说这取决于条件。减少 HTTP 连接可以加速页面加载。例如rack-pagespeed 正在做。
@KARASZI 好点——如果在特定场景中减少 HTTP 连接胜过单独的缓存能力和浏览器兼容性，那么最好使用数据 URI。将“几乎”添加到“总是”
使用 Sass + Compass，您可以在编译时转换为 base64。我认为这比精灵更可取，因为这意味着图像在开发模式下保持分离。关于缓存 - CSS缓存，所以我不明白这个问题？
@Matrym 是的，缓存问题在这种情况下并不真正有效（当您将内容嵌入主页时，而不是样式表）。我会删除它。

【解决方案2】：

Web 服务器应该通过 GZIP 压缩所有文本文件来处理多出 33% 的空间，因此这应该不是什么大问题。这与减少 HTTP 请求的数量 (which is very important performance-wise) 一起使该方法值得。此外，图像仍被缓存，但现在在 CSS 文件中，而不是在单独的文件中。

最好使用插入数据 URI 的构建脚本来完成嵌入。这样我们在编辑 CSS 文件时就不必关心大块的 base64 编码数据。另外，如果图像在文件中出现多次，请记住要有一个好的解决方案，例如重写 CSS 规则。我们不希望文件过大。

虽然 IE 存在问题。 IE

这是一篇关于在 CSS 中嵌入图像以及如何解决 IE 问题的好博文：http://blog.meebo.com/?p=2320

【讨论】：

我发现它比管理 sprite 更容易，并且确实使用 MHTML for IE 将其合并到我最大的站点中（如果需要，IE8 也可以使用它） - 尽管有一个采取的其他措施很少，我会说它肯定有它的位置，对于通常会被精灵化的较小图像。你可以重复一个数据 Uri 图像，这是你不能用精灵的一部分做的——我没有构建脚本，但为它们使用单独的 Scss 文件（如索引）和@extend它们在需要的地方

【解决方案3】：

就个人而言，我总是会提出单独的要求。过去我在使用 Internet Explorer 和 data:url 图片时遇到过麻烦。

似乎 IE8 将 url 长度限制为 32KB，这对于图像来说通常是不够的。

Wikipedia on Browser Support

【讨论】：