网站最基本的东西是什么?
内容?SEO(搜索引擎优化)?UE(用户体验)?都不对,是速度。
内容再丰富的网站,如果慢到无法访问也是毫无意义的。SEO 做的再好的网站,如果搜索蜘蛛抓不到也是白搭。UE 设计的再人性化的网站,如果用户连看都看不到也是空谈。
所以网页的效率绝对是最值得关注的方面。如何才能提高一个网页的效率呢?这也将是我们在文中介绍到的 YSlow 工具的十四条理论基础:
- Make Fewer HTTP Requests
- Use a Content Delivery Network
- Add an Expires Header
- Gzip Components
- Put CSS at the Top
- Move Scripts to the Bottom
- Avoid CSS Expressions
- Make JavaScript and CSS External
- Reduce DNS Lookups
- Minify JavaScript
- Avoid Redirects
- Remove Duplicate Scripts
- Configure ETags
- Make Ajax Cacheable
这里我们将逐一的讲解这些准则,对其中开发者密切相关的准则我将详细讲解。
第一条:Make Fewer HTTP Requests 尽可能的减少 HTTP 的 Request 请求数
80%的用户响应时间都是浪费在前端。而这些时间主要又是因为下载图片、CSS 样式表、JavaScript 脚本、flash 等文件造成的。减少这些资源文件的 Request 请求数将是提高网页显示效率的重点。
这里好像有个矛盾,就是如果我们减少了很多的图片,样式,脚本或者 Flash ,那么网页岂不是光秃秃的,那多难看呢?其实这是一个误解。我们只是说尽量的减少,并没有说完全不能使用。减少这些文件的 Request 请求数,当然也有一些技巧和建议的:
1、用一个大图片代替多个小图片
这的确有点颠覆传统的思维了。以前我们一直以为多个小图片的下载速度之和会小于一个大图片的下载速度。但是现在利用 FireBug 工具对多个页面进行分析后的结果表明事实并不是这样。
所以还是使用大图片来替代过多的琐碎的小图片吧。这也是为什么翻转门的效率要高于图片替换实现的滑动门的原因。
但是,请注意:也不能用太大的单张图片,因为那样会影响到用户体验。例如:几兆的背景图片的使用绝对不是一个好主意。
2、合并你的 CSS 文件

图为:合并与融合的示例
我们为了提高网页效率的角度上而言,我们还是应该将所有的 CSS 写在同一个 CSS 文件中。但是问题又来了。那么怎么来很好的组织和规划 CSS 样式表呢?这的确是个矛盾。我现在的做法是采用两套版本。编辑版和发布版。编辑版仍然使用多个 CSS 文件以便于规划和组织。而等到发布的时候,再将多个 CSS 文件合并到一个文件中去,从而达到减少 HTTP Request 请求数的目的。
3、合并你的 javascript 文件
原因和处理方法同上,不再赘言。
第二条:Use a Content Delivery Network 使用 CDN
这个看上去好像很深奥的样子,但是只要结合中国的网络特色,这个便不难理解了。“北方服务器”、“南方服务器”、“电信服务器”、“网通服务器”…… 这些词听起来是那么熟悉。如果,一个北京的电信用户试图访问广东的网通服务器上打开一个网页时,你就能很深刻的理解。鉴于这个不是我们开发人员力所能及的准则,所以这里也就不多言了。
第三条:Add an Expires Header 添加周期头
这个也并非开发人员来控制,而是网站服务器管理员的职责。所以,如果作为开发人员的你不了解和明白也没有关系。还是把这个准则告诉公司的网站服务器管理员去处理吧。
第四条:Gzip Components 启用 Gzip 压缩
这个大家应该比较熟悉。Gzip 的思想就是把文件先在服务器端进行压缩,然后再传输。这对于体积较大的纯文字型的文件有特效。鉴于这也并非开发人员来控制,而是网站服务器管理人员的工作范畴,这里就不详细讲解了。如果你对此感兴趣,可以资讯公司的网站服务器管理人员。
第五条:Put CSS at the Top 把 CSS 样式放在页面的上方
无论是 HTML 还是 XHTML 还是 CSS 都是解释型的语言,而非编译型的语言。所以 CSS 放到上方的话,那么浏览器解析结构的时候,就已经可以对页面进行渲染。这样就不会出现,页面结构光秃秃的先出来,然后 CSS 渲染,页面又突然华丽起来,这样太具有“戏剧性”的页面浏览体验了。
第六条:Move Scripts to the Bottom 将脚本放在底部
原因同第五条一样。只是脚本一般是用来于用户交互的。所以如果页面还没有出来,用户连页面都不知道什么样子,那谈交互简直就是扯谈。所以,脚本和 CSS 正好相反,脚本应该放在页面的底部。
第七条:Avoid CSS Expressions 避免使用 CSS 中的 Expressions
首先有必要先说明一下 CSS Expressions 是什么一个东西。其实它就像其它语言中的 if …… else …… 语句。这样在 CSS 中就可以进行简单的逻辑判断了。但是 CSS 中 Expressions 的代价却是极高的。当你的页面需要根据判断来渲染效果的元素很多的时候,那么你的浏览器将长期处于假死状态,从而给用户带来极差的用户体验。
第八条:Make JavaScript and CSS External 将 JavaScript 和 CSS 独立成外部文件
这一条好像和第一条有点矛盾。的确,如果从 HTTP 的 request 请求数来讲的话,这样做的确是降低了效率。但是之所以这么做,是因为另外一个重要的考虑因素——缓存。因为外部的引用文件会被浏览器缓存,所以如果 JavaScript 和 CSS 体积较大的时候,我们将它们独立成外部文件。这样当用户 只要浏览一次以后,这些体积较大的 JS 和 CSS 文件就能被缓存起来,从而极高地提高用户再次访问时的效率。
第九条:Reduce DNS Lookups 减少 DNS 查询
DNS 域名解析系统。大家都知道我们之所以能记住那么多的网址,是因为我们记住的都是单词,而非 http://58.64.157.162 这样的东西,而帮我们把那些单词和 58.64.157.162 这样的 IP 地址联系起来的就是 DNS。那这一条对我们到底有什么真正意义上的指导意义呢?
其实有两条:
1、如果不是必须,请不要把网站放到两台服务器上。
2、网页中的图片、CSS 文件、JS 文件、Flash 文件等等,不要太多的分散在不同的网络空间中。这就是为什么那种只发一个网站中的壁纸图片的帖子,要比壁纸图片来源于不同网站的帖子显示要快得多的原因。
第十条:Minify JavaScript and CSS 减少 JavaScript 和 CSS 文件的体积
这点很好理解。在你的最终发布版本中把没有必要的空行、空格和注释全部去掉。显然手工去处理效率太低,好在网上到处都是用于压缩这些东西的工具。压缩 JavaScript 代码体积的工具随处可见,我便不再列举了,这里我只提供一个用于压缩 CSS 代码体积的在线工具网站 http://www.cleancss.com/ 它提供了多种压缩方式,可以适应多种要求。
第十一条:Avoid Redirects 避免跳转
我只从网页开发人员的角度来解读此条。那么我们可以解读到什么东西呢?
其实有两条:
1、“此域名已过期,5 秒钟以后,页面将跳转到 http://www.xxx.com/index.html 页面”,这句话看起来的确很熟悉。但是,我就奇怪了,为什么不直接链接到那个页面呢?
2、一些链接地址请更明确的写出来。例如:将 http://www.d2nb.com/ 写成 http://www.d2nb.com (注意最后面一个“/”符号)。的确,这两个网址都能访问到我的博客,但是,事实上,它们是有区别的。http://www.d2nb.com 的结果是个 301 响应,它会被重新指向 http://www.d2nb.com/ 。但是显然,中间多浪费了一些时间。
第十二条 Remove Duplicate Scripts 移除重复的脚本
这个准则的道理很浅显,但是真正在工作中,很多人却因为“项目时间紧”、“太累了”、“初期没有规划好”……这样的理由搪塞过去了。你的确可以找很多的理由不去处理这些多余重复的脚本代码,如果你的网站不需要更高的效率和后期维护的话。也正是这点,我提醒大家一些,一些 JavaScript 框架、 JavaScript 包一定要慎用。至少要问一下:用了这个 JS 到底给我们多少方便,提高了多少工作效率。然后,再与它因为多余的、重复的代码带来的负面效果比较一下。
第十三条:Configure ETags 配置你的实体标签
首先来讲讲什么是 ETag 吧。ETag(Entity tags)实体标签。这个 tag 和你在网上经常看到的标签云那种 tag 有点区别。这个 Etag 不是给用户用的,而是给浏览器缓存用的。Etag 是服务器告诉浏览器缓存,缓存中的内容是否已经发生变化的一种机制。通过 Etag,浏览器就可以知道现在的缓存中的内容是不是最新的,需不需要重新从服务器上重新下载。很遗憾作为网页开发人员对此无能为力。它依然是网站服务器人员的工作范畴。如果,你对此有兴趣,可以咨询公司的网站服务器管理员。
第十四条:Make Ajax Cacheable 上面的准则也适用 Ajax
现在的 Ajax 好像有点被神话了,好像网页只要 Ajax 了,那么就不存在效率问题了。其实这是一种误解。拙劣的使用 Ajax 不会让你的网页效率更高,反而会降低你的网页效率。Ajax 的确是个好东西,但是请不要过分的神话它。使用 Ajax 的时候也要考虑上面的那些准则。
后记:
当然,上面的这些也只是供你参考的理论上的准则。具体的情况还是要具体的去对待。理论和准则只是用来指导现实工作的,却是万万不可死记硬套。
浙公网安备 33010602011771号