html5 和 css3 里有 css sprite 的替代品吗

2010-11-27 11:29:51 +08:00
 pudd
因为雪碧在手机设备上常出乱子,想知道在新的标准里有没有专门用于减少http链接数的设计
7420 次点击
所在节点    HTML
25 条回复
disinfeqt
2010-11-27 12:34:10 +08:00
Nope.
Optimizing is for now, not the future.
spritevan
2010-11-27 14:25:55 +08:00
从你的设备支持状况来考虑, 尝试下 base64+dataurl 来载入 icon
disinfeqt
2010-11-27 15:03:28 +08:00
css sprite 只是一种 trick,连 technique 都算不上。只是用很反人性的方式、增加工作量为前提来减少请求数。
至于新标准,更多的是为语义化和便捷开发做优化,性能不是标准制定者们该考虑的问题。
disinfeqt
2010-11-27 15:05:13 +08:00
说了半天,其实应该叫:CSS Sprites。
pudd
2010-11-27 17:09:08 +08:00
今天看了一些html5的文章,感觉有一些新规范实际上是把原来就流传于开发者间的山寨技巧标准化了,所以忽然想起悲摧的Sprites哈哈。
chone
2010-11-27 17:24:49 +08:00
dataurl不错
disinfeqt
2010-11-27 17:25:25 +08:00
No more CSS Sprites, Data URI + MHTML please.
keakon
2010-11-27 20:35:53 +08:00
不知道楼上2位是否真的将data URI投入实际使用,至少在我看来有几个严重问题:
1.base64编码会增大1/3体积。
2.无法让浏览器缓存图像,只能缓存引用它的文件。
3.在HTML上不能复用,要复用只能放在CSS和JavaScript里。
4.你如果把背景图片写在CSS或JavaScript里,你在下载完CSS和JavaScript之前,浏览器是完全停止解析和渲染的,而常规的引用外部图片的方式是可以并行下载的。
chone
2010-11-27 20:49:38 +08:00
@keakon
1. data uri是用文本来保存图像,虽然体积增加,但是文本可以用gzip进行传送,基本能压缩1/3的体积,有些时候甚至更小
2. 虽然不能缓存,但是缓存在外联的的文件中基本能代替缓存。外联文件更新的时候需要从新下载是个问题
3. 这个是一个问题,但是在css sprites的使用情景里,基本都是css
4. 这个缺点css sprites一样存在
keakon
2010-11-27 21:14:35 +08:00
@chone

1.我们使用的图像大部分就是压缩过的,如果base64后再gzip会变得更小,那么这个图像压缩算法就太傻了。
拿http://www.google.com/images/logo.gif来说,原大小是11430字节,base64后是15240,再gzip是11473。
而且你测试下就知道,多一次compress和decompress的操作,肯定会对性能造成影响,更何况你还是用在CPU不给力的手机设备上。

2.如果要缓存,就必须每个图片写一个css。而获取这个文件本身就相当于多了一个HTTP请求,没有起到减少HTTP请求这个目的。

4.这个是和1相关的。一般的css文件只有几k到几十k,是很容易下载完的,不需要等待太久。而你加上了图像后,css变成了几百k甚至上m,这对用户来说就很慢了。因为我可以忍受图片暂时不显示,但不能忍受整个网页都暂时不能显示。
lianghai
2010-11-27 21:40:19 +08:00
强烈关注各位的观点阐述,很有意思。
disinfeqt
2010-11-27 22:46:05 +08:00
@keakon 如果你一味比较两方技术的优劣的话,反而让我质疑您“是否真的将data URI投入实际使用”。
就我个人经验来说(虽然并没有多少,如有不足请指正),Data URI + MHTML 只适用于小尺寸、同时具有高度复用性的图片,比如 h1~h6 的背景图,或者最近一个项目中我用它存储 faux 背景。如果图片(Riot 之后)的尺寸大于 5K,我是坚决不用 Data URI + MHTML 的。

对我个人而言,CSS Sprites 是个很反人类的东西,维护起来的难度对前端和视觉都是折磨,如果你现在不这么觉得,等半年以后给一个上 k 高度的 Sprites 加几个像素的时候就知道了。而且更新完之后,要在服务端同时清掉 CSS 和那张 Sprites 图的 cache,麻烦至极。

最后再说一个非常偏执的想法:我对所谓的性能优化和种种压缩厌恶至极,创造力和灵感不该被这些桎梏所束缚。如果你想创造美好的东西(仅指 web),永远不要把性能优化的优先级排在前面。甚至有次我直接问 @maxvoltar 说有没有好用的 CSS 压缩工具,这位大牛直接回复我说:Never used that before.

技术本来是为人造福的,合理的讨论有利于大家共同进步。如果还有争执,一位经验丰富的前辈已经说的够清楚了,请静心阅读:
http://dancewithnet.com/2009/08/15/data-uri-mhtml/
disinfeqt
2010-11-27 22:51:53 +08:00
题外话:如果不是需求方要求照顾 IE,我死都不会用这些东西。4行 CSS3 搞定。
keakon
2010-11-28 00:01:10 +08:00
@disinfeqt

就我本身来说,我没有采用上述的任何一种技术,因为我觉得简单就是最好的。我甚至完全不考虑IE浏览器,我自己的博客就是HTML5 + CSS3。

小图像下载本身就很快,拼在一起并没有让我感觉到更快。对用户来说,它们是次要的,关注的重点应该是内容本身。

而data URI会增大CSS体积这个缺点对我来说是致命的。这种次要内容绝对不应该影响到用户正常浏览网页,而CSS在下载和解析过程中对浏览器的独占性决定了它必须尽可能简化和轻量。
单个5kb的文件看上去是可以接受,但整个网站会用到多少个这种图片呢?如果就3、4个,增加几个HTTP链接又不会怀孕;如果10几20个,我想这个CSS也就不可接受了。
而且从维护上来说,看到一堆乱码一样的东西,人脑是不可能读懂这是什么图片的。

举个很现实的例子,我手机用的是GSM,网速慢得要死,所以我是不显示图片的。可你如果放在CSS里,我就被迫去下载这些我不关注的玩意了。

我还见过一些体验很差的网站,打开后先展示一个框架,然后下载半天资源,过了30秒才给你展示最重要的文字内容。
我想你必然更愿意在3秒内看到主要内容,然后花27秒去下载其他资源。至少在这个等待过程中,你可以看到想看的内容,而不是一个空白的框架。

我认为它真正有意义的地方是用来生成验证码。这个玩意不需要在服务器端生成和维护一张临时图片,这对于不能更改文件系统的GAE来说是很有意义的。
disinfeqt
2010-11-28 01:55:51 +08:00
OK I'm exhausted. Topic is off.
Oh btw, by "blog", you meant http://www.keakon.cn/bbs/forum-8-1.html ?
It's delightful, mate.
keakon
2010-11-28 03:16:37 +08:00
这个是旧的,下个月主机到期就会自动转到GAE了,因为有些文章还在整理中,所以地址就懒得公布了

演示在这里(版本比较旧):http://acgpedia.appspot.com/blog/
pudd
2010-11-28 08:52:52 +08:00
你们讨论的应该大多是把css sprites用在小图小按钮之类的地方

我自己的单页主页 http://pudd.cc

是把七八张中大型图片合成一张了( ̄▽ ̄")光下载图片就可能要十秒,也没见过有多少网站用过这么大的css sprites,所以不知道自己是不是做了一个很不地道的东西出来。
SolidZORO
2010-11-28 09:09:05 +08:00
@keakon 用CSS sprite做验证码。这招学到了。太高科技了。
key4ever
2010-11-28 09:34:23 +08:00
不回答布丁的问题
Sai
2010-11-28 09:38:34 +08:00
我觉得闲得OO疼的时候才会去捣鼓一下CSS Sprites,对于MiniSite来说拼一拼还是挺有趣的:
http://bgm.tv/tokei
http://chii.in/img/tokei/tokei_spirit.png

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/5062

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX