2009 - 06 - 07

使用Google Page Speed优化Web前端性能

Published by at 16:33 under 未分类

安装好以后,打开Firebug,可以看到新增的两个标签页:Page Speed与Page Speed Activity,如下图所示:

使用Page Speed

其中,Page Speed标签页包括两个功能:Analyze Performance与Show Resources,其中Analyze Performance是Page Speed的核心功能。点击以后Page Speed开始工作,几秒钟以后就会得出一份详细的性能分析报告:

Page Speed分析报告

其中各项按照重要性进行排序,展开每一部分,可以得到详细的报告。其中,红色图标表示未进行优化,黄色表示可以进行进一步优化,绿色表示已经进行优 化。

其余部分的功能可以在Google Code的官方主页上找到,这里就不赘述了,只重点介绍Analyze Performance这一功能。

性能优化技巧

其实上图的每一项都是Page Speed提供的优化标准,Page Speed就是按照这一条条标准进行分析的。需要拿出来讲的包括:

使用gzip压缩

这里放在第一,是性能优化效果最显著的一步。所谓gzip压缩是一种开发的压缩算法,目前的主流浏览器(, Safari, Chrome, IE4及以上)与主流服务器(Apache, Lighttpd, Nginx)均对其有很好的支持。gzip压缩是通过HTTP 1.1协议中的Content-Encoding : gzip来进行标记说明,其可以明显减少文本文件的大小,从而节省带宽和加载时间。我做过的一个实验,发现启用gzip后,jquery 1.2.6 minify版本的大小从54.4k减少到16k,减少了70%。gzip适用的情况包括:

  • HTML\CSS\JavaScript文件,gzip算法对于文本文件的效率比较高,而jpg/gif/png/pdf等二进制文件本身已经进 行了一次压缩,再使用gzip的成效已经不明显了。而且gzip压缩需要消耗服务器的资源,而解压缩需要消耗浏览器的资源,对于比较大的二进制文件具有非 常高的性能消耗;
  • 尽量使用一种大小写方式,要么全部大写,要么全部小写。学过数据结构和算法的同学一定知道压缩其本身就是对冗余信息熵进行压缩,如何数据原素的类 型种类太多,其信息冗余度会降低,从而压缩率降低;
  • 过小的文件(通常小于150个字节)不宜进行gzip压缩,因为gzip会在文件头加入相关信息,对于小文件反而会增加文件的长度;

关于各服务器如何启用gzip,可以参加相关文档说明。

如何检查gzip是否启用?使用Firebug,在Net模块中进行检查HTTP Header是否有Content-Encoding gzip标记,参见下图:

gzip压缩检查

最小化JS和图片

对于JavaScript文件本身具有非常大的优化空间。所谓JavaScript压缩,就是通过一些工具将函数、变量名进行优化(其实就是尽可能 缩短变量名长度),消除多余字符(比如空格、换行符、注释等),最终得到的代码可以在分析和执行上得到性能提升。压缩后得到的代码对于机器而言是可读的, 对于人来说就不行了,因为文件内容已经面目全非。所以压缩一般用于生产期的代码,不能使用于开发期。

同样的道理,图片内容中也有一定的冗余信息,比如文件头部的一些内容描述(这些内容在jpg)图片上尤其如此。通过一定的工具(比如GIMP)可以 去除这些信息,从而节省一定的空间。

幸运的是,Page Speed已经内置了这些功能,我们不需要找第三方的工具。如下图所示,可以看到对JS文件进行最小化可以得到的预期效果:

JavaScript最小化

比如jquery.form.js,最小化后减少11.9kb,减少54.8%的空间。点击minified version,在新窗口中可以看到Page Speed为你优化好的版本,直接更新到服务器就可以了。

关于图片优化,操作方法同上。

启用浏览器缓存

这是经常使用的方法。当请求的资源在浏览器本地得到缓存后,第二次请求这些内容就可以从直接缓存中取出,减少了连线的HTTP请求。

HTTP 1.1提供的缓存方法主要有两种:

  • Expires and Cache-Control: max-age. 即内容在缓存中的生命有效期。第一次请求后,在生命有效期之内的后期请求直接从本地缓存中取,不过问服务器;
  • Last-Modified and ETag. 其中Last-Modified标记文件最后一次修改的时间,浏览器第二次请求是在头部加入上次请求缓存下来的Last-Modified时间,如何两次 请求期间服务器的内容没有进行修改,服务器直接返回304 Not Modified,浏览器接到以后直接使用本地缓存。否则,服务器会返回200以及更新后的版本。ETag是服务器对于文件生成的Hash散列,其生成算 法与最后一次修改的时间相关。浏览器第二次请求发送上次的ETag信息,服务器通过简单的比对就知道是否应该返回304还是200。

关于各缓存头部的设置可以参考各服务器的相关文档。

JavaScript延迟加载

通常浏览器在解析HTML时遇到JS文件会先下载,解析执行后才会下载后面的内容,期间自然会造成一定的延时。为了提高性能,尽可能将JS文件的位 置后移,如果可能,还可以通过部分代码进行异步加载。另外,对于JS和CSS在必须放置在一起情况,需要报JS放置在CSS之后,这样CSS与JS文件可 以同步下载。

文件拼接

这里主要包括JS/CSS等文本文件和图片。对于文本文件,尽可能将同一类型放置到一个文件中,减少HTTP请求。对于CSS背景图片,可以使用 Sprit技术将图片拼接到一起,然后使用background-position属性选择对应的图片。Google首页上的这个图片就是一个很好的例 子:

Google Sprite

其它

更多优化规则,可以参考Page Speed的说明以及Steve Souders个人主页上的相 关信息。

结论

虽然现在网络速度越来越快,前端优化仍然非常重要;永远不要假设用户的网络速度 和你一样快,毕竟由于ISP的各方面原因,各地的速度大不相同。良好的策略可以在有限的带宽资源下达到最大的性能发挥。

这个世界需要丰富的应用,更加需要高效的应用。

4 responses so far

4 Responses to “使用Google Page Speed优化Web前端性能”

  1. zhuimengon 11 12月 2010 at 18:55

    学习了

  2. 594lhnon 09 5月 2011 at 11:31

    很不错

  3. 594lhnon 09 5月 2011 at 11:33

    我刚才请别人做的一个站www.jimmychoonline.com,速度很慢,谷歌里面说比99%的站都慢,打击啊

Trackback URI | Comments RSS

评论