疯狂的雪碧图
2011-07-24 20:21
155 查看
重构工程师是掌控天平的人。在制作雪碧图这件事上,要考虑自己行为造成的如下影响:服务器流量、HTTP请求数、可扩展性。理解了使用它的优势和劣势,才能写出更好的代码。
服务器流量
滥用雪碧图可能导致服务器流量的浪费,体现在以下4个方面:单独来看,不同类型的图片适合使用不同类型的格式,各自使用各自适合的图片的话,并且经过额外压缩(非PS里的压缩,而是去掉文件附带信息的压缩),就能达到流量最优。当做成雪碧图时,也就是用一种类型来匹配多种图片。在这种情况之下,可能一个并不适合制作成jpg的按钮被放在一个大的jpg雪碧图中。由此造成的服务器流量增多是一个无法忽视的漏洞。更严重的是,一些需要平铺repeat的图放在雪碧图中可能会影响整个雪碧图尺寸大小的变更。第二个由雪碧图造成的服务器流量浪费是多页面使用各自不同的图:页面1显示a.jpg,页面2显示b.jpg,页面3显示c.jpg。如果abc做到一个雪碧图中,那么用户访问页面1的时候就会读取一个包含了abc的大图,而他可能根本不会去访问页面2和页面3,这样就造成了流量浪费。这是非常大的一个浪费。第三个因素是雪碧图中的一个小地方修改时,整个大图都需要由用户重新读取,无法长缓存。第四个因素是:模块之间是耦合较低的,这是理想的、我们希望看到的情况。但通过雪碧图我们把几个模块连接在一起了:当一个模块弃用或者修改之后,模块的图片还在雪碧图之中,而雪碧图仍然在线上通过其他模块被用户读取。这就造成了流量浪费。HTTP请求数
雪碧图能减少HTTP请求数,以此获得的利益被高估了:HTTP请求数不是一个重要得不得了的优化因素,因为HTTP请求数不是越少越好,而是少到一定程度就足够好了。就好像通过CDN增加域名数来提高并行下载数量,但CDN的数量也不是越多越好,因为增加一个域名就会增加一个域名的DNS解析时间。达到4个域名的时候,增加的额外DNS解析时间可能会完全抵消掉并行下载带来的好处。足够好就够了。可扩展性
雪碧图对扩展性造成的干扰体现在下面几点:首先,降低了了组件独立性。如果希望在一个子页中调用首页的一个vip按钮,那么就必须做一个担心:担心子页中引用改模块的html或者css会导致请求一整张不需要的大图片。其次,增加了图片,那么是在已有雪碧图中进行修改增加还是另外增加一个图片?后者会导致不一致和服务器布局混乱;前者会导致雪碧图尺寸增加,或者由于找不到PSD源码导致图片质量降低的问题,而且几个同样按钮的不同布局摆放也可能会输出大小不一的图片,后期变更往往在开始摆放的时候是无法预料到的。再次,雪碧图尺寸变更也可能导致原有雪碧图支持的模块错乱。因为一些小icon必须处于雪碧图的中间的,如果改变宽度,那么icon就不在50%处了,会导致模块错位。那么
使用的时候多思考,不要不加思考地使用雪碧图,不要让自己的天平太过于偏向HTTP请求数,而忽略了流量和可扩展性。相关文章推荐
- 【疯狂labview】 Xcontrol+LVoop封装练习 Toolbar
- 【C疯狂的教材】(四)C语言分支语句
- 疯狂java讲义 第三版 笔记
- IOS疯狂基础之UIImage
- gulp多张图片自动合成雪碧图
- MiUI手机疯狂输出logcat处理
- Java疯狂讲义第五章笔记
- [疯狂Java笔记]事件处理:Java事件处理模型
- 疯狂iOS讲义上、下PDF(包含源码)
- [疯狂Java]网络:IP地址和端口号
- 硬盘杀手!Windows版Redis疯狂占用C盘空间!
- 【疯狂造轮子-iOS】JSON转Model系列之二
- 程序猿也疯狂《二》
- [疯狂Java]I/O:File(文件类,也是文件流的节点)、FilenameFilter(文件过滤器)
- 疯狂安卓书籍的学习--未完待续~
- [疯狂Java]AIO:
- [疯狂Java]集合:专门用于聚集操作的一次性集合——Stream(流)
- [疯狂Java]集合:Collections工具类、Enumeration(摒弃)
- cojs 疯狂的字符串 题解报告
- [疯狂Java]面向对象:常量池、equals标准模板