当前位置:  开发笔记 > 编程语言 > 正文

将背景图像数据嵌入到CSS中作为Base64的好或坏做法?

如何解决《将背景图像数据嵌入到CSS中作为Base64的好或坏做法?》经验,为你挑选了5个好方法。

我正在查看一个greasemonkey用户脚本的来源,并在他们的css中注意到以下内容:

.even { background: #fff url(data:image/gif;base64,R0lGODlhBgASALMAAOfn5+rq6uvr6+zs7O7u7vHx8fPz8/b29vj4+P39/f///wAAAAAAAAAAAAAAAAAAACwAAAAABgASAAAIMAAVCBxIsKDBgwgTDkzAsKGAhxARSJx4oKJFAxgzFtjIkYDHjwNCigxAsiSAkygDAgA7) repeat-x bottom}

我可以理解,一个greasemonkey脚本想要在源代码中捆绑任何东西而不是在服务器上托管它,这是显而易见的.但由于我以前没有看过这种技术,我考虑过它的使用,看起来很有吸引力有很多原因:

    它将减少页面加载时的HTTP请求量,从而提高性能

    如果没有CDN,那么它将减少通过cookie与图像一起发送产生的流量

    CSS文件可以缓存

    CSS文件可以是GZIPPED

考虑到IE6(例如)有背景图像缓存问题,这似乎不是最糟糕的想法......

那么,这是一个好的或坏的做法,为什么你不使用它,你会使用什么工具base64编码图像?

更新 - 测试结果

用图像测试:http://fragged.org/dev/map-shot.jpg - 133.6Kb

测试网址:http://fragged.org/dev/base64.html

专用的CSS文件: http://fragged.org/dev/base64.css - 178.1Kb

GZIP编码服务器端

结果发送给客户端的大小(YSLOW组件测试):59.3Kb

保存发送到客户端浏览器的数据:74.3Kb

不错,但我认为它对于较小的图像会稍微有用.

更新:谷歌的软件工程师Bryan McQuade正在研究PageSpeed,他在ChromeDevSummit 2013上表达了数据:CSS中的uris被认为是一种渲染阻止反模式,用于在他的演讲中提供关键/最小的CSS #perfmatters: Instant mobile web apps.请参阅http://developer.chrome.com/devsum​​mit/sessions并记住这一点 - 实际幻灯片

小智.. 164

当您希望单独缓存图像和样式信息时,这不是一个好主意.此外,如果您将大图像或大量图像编码到css文件中,则在下载完成之前,浏览器需要更长时间才能下载文件而不会显示任何样式信息.对于您不打算经常更换的小图像,如果它是一个很好的解决方案.

至于生成base64编码:

http://b64.io/

http://www.motobit.com/util/base64-decoder-encoder.asp(上传)

http://www.greywyvern.com/code/php/binary2base64(来自下面的小教程的链接)

无需上传,拖放:http://bennedich.github.com/web-playground/experiments/test43_dragDrop_file2base64.html (3认同)


小智.. 55

这个答案已过时,不应使用.

1)2017年移动设备的平均延迟要快得多.https://opensignal.com/reports/2016/02/usa/state-of-the-mobile-network

2)HTTP2多路复用 https://http2.github.io/faq/#why-is-http2-multiplexed

对于移动网站,绝对应该考虑"数据URI".通过蜂窝网络的HTTP访问伴随着每个请求/响应的更高延迟.因此,在某些用例中,将图像作为数据干扰到CSS或HTML模板可能对移动Web应用程序有益.您应该根据具体情况衡量使用情况 - 我并不主张数据URI应该在移动Web应用程序的任何地方使用.

请注意,移动浏览器对可缓存文件的总大小有限制.iOS 3.2的限制相当低(每个文件25K),但是对于较新版本的Mobile Safari,它们会变得更大(100K).因此,在包含数据URI时,请务必密切关注文件总大小.

http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/



1> 小智..:

当您希望单独缓存图像和样式信息时,这不是一个好主意.此外,如果您将大图像或大量图像编码到css文件中,则在下载完成之前,浏览器需要更长时间才能下载文件而不会显示任何样式信息.对于您不打算经常更换的小图像,如果它是一个很好的解决方案.

至于生成base64编码:

http://b64.io/

http://www.motobit.com/util/base64-decoder-encoder.asp(上传)

http://www.greywyvern.com/code/php/binary2base64(来自下面的小教程的链接)


无需上传,拖放:http://bennedich.github.com/web-playground/experiments/test43_dragDrop_file2base64.html

2> 小智..:

这个答案已过时,不应使用.

1)2017年移动设备的平均延迟要快得多.https://opensignal.com/reports/2016/02/usa/state-of-the-mobile-network

2)HTTP2多路复用 https://http2.github.io/faq/#why-is-http2-multiplexed

对于移动网站,绝对应该考虑"数据URI".通过蜂窝网络的HTTP访问伴随着每个请求/响应的更高延迟.因此,在某些用例中,将图像作为数据干扰到CSS或HTML模板可能对移动Web应用程序有益.您应该根据具体情况衡量使用情况 - 我并不主张数据URI应该在移动Web应用程序的任何地方使用.

请注意,移动浏览器对可缓存文件的总大小有限制.iOS 3.2的限制相当低(每个文件25K),但是对于较新版本的Mobile Safari,它们会变得更大(100K).因此,在包含数据URI时,请务必密切关注文件总大小.

http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/


相反,http://www.mobify.com/blog/data-uris-are-slow-on-mobile/

3> Gumbo..:

如果您仅引用该图像一次,我认为将其嵌入您的CSS文件中没有问题.但是,一旦您使用多个图像或需要在CSS中多次引用它,您可以考虑使用单个图像映射,然后可以从中裁剪单个图像(请参阅CSS Sprites).


它只是意味着你应该有参考背景图像的元素,并引用偏移到该映像使用该元素的另一CSS类的一个CSS类.
你应该没有关于描述材料如何呈现的元素的类 - 这些类应该是有名的和语义的(这不是总是可行的,但是很适合拍摄)如果多个元素使用相同的图像,并且你想要在CSS中编码该图像,只是将图像从声明中删除,并使用稍后的css规则来声明和嵌入多个选择器/类的图像.

4> ximi..:

我建议的一件事是有两个单独的样式表:一个是常规样式定义,另一个是包含base64编码的图像.

当然,您必须在图像样式表之前包含基本样式表.

通过这种方式,您可以确保将常规样式表下载并尽快应用到文档中,同时您可以从减少的http请求和其他数据中获益 - uris为您提供.



5> Greg..:

在GZipped之后,Base64在图像尺寸上增加了大约10%,但是在移动设备方面,这超过了它的优势.由于响应式网页设计存在整体趋势,因此强烈建议使用.

W3C还推荐这种移动方法,如果你在rails中使用资产管道,这是压缩你的css时的默认功能

http://www.w3.org/TR/mwabp/#bp-conserve-css-images


这是对的.任何移动设备中最慢的是打开/关闭http连接.建议尽量减少它们.
如果它不可能拉链,我想它可以提高33%.
推荐阅读
跟我搞对象吧
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有