朝心

安装好以后，打开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压缩是一种开发的压缩算法，目前的主流浏览器(Firefox, 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个人主页上的相 关信息。

结论

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

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

如果你对YSlow比较熟悉的话，那么一定会知道YSlow用于衡量网页速度的14条标准，而“Page Speed”有20条衡量标准，那么他们之间的到底有什么不同呢？Google又会给我们带来什么新的观点呢？

补充一下：如果你对YSlow的14条衡量标准不熟悉的话，您可以阅读一下，我以前写的两篇文章，分别是《如何提高网页的效率（上篇）——提高网页效率的14条准则》和《如何提高网页的效率（下篇）——Use YSlow to know why your web Slow》，文章较为详细的介绍了YSlow这个工具的使用，以及YSlow的14条衡量标准。这两篇文章同时也被收录到了《博客园精华集-web标准之道》一书当中。

继续补充：如果你想非常详细的了解YSlow的14条衡量标准的超详细讲解，那么你可以购买一本书，书的名字叫做：《高性能网站建设指南》，书的封面是一条经常出现在《人与兽》一类电影中的那种狗狗。

高性能网站建设指南OK，不扯那么多了，让我们回到正题：“Page Speed”的20条衡量标准到底是什么呢？

Put CSS in the document head

将你的CSS样式表文件放在整个页面的头部。没有什么难理解的。css先下载下来，就能更快的渲染网页效果。从而让人们感觉网页速度很快。

更多关于”Put CSS in the document head”的更多详细解释，请看官方文档。

Use efficient CSS selectors

使用效率更高的CSS选择符。举个很简单的例子：尽量不要使用*号选择符：

*{padding:0;margin:0}

像这样的得分会很低，正确的办法应该是只对你想设置的标签元素进行设置，例如：

html, body, div, span, applet, object, iframe,

h1, h2, h3, h4, h5, h6, p, blockquote, pre,

a, abbr, acronym, address, big, cite, code,

del, dfn, em, font, img, ins, kbd, q, s, samp,

small, strike, strong, sub, sup, tt, var,

b, u, i, center,

dl, dt, dd, ol, ul, li,

fieldset, form, label, legend,

table, caption, tbody, tfoot, thead, tr, th, td {

    margin: 0;

    padding: 0;

}

如果你对本条有更多的兴趣，可以去看Use efficient CSS selectors官方文档的详细解释。

Leverage proxy caching

代理缓存。这个名词听起来好像很屌的样子，以至于我也是查了资料才知道：所谓proxy cacheing，就是一种公共缓存，用于静态资源，允许浏览器从最近的代理服务器上，而不是从远程的原始服务器，下载这些静态资源。这些代理服务器，通 常而言就是有ISP，接入服务商所提供的。

这样的代理服务器缓存可以让通过同一ISP接入服务的用户共享这些静态资源，而节省原始服务器的带宽，以及下载速度也会大大提高，特别是对于局域网 的用户有特别的好处。

关于“Leverage proxy caching”的文档资料，请看官方文档的详细解释。

Minify JavaScript

最小化JavaScript脚本。这个貌似没有什么好说的，压缩一下你的JavaScript脚本吧。

关于“Minify JavaScript”的更多文档资料，请看官方文档的详细解释吧。

Optimize images

优化图片，其实最经常使用的就是css script了，也有翻译为“css精灵”的，虽然翻译的很美好，但是其实很简单，就是将多个图形，放在张图片文件中。这样，可以有效的减少http请求 的数量。

如果你对“Optimize images”有更多的兴趣，可以看这个。一个css cript的示例： 《【CSS翻转门】技术实例讲解（附源码下载）》。

Minimize cookie size

最小化你的cookie。cookie的确是个好东西，他可以让你在用户的客户端保存一些东西，但是，千万不要什么都往用户口袋里面塞。原因很简 单，cookie大小有限，有最大限制，而且cookie过大会减慢网页呈现的速度。另外为了安全性考虑，也不要把所有的什么破铜烂铁都塞到cookie 里面。

关于“Minimize cookie size”的更多文档资料：看这里。

Enable gzip compression

使用gzip压缩。详细这个大家应该已经比较熟悉了。说白了就是服务器向浏览器发的是经过压缩的页面，这样传输的字节就会大大减少，速度自然也就快 了。

这幅图说明了gzip技术的工作原理欲了解更多的“Enable gzip compression”资料，请看官方文档。

Combine external JavaScript

合并外部的JavaScript文件。道理很简单，依然是为了少读取.js文件，从而有效的减少http请求数量。

合并外部的JavaScript文件可以有效的减少http请求数量更多的关于“Combine external JavaScript”的文档，可以看这个。

Minimize DNS lookups

最小化DNS查询。详情请看这个：Minimize DNS lookups规则详情。

Optimize the order of styles and scripts

优化样式表和脚本的顺序。如果你要是看过老赵的《挣脱浏览器的束缚》系列的话（本系列也已经收录到《博客园精华集-web标准之道》一书中）。就知道IE浏览器对同一个域名下的文件，同时只能下载2个文件。所 以，到底先让哪些样式表先下载下来，让哪些脚本先下载下来，这个顺序就非常重要了。所以，如果有可能，请重视一下样式表和脚本的顺序吧。推荐的做法是：将 css放在js文件上面，让css文件先被加载，这样就可以先让网页渲染出来，从而加快浏览者的感知速度。

IE浏览器对同一个域名下的文件，同时只能下载2个文件关于“Optimize the order of styles and scripts”更多详情，请看这个。

Serve resources from a consistent URL

相同的资源，使用相同的url地址。道理很好理解，如果是相同的一张图片，就不要东方一下，西方一下，然后引用的时候使用不同的url地址。为什么 要这样做，道理也很简单，因为——缓存！

更多“Serve resources from a consistent URL”详情，请看这里

Avoid CSS expressions

避免CSS表达式。这个我在《如何提高网页的效率（上篇）——提高网页效率的14条准则》一文中也有讲到。现在需要补 充的是：IE8已经不再支持css表达式功能。

关于“Avoid CSS expressions”，更多详情看这里。

Parallelize downloads across hostnames

通过不同的主机同时下载网页资源。这个的道理已经在“Optimize the order of styles and scripts”这一准则中讲述过。道理依然是老赵的《挣脱浏览器的束缚》提到的原因：IE浏览器对同一个域名下的文件，同时只能下载2个文件。

更多关于“Parallelize downloads across hostnames”的详情，可以看这个。

Combine external CSS

合并外部的css文件。这条和“Combine external JavaScript”准则的道理一样。还是为了减少http请求数量。

关于“Combine external CSS”的更多详情，可以看这个。

Specify image dimensions

明确的指明图片的高度和宽度。很久很久以前，long long ago。一个同学问我：“明确的指明图片的宽度和高度，是否能加快页面的渲染速度？”当时我的答案是：“这个应该没有关系吧！”。看来，当时的我是误人子 弟了。明确的指出图片的高度和宽度，能够有效的加快浏览器在渲染图片周围布局和绘制呈现时的速度。

更多关于“Specify image dimensions”的详情，可以看这里。

Minimize redirects

尽量避免重定向。道理很简单，你从A地点到你的同事B先生家，到了那里，他的邻居告诉你，B先生已经搬家了，搬到了C地点，于是，你又跑到C地点， 然后C地点有个人告诉你，B先生现在又搬家了，已经搬到了D地点。于是你又跑到了D地点，才找到了这个B同事。而这个装B的B同事，告诉你，你如果直接就 来D地点，就不用那么麻烦了，而且速度也会更快一些。网页的跳转和重定向的道理是一样的。

关于“Minimize redirects”的详细文档，可以看这里。

Defer loading of JavaScript

延期加载JavaScript。这个听起来真是个高科技的东西呀。其实这玩意还真是非常的有效呀。不仅可以延期加载脚本，像一些大的图片、 flash也都可以延期加载。其实实现原来也不是很难，就是先不加载一些比较大的东西，当页面加载完毕后，再加载那些东西。

关于“Defer loading of JavaScript”的更多详情，请看这里。

Google刚刚开源了Page Speed，这是一个Google优化其网站，特别是加速网页加载的内部工具。

Page Speed是运行在Firebug里 的Firefox插件。该工具可以运行在Linux、Mac和Windows XP/Vista之上。Page Speed在运行时会分析一些Web服务器配置和服务器上下载下来的代码，还会创建一个结果列表，其中包括如何改进网页的建议。分析基于一个分为五类的最佳实践列表：

• 优化缓存—— 让你应用的数据和逻辑完全避免使用网络
• 减 少回应时间——减少一连串请求-响应周期的数量
• 减小请求大小—— 减少上传大小
• 减小有效负荷大 小——减小响应、下载和缓存页面的大小
• 优化浏览器 渲染——改善浏览器的页面布局

这些实践考虑了页面加载时间，以及发出页面请求到客户端看到结果之间的时间。页面加载时间包括创建TCP连接、解析DNS名称、发送 请求、获取（包括来自于缓存的）资源、执行脚本、渲染。

该工具提出的建议有：

• 避 免使用CSS表达式
• 结 合使用外部的CSS
• 结 合外部的JavaScript
• 推 迟JavaScript的加载
• 启 用gzip压缩
• 利 用浏览器缓存
• 利 用代理缓存
• 减 少JavaScript
• 减 小Cookie大小
• 减 少DNS查找
• 减 少重定向
• 优 化图片
• 优 化样式和脚本的顺序
• 跨 主机名并行下载
• 将 CSS放在文件头部
• 删 除用不到的CSS
• 始 终从一个URL为资源提供服务
• 在 没有Cookie的域里处理静态内容
• 指 定图片尺寸
• 使 用有效率的CSS选择器

这些建议根据优先级排列。比如说，在加载Facebook的主页时，已知的高优先级建议是：“在文件头部先包含外部的JavaScript文件，然 后再将外部的CSS文件包含进来。为了保证并行下载CSS文件，始终要在包含外部JavaScript之前先包含外部CSS。”

Page Speed的活动版面显示了所有浏览器的活动，包括网络事件和JavaScript代码完成的时间（单位：毫秒）。要想看看在尝试加载特定页面时，浏览器 在哪里花费了最多的时间，这是非常有用的。总之对Web开发人员来说，Page Speed似乎是一个必备的工具。

查看英文原文：Google Has Open Sourced Page Speed

http://spreadsheets.google.com/pub?key=rcz-FpRKSsvyQUnLL1UMjcg&single=true&gid=0&output=html
中国互联网网站集体维护日