应用CSS sprite 的益处和弊端剖析

日期:2021-01-20 类型:科技新闻 

关键词:在线网页制作,建网页,个人简介网页制作,简单网页,建立网页

原文:CSS Sprites: Useful Technique, or Potential Nuisance?

译文:CSS Sprites:鱼翅還是3鹿?

无处不在的 CSS sptites - 为数很少的几个能够立即绕过”时兴”这个全过程,而能够立刻而且紧紧地跻身于最好 CSS 实践活动当中的几个技术性之1。尽管它真实时兴是在 A List Apart 解释并认同这个技术性以后,可是早在 2003 年 7 月份,Peter Stanicek 就早已刚开始讨论它了。

现阶段大多数数的开发设计人员对这个技术性都有非常地把握,也是有许多有关它的实例教程和文章内容。基本上全部的文章内容中都声称设计方案师和开发设计人员都应当应用 CSS sprite 来降低 HTTP 恳求数,而且节约1些总流量。这个技术性被很多网站应用,包含应用了大中型 sprite 的 Amazon .

可是这些被普遍热议的益处真的是值得的吗?设计方案师们是不是在沒有全面考虑到到全部状况的状况下,在盲目跟风地应用这个技术性呢?设计方案师们是否过度关心 CSS sprite 的时兴,而忽视了其它应当细心掂量的要素了呢? 这篇文章内容会探讨下应用 CSS sprite 的益处和弊端,特别关心”乱用” sprites 的状况,并且会解释下为何“乱用” sprite 实际上是消耗時间。

访问器缓存文件全部照片

sprite 技术性的在其中1个益处是照片的载入時间(在有很多 sprite 时,单张照片的载入時间)。由所需照片拼成的1张 GIF 照片的规格会显著小于全部照片拼合前的尺寸。单张的 GIF 仅有有关的1个色表,而独立切分的每张 GIF 都有自身的1个色表,这就提升了整体的尺寸。因而,独立的1张 JPEG 或 PNG sprite 在尺寸上十分将会比把1张图分为多张得来的照片总规格小。可是这真的有想像的那末好吗?

1般来讲,访问器会缓存文件全部的照片 – 不管照片 sprite 与否。sprite 技术性只是在网页页面第1次载入的情况下才会节约带宽,另外缓存文件也会对应用同样照片的别的网页页面合理。

Firefox 缓存文件显示信息的访问器缓存文件的来自 amazon.com 的照片(在 Firefox 详细地址栏键入 “about:cache” 来查询)。

考虑到到如今的广泛网速早已比 2003⑵004 年时提出这个技术性的情况下要快多了,因而很多应用 sprite 技术性就并不是那末必要了。有1点必须确立,并不是说不可该用 sprite,而是不可该以便比较有限的益处来乱用这个技术性。

拼合照片的時间成本费会提升

想像1下1个有3个情况的照片按钮是如何制做的:意味着不一样的情况的照片必须邻近置放在1起构成1张照片。在应用 Photoshop 或别的手机软件切图时,不一样的情况其实不会在1起;必须把她们独立切出来再合拼为1张照片。

假如在其中任1个照片情况必须更改,全部照片就必须再次制做储存。对1些设计方案师来讲这并不是甚么难题,或许她们会独立保存不一样按钮情况的源文档,这样必须合拼的情况下就简易了。可是这个全过程有点繁杂,远沒有切出1个独立照片来的简易。

以便节约几 k 的总流量和几个服务器恳求(还只产生在第1次载入网页页面时),sprite 技术性是不是真的值得?

编号和维护保养的時间成本费会提升

照片切成片輸出以后,不便仍然存在。尽管习惯性这个全过程以后,按钮 sprite 能够很简易地编号到 CSS 中,可是别的的 sprites 就不这么简易了。

单1的1个按钮1般会是个有定宽的 <ul> 元素。倘若按钮的 sprite 是相互单独的,就较为简易:<ul> 的宽高会和目录项和锚点的宽高1致,每一个情况的 sprite 对齐放置。sprite 的部位还可以很非常容易地依据每一个按钮的宽高测算出来。

可是遇到以前提到的,像 Amazon 或 Google 用到的大中型 sprite 的状况时,会如何呢?你能想像到到维护保养这么1个文档,而且在 CSS 中更改 sprite 项的部位会是甚么样吗?也有第1次建立 CSS 编码的状况?相对1个能够轻轻松松测算出来情况部位的简易按钮来讲,大中型的 sprite 会致使无穷地检测和照片情况的再次放置。

1些用于精准定位 Google 的 sprite 照片的款式

Amazon 的 sprites 的确节约了最少 30 个 HTTP 联接,特性层面也的确有了很大的提升。可是把这些益处拿来和开发设计和维护保养成本费做个较为,再把缓存文件和网速等要素考虑到进来,决策应用这般大中型的 sprites 或许就不那末让人相信了。

Sprites 是不是真的必须“维护保养”?

自然了,一些人不感觉 sprite 是主要引发头疼的难题。绝大多数状况下,1个 sprite 建立并编号完以后,就非常少会被修改了,也不容易受开展中的网站维护保养的危害。倘若你觉得 sprite 维护保养并不是个难题的话,那末或许应用大中型 sprite 是最好是的挑选。

并不是全部照片全是情况

另外一个不倡导乱用 CSS sprite 的理由是这会致使开发设计人员不正确地应用情况照片。有工作经验的开发设计人员会在新项目中考虑到可浏览性难题,她们搞清楚其实不是每一个照片全是情况。情况照片应当留给按钮和用来装饰设计元素,而用来传递关键信息内容的图象应当内联在 XHTML 中。

Amazon 正确是应用了内联图象元素和装饰设计用的情况。

不正确得应用 Sprites 危害可浏览性

1些刚新手入门的开发设计人员会以便节约 HTTP 恳求数(这是应用 CSS Sprite 1直强调的益处)而把全部的照片都当情况照片来解决 – 乃至是那些传递关键信息内容的照片。結果会致使1个欠缺可浏览性的网站,也会减少 HTML 中 title 和 alt 的潜伏好处。

因而,CSS sprite 自身没错,并且也不容易引起可浏览性难题(客观事实上,正确得应用会提升可浏览性)。可是分不清对与错得过多应用 sprite 会阻拦具备可浏览性和生产制造率层面的网页页面基本建设过程。

HTTP 恳求数又怎样?

很多人会强词夺理,改进网站特性最关键的一部分便是降低 HTTP 恳求数。也要了解1项科学研究说明1个网站平常的浏览者中 40⑹0% 占比全是沒有访问器缓存文件的。这是不是足以表明应当在全部状况下应用大中型 sprites 呢?也许是这样。特别是考虑到到客户的初次来访对1个网站的关键性。

Firefox 的 YSlow 软件显示信息 HTTP 恳求数

过去的访问器1般只容许 2 个高并发 HTTP 联接,3.0 版本号以来的 Firefox 和 IE8 默认设置容许 6 个高并发 HTTP 联接。这代表着每台服务器有 6 个高并发联接。引入 Steve Souders 的话:

“搞清楚这是服务器的基本是很关键的。应用好几个网站域名,如 1.mydomain.com, 2.mydomain.com, 3.mydomain.com, 这些,使开发设计人员能够彻底运用服务器联接数。在全部网站域名是同1 IP 详细地址的 CNAME 时仍然合理。”

因而,也许在按钮情况以外应用 CSS sprites 也是有利的,在将来,伴随着互联网联接速率的加速和新版访问器的特性提高,应用大中型 sprites 所带来的益处可能变得不值得1提。

那些 Sprites 转化成器呢?

另外一个钟爱大中型 sprite 的理由是能够运用1些 sprite 转化成器来简易得转化成 sprite。对此类专用工具的详尽探讨和评测不在本文探讨范畴。可是从作者对此类专用工具的科学研究看来,协助十分比较有限,而且维护保养这些 sprites 1样必须可观的工作中量,这也是必须和盈利衡量的。

一些专用工具,比如来自 Fondue 新项目的这个,出示輸出 CSS 选项。Steve Souders’ 的专用工具 SpriteMe 是另外一个出示 CSS 编号选项的。SpriteMe 会把现有的网站情况照片变换成单张 sprite 照片(我以前提到的“大中型” sprite)并出示免费下载以供编号入网页页面当中。但是这些专用工具只是有助于建立 sprite,其实不能在维护保养层面出示是多少协助。Souder 的专用工具貌似对再次设计方案或合理布局的网站失效,并且只对那些现有的沒有应用 sprite 方式的网站有效。

能够改善现有的专用工具,并且将来也会有新的专用工具出現。可是,鉴于以上提到的这些缺陷,是不是还存在这类将会,便是开发设计人员仍然把活力集中化在比较有限的所得上?

关心好几个特性提高点

上面提到,HTTP 恳求数是提高网站特性必须考虑到的1个十分关键的要素。可是有其他方式能够降低联接数,包含合拼脚本制作和款式表,应用远程控制库文档(即便用 Google 或 Yahoo!出示的库文档代管)。

除 HTTP 恳求数以外也有许多开发设计人员能够关心的用于提高网站特性的要素。包含服务器开启 Gzip,正确的置放外链脚本制作,提升 CSS 英语的语法,缩小较大的 JavaScript 文档,提高 Ajax 特性,防止应用已知的会引发特性难题的 JavaScript 英语的语法,这些。


YSlow 显示信息了 HTTP 恳求数以外能够提高网站特性的要素

假如开发设计人员花点時间来考虑到下全部能够提高网站特性的要素,再衡量下利与弊,或许就有较好的理由能够防止乱用 CSS sprite 了,而且会把活力放在那些物有一定的值的层面。

总结

请不必误会我所说的。很多顶级的 blogger 和开发设计人员早已称赞 sprite 的益处许多年了,近期几年又把这些建议营销推广到应用大中型 sprite 上来了 – 因而应当用心得考虑到下这些见解。可是,这类拥有健全的体系和系统软件,使得网站维护保养每日任务简化并流水化的企业,其实不是全部人都能进去的。大多数数人全是单独工作中,或接纳他人建立的新项目。这类状况下,大中型的 sprite 会致使因小失大的不便。

糖伴番茄的总结

题目有点醒目 :) 原题目的规定汉语翻译为 CSS Sprites:有效的技术性還是潜伏的不便?

有关 CSS Sprite,在 Web 规范沟通交流会 第2期的情况下探讨过。实际上 CSS Sprite 是很有效处的。可是前提条件是不必超过1个度的限定。基础上许多难题最后都会归入怎样适当地应用的难题。俗话说:物极必反,实际上還是很有道理的。

针对降低 HTTP 恳求数难题,能够稍作让步,把照片归类,尽可能把內容固定不动、后期不容易有太多变化的图归于1个 sprite 中,比如1些 icon 。那些会常常修改的照片归于1类,分为几组 sprite。针对设计方案花梢而性命周期很短的专题来讲,真得,花销在拼图上的時间和亲身经历确实是有点消耗了。

有关老外的文章内容,我如今感觉一些叨唠了。也许许多人也会有这个觉得。实际上应当反思下,听说日本有专业的小册子来教人做1些十分基本的物品,內容流程细腻到让人发指得程度。基本的物品大多数人会嗤之以鼻,感觉他人都讨论奇技淫巧、高級运用了,我还在搞这些基本,多丢脸啊。

基本的物品实际上没那末简易的,有谁能真得把握了这些看上去简易的基本呢?看1下这个基本难题你真的掌握HTML吗?

以前有1个大神送我1本书,他写了 ”Back to basic“ 送我,我在这里送给大伙儿,期待大伙儿都能安安稳稳地勤奋发展。

上一篇:慎重应用CSS中的星号(*)通配符 返回下一篇:没有了