Google提供的page-speed工具详细用法

Google提供的page-speed工具详细用法：
一、工具的准备

　　1、电脑需安装浏览器Firefox;

　　2、安装Firefox的组件：Firebug和page-speed。

二、工具的使用

　　1、用Firefox打开首页;

　　2、选择“工具”-“firebug”或者使用快捷键F12，弹出firebug工具

       3、点击“Analyze Performance”对网页性能进行分析，

三、对报告的说明分析

　　1、“Page Speed Score：83/100”

　　说明：本页面的性能分数为83分，总分100分。

　　2、报告内容图标的说明：

　　(1)“红色叹号”为没有进行过优化的内容，需要进行优化的内容：

　　a、“Leverage browser caching”：浏览器缓存文件

说明：列表中的内容(如图片)没有定义缓存过期时间，只有设置了缓存过期时间，等文件过期后才会重新进行缓存，所以该项内容需要进行优化，对图片的缓存过期时间进行设置。

　　b、“Specify image dimensions”：指定图片的尺寸

说明：列表中的图片都没有在代码中设置图片的大小，比如代码中的<img src=“/images/1new/city_ico_2.gif” />，没有添加width=“15” height=“13”，没有添加width=“15” height=“13”的属性，浏览器在加载的时候就要计算图片的尺寸，增加了加载时间。所以优化方式为：对网页中的图片指定尺寸。

　　c、“Parallelize downloads across hostnames”：平衡文件的下载主机来源，也就是将文件分配到不同的服务器上，分摊压力。

　　说明：这方面可以通过增加独立服务器才能实现，。

(2)“黄色三角”为需要进一步优化的内容

　　a、“Combine external JavaScript”：合并外部的JS文件

合并JS文件，降低浏览器对JS文件的读取，有效的减少http的请求数量。

　　b、“Enable compression”：启用压缩，这里提到时启用gzip格式的压缩

说明：该列表中详细提供了这些资源通过gzip压缩后能够节省多少时间成本。下面是对gzip的解释：所谓gzip压缩是一种开发的压缩算法，目前的主流浏览器与主流服务器 (Apache， Lighttpd， Nginx)均对其有很好的支持。gzip压缩是通过HTTP 1.1协议中的Content-Encoding ： gzip来进行标记说明，其可以明显减少文本文件的大小，从而节省带宽和加载时间。

　　c、“Remove unused CSS”：移除不用的CSS代码

说明：在网站的CSS文件中可能会存在一些用不到的代码，这项工作应该在网站的发布之前对CSS，JS文件进行检查，删除没有用到的代码，该列表中详细的列出了没有用到的CSS代码。

　　(3)“绿色对勾”为已经进行过优化，暂不需要优化的内容。

 

 来源：A5

 

<<--------------------------------------------------------------------------------------------------------------------------------->> 

导言

google page speed 该工具采用了现在大家公认的影响用户端页面下载性能的评价指标

²       Optimize caching

²       Minimize round trip times

²       Minimize request size

²       Minimize payload size

²       Optimize browser rendering

 

 

在运行后，根据这些指标，该工具会按照每条的标准，给出一个改进的优先度建议报告。有些建议是可以明显改善用户端页面的性能，有些只能一般效果改善页面下载的性能。下面是一个用户使用后对这些建议给出的一些解决方法及肯定的评价。同时使用该工具对部分建议的质疑。觉得对自己了解和使用该工具就帮助。记录之。

 

 

明显产生性能提高的优化方法

一、Leverage browser caching-使用浏览器cache

The following resources are missing a cache expiration. Resources that do not specify an expiration may not be cached by browsers. Specify an expiration at least one month in the future for resources that should be cached, and an expiration in the past for resources that should not be cached

每个页面浏览时让浏览器请求静态内容是相当无用的。许多内容像图片、Js 和 css file ,很少改变，所以应该在浏览中缓存很长一段时间。

如何安全而高效地使用浏览器的cache—

例子

Rails uses a nifty little trick, that makes clientside caching fairly safe. It puts the timestamp of each files last modification at the end of each asset request (that’s why images in Rails applications are usually addressed as /images/foo.png?74734234). This means that the asset will get a new URL when it’s changed, so we can cache it under the old URL for a long’ish time.

Using Apache and mod_expires we can simply add the following to our site configuration:

<Directory /var/www/lokalebasen/production/current/public>

  ExpiresActive On

  ExpiresDefault "access plus 1 month"

</Directory>

The public directory contains only cacheable contents, so we can set a blanket rule for the entire directory, and we’ll just let the browser cache those assets for a full month.

The following cacheable resources have a short freshness lifetime. Specify an expiration at least one month in the future for the following resources: http://www.google-analytics.com/ga.js

二、Combine external JavaScript—联合外部的的js

There are 8 JavaScript files served from www.lokalebasen.dk. They should be combined into as few files as possible.

当程序中不得不使用几个小的JS文件。这些小文件需要额外的HTTP requests。

最多数的情况是所有这些文件都可以容易地结合成一个js.这样浏览器仅仅需要建立一个HTTP 连接。所有的文件的属性被结合在一起，并且缓存成一个文件--All.js

三、Parallelize downloads across hostnames 通过使用多个hostname 并行下载

This page makes 28 parallelizable requests to www.lokalebasen.dk. Increase download parallelization by distributing these requests across multiple hostnames:

预设情况下，很多的浏览器不能在相同时间内从同一个服务器下载多于两个文件。我们推测是阻止用户造成服务器的超载。然而，在这个年代，带宽和服务器能量是充足的，足够应付并行的多数下载。大多数的网站能够处理超出这种限制的下载。

让浏览器建立更多链接的的一种方式是从一个或更多hostname 中提供静态的内容。这些hostname 可能或不可能指向不同的服务器或者一个CDN.但是这些浏览器并不知道。

例子：

We can configure Rails to use asset hosts in the production.rb configuration file:

config.action_controller.asset_host = "http://assets%d.lokalebasen.dk"

The above tells rails to assets0-3.lokalebasen.dk for our assets. If we want to configure more detailed asset host usage, we can pass a Proc to asset_host, like so:

config.action_controller.asset_host = Proc.new { |source|
  "http://assets#{rand(2) + 1}.lokalebasen.dk"
}

This tells Rails to use 2 asset hosts (assets1 and assets2) which in turn means 4 parallel requests from the browser rather than 2 - in addition to the two connections that might be fetching data from the application.

Now, all we have to do is to setup the hostnames as CNAMEs for www.lokalebasen.dk and we’ve increased “download parallelization” (and the load on our server, but that should be minimal with the caching changes that’s implemented above).

 

产生中等性能提高的优化方法

一、Minify JavaScript—减少JS 文件

这种方式没有上面所说的将js文件联合起来的产生的性能优化明显。

二、Optimize images—优化图片

There are 63kB worth of images. Optimizing them could save ~15.9kB (25.3% reduction).

Google 不仅仅检查出大的图片文件，同时能压缩图像。压缩后的图片在工具中直接另存为就可以使用。

该工具的另一个好处是，它可以提示页面中那些图片实际的图片比你看到的要大。并且修正图片的尺寸到他们合适的尺寸。这个节约页面字节的好方式。

三、Remove unused CSS—移除无用的CSS

75.9% of CSS (estimated 27.1kB of 35.7kB) is not used by the current page.

去掉无用的CSS明显是个伟大的建议。但是该插件并没有方法知道什么内容是正在使用的什么内容没有使用。

插件只能分析当前的页面，并且移除在一个页面中的style并不是一个好主意。有谁能整个应用所有页面中的css .分析那些css是可以使用的。

四、Serve static content from a cookieless domain—从一个cookiless domain 来提供静态内容

Serve the following static resources from a domain that doesn’t set cookies:
…
8.6kB of cookies were sent with the requests for these resources.

这种建议我以前没有留意。通常所有的服务器来的反应包括cookie的头部，并不是明确地需要进行cache。这种情况并不同于图片、JS 、css的cache。

我猜想只是在我们的服务器中操作所要求的很少的几行代码关闭cookie

五、Use efficient CSS selectors—使用有效的css选择器

/stylesheets/all.css?1248691631 has 63 very inefficient and 95 inefficient rules of 411 total rules.

我以前从未认识到一些CSS selectors 之间有很明显的效率差别。看着是有道理的，但是，对于这个提示有点引导我们进入黑魔力领域。如果有个工具能测试出所给的CSS selector的实际效率，将是很酷的。这样我们就可以评测那些改变是值得进行的。我的本能反应是这个建议仅仅提高最后的毫秒级。

结果：

我们在执行能明显提高性能的的工作中，仅仅改变了3 个文件和11 行的配置代码。进行了不到一个小时的工作。如果你问我结果，这是非常好的投资。