为了减少服务器上的请求数量,我将一些图像(PNG和SVG)作为BASE64直接嵌入到CSS中。(在构建过程中自动执行)
像这样:
background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAFWHRTb2Z0d2FyZQBBZG etc...);
这是一个好习惯吗?有什么理由可以避免这种情况?是否有一些不支持数据URL的主流浏览器?
额外的问题:对CSS和JS这样做也有意义吗?
为了减少服务器上的请求数量,我将一些图像(PNG和SVG)作为BASE64直接嵌入到CSS中。(在构建过程中自动执行)
像这样:
background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAFWHRTb2Z0d2FyZQBBZG etc...);
这是一个好习惯吗?有什么理由可以避免这种情况?是否有一些不支持数据URL的主流浏览器?
额外的问题:对CSS和JS这样做也有意义吗?
Answers:
这是一个好习惯吗?有什么理由可以避免这种情况?
这是一个好习惯,通常仅适用于在IE兼容性无关紧要时将一起使用的非常小的CSS图像(如CSS Sprites),并且保存请求比可缓存性更为重要。
它有许多明显的缺点:
出于一系列合法的原因,此处的常见答案似乎表明不需要这样做。但是,所有这些似乎都忽略了现代应用程序的行为和构建过程。
设计一个简单的过程来遍历文件夹图像,并使用该文件夹的所有图像生成单个CSS,这并非没有可能(实际上非常容易)。
此css将被完全缓存,并将大大减少到服务器的往返行程,这是@MemeDeveloper正确建议的,这是最大的性能问题之一。
当然,这是骇客。毫无疑问。和精灵一样,都是骇客。在完美的世界中,这是不需要的,直到那时,如果您需要解决的问题是一种可能的做法:
我的看法。
这不是一个好习惯。某些浏览器不支持数据URI(例如IE 6和7)或支持受到限制(例如IE8为32KB)。
另请参阅此Wikipedia文章,以获取有关Data URI缺点的完整详细信息:
缺点
- 数据URI不会从其包含的文档(例如CSS或HTML文件)中单独缓存,因此每次重新下载包含的文档时都会下载数据。
- 每次进行更改时,都必须重新编码内容并重新嵌入内容。
- 版本7的Internet Explorer(截至2011年1月约占市场的15%)缺乏支持。
- Internet Explorer 8将数据URI的最大长度限制为32 KB。
- 数据作为简单流包含在内,许多处理环境(例如Web浏览器)可能不支持使用容器(例如
multipart/alternative
或message/rfc822
)来提供更大的复杂性,例如元数据,数据压缩或内容协商。- Base64编码的数据URI的大小比其二进制等效文件大1/3。(但是,如果HTTP服务器使用gzip压缩响应,则此开销将减少到2-3%)
- 数据URI使安全软件更难以过滤内容。
我对一般的最佳实践一无所知,但是我可以帮助我,但我不希望看到这种事情。:)
Web浏览器和服务器内置了全部缓存内容,因此我认为最好的选择就是让您的服务器告诉客户端缓存图像文件。除非您在页面上加载非常小的图像,否则我不会认为多个请求的开销是一件大事。浏览器通常将使用相同的连接来请求大量文件,因此不会建立新的网络连接,因此,除非通过HTTP标头提供的流量与图像文件的大小相比是可观的,否则我不会担心太多请求。
您是否有理由认为目前有太多请求发送到服务器?
我建议将其用于经常使用的微小图像,例如Web应用程序的常用图标。
当然,必须牢记旧版浏览器的支持问题。使用框架的功能来自动内嵌图像的数据URL(例如GWT的ClientBundle)或至少使用CSS类,而不是直接将其直接添加到元素的样式中,也是一个好主意。
此处收集了更多信息:http : //davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/