为了减少服务器上的请求数量,我将一些图像(PNG和SVG)作为BASE64直接嵌入到css中。 (它在构建过程中自动化)
像这样:background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAFWHRTb2Z0d2FyZQBBZG etc...);
这是一个好习惯吗?有什么理由可以避免这种情况吗?是否有一些主要的浏览器没有数据网址支持?
奖金问题: 为CSS和CSS执行此操作是否有意义? JS也呢?
答案 0 :(得分:153)
这是一个好习惯吗?有什么理由可以避免这种情况吗?
这种做法通常只适用于IE兼容性无关紧要的非常小的CSS图像(如CSS精灵),保存请求比可缓存性更重要。
它有许多值得注意的缺点:
在IE6和7中根本不起作用。
仅适用于资源up to 32k in size in IE8。这是base64编码后适用的限制。换句话说,不超过32768个字符。
它会保存一个请求,但会改变HTML页面!并使图像无法缓存。每次加载包含页面或样式表时都会加载它们。
Base64编码使图像尺寸膨胀33%。
如果在gzip压缩资源中提供服务,data:
图像几乎肯定会对服务器资源造成严重压力!传统上,图像在压缩时非常耗费CPU,而且尺寸几乎没有减少。
答案 1 :(得分:34)
这里的常见答案似乎表明,由于一系列合理的原因,这不是必需的。 但是,所有这些似乎都忽略了现代应用程序的行为和构建过程。
设计一个简单的过程并不是不可能(实际上非常简单),它将遍历文件夹图像,并生成一个包含该文件夹所有图像的CSS。
这个css将被完全缓存,并将大大减少到服务器的往返,这正是@MemeDeveloper正确建议的最大性能点击之一。
当然,这是黑客。毫无疑问。像精灵一样是一个黑客。在完美的世界中,这是不需要的,在此之前,如果您需要解决的是:
我的观点。
答案 2 :(得分:11)
这不是一个好习惯。有些浏览器不支持数据URI(例如IE 6和7)或支持有限(例如IE8为32KB)。
有关数据URI缺点的完整详细信息,请参阅此维基百科文章:
<强>缺点强>
- 数据URI不会单独缓存其包含的文档(例如CSS或HTML文件),因此每次重载所包含的文档时都会下载数据。
- 每次更改内容都必须重新编码并重新嵌入。
- Internet Explorer到版本7(截至2011年1月约占市场份额的15%),缺乏支持。
- Internet Explorer 8将数据URI限制为最大长度为32 KB。
- 数据作为简单流包含在内,许多处理环境(例如Web浏览器)可能不支持使用容器(例如
multipart/alternative
或message/rfc822
)来提供更高的复杂性,例如元数据,数据压缩或内容协商。- Base64编码数据URI的大小比其二进制等值大1/3。 (但是,如果HTTP服务器使用gzip压缩响应,则此开销减少到2-3%)
- 数据URI使安全软件更难以过滤内容。
答案 3 :(得分:9)
我正在使用data-uri大约一个月,我刚刚停止使用它们,因为它们使我的样式表非常庞大。
Data-uri可以在IE6 / 7中运行(您只需要向这些浏览器提供mhtml文件)。
我使用data-uri获得的一个好处是,我的背景图像在下载样式表后立即呈现,而不是我们看到的逐渐加载
很高兴我们可以使用这种技术,但将来我不会太多使用它。我建议尝试一下,只是让你自己知道
答案 4 :(得分:3)
我更倾向于使用CSS Sprites来合并图像并节省请求。我从来没有尝试过base64技术,但它显然在IE6和IE7中不起作用。同时也意味着如果任何图像发生变化,那么除非你有多个CSS文件,否则你必须重新传输整个丢失的文件。
答案 5 :(得分:2)
我不知道一般的最佳实践,但如果我能帮助它,我不希望看到那种事情。 :)
Web浏览器和服务器内置了大量的缓存内容,所以我认为最好的办法就是让服务器告诉客户端缓存图像文件。除非你在页面上有很多非常小的图像,否则我不会认为多个请求的开销是一个大问题。浏览器通常会使用相同的连接来请求大量文件,因此没有建立新的网络连接,所以除非通过HTTP标头的流量与图像文件的大小相比是显着的,否则我不会担心多个请求太多
是否有理由认为目前有太多请求要发送到服务器?
答案 6 :(得分:0)
我建议将它用于经常使用的小图像,例如Web应用程序的常见图标。
当然,必须牢记旧浏览器的支持问题。此外,使用框架的功能自动内联图像数据网址(如GWT的ClientBundle或至少使用CSS类,而不是直接将其添加到元素的样式)可能是一个好主意。
此处收集了更多信息:http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/