我一直在查看油脂猴子用户脚本的来源,并在他们的CSS中注意到以下内容:
.even { background: #fff url(data:image/gif;base64,R0lGODlhBgASALMAAOfn5+rq6uvr6+zs7O7u7vHx8fPz8/b29vj4+P39/f///wAAAAAAAAAAAAAAAAAAACwAAAAABgASAAAIMAAVCBxIsKDBgwgTDkzAsKGAhxARSJx4oKJFAxgzFtjIkYDHjwNCigxAsiSAkygDAgA7) repeat-x bottom}
我可以理解,滑脂脚本希望将其可以捆绑的所有内容捆绑在源代码中,而不是将其托管在服务器上,这很明显。但是由于我以前没有看过这种技术,所以我考虑了它的使用,并且由于许多原因,它似乎很有吸引力:
- 它将减少页面加载时的HTTP请求数量,从而提高性能
- 如果没有CDN,则它将减少通过Cookie与图像一起发送而产生的流量
- 可以缓存CSS文件
- CSS文件可以是GZIPPED
考虑到IE6(例如)在背景图片缓存方面存在问题,这似乎不是最糟糕的主意...
那么,这是好事还是坏事,为什么您不使用它,以及使用哪种工具对图像进行base64编码?
更新-测试结果
图片测试:http://fragged.org/dev/map-shot.jpg-133.6Kb
专用CSS文件: http: //fragged.org/dev/base64.css-178.1Kb
GZIP编码服务器端
发送给客户端的结果大小(YSLOW组件测试):59.3Kb
发送到客户端浏览器的数据保存:74.3Kb
不错,但是我猜它对较小的图像用处不大。
UPDATE: Bryan McQuade, a software engineer at Google, working on PageSpeed, expressed at ChromeDevSummit 2013 that data:uris in CSS is considered a render-blocking anti-pattern for delivering critical/minimal CSS during his talk
#perfmatters: Instant mobile web apps
. See http://developer.chrome.com/devsummit/sessions and keep that in mind - actual slide
据我研究,
使用:1.使用svg精灵时。2.当图像尺寸较小时(最大200mb)。
不要使用:1.当您放大图像时。2.图标为svg。由于它们已经很好并且在压缩后会压缩。