前端性能测试优化建议
为转帖：具体看地址http://blog.csdn.net/zhengsj/article/details/2691456
Yahoo提高网站性能34条最佳实践一
对于前台后台程序员 下面这些都应该是大家在工作要注意的
减少HTTP请求
80%的客户端响应时间耗费在前端上。而其中大部分的时间又用在下载所有页面中需要的资源：图片，样式表，脚本，Flash等等。依次减少渲染页面所需的资源和HTTP请求的数量。这是加速页面显示的关键。
一种减少资源数量的方法是简化页面的设计（- - ||真是个好主意）。但有没有方法在获取快速响应的前提下有一个丰富内容的页面呢？这里有一些能够在不减少页面内容的前提下减少HTTP请求数的技术。
合并文件是一种通过把所有脚本合并到一个脚本中来达到减少HTTP请求数目地的方法，同样也适用于CSS。在不同页面需要不同脚本和样式表的情况下要合并文件显的更为困难，但是把这个做为你发布工程的一部分来改善响应时间。
CSS Sprites是一个很好的减少图片请求数的技巧。把你的背景图合并到一张图片中，使用CSS的background-image和background-position属性去显示需要的部分。
Image maps把多张图片合并到一张图片上。整体的尺寸几乎相同，但是因为减少了HTTP请求数而加速了页面的显示。Image maps仅仅在连续使用的图片下才能起作用，如导航条。制定image maps的坐标是一件枯燥，容易出错的工作。使用image maps的导航条也不易于访问，所以这个不被推荐。
Inline images 使用data: URL scheme来将图片数据嵌入到实际页面中。这样做会增加HTML文档的体积。把inline images合并到你的样式表中能够在避免页面体积增大的前提下减少HTTP请求。Inline images目前还被所有主流浏览器支持。
为你的页面减少HTTP请求数是第一步。这是改善初次访客体验的最重要的原则。正如Tenni Theurer的博客文章Browser Cache Usage - Exposed!中描述的那样，40-60%的网站日常访客都是以一个空缓存的状态进入的。因此为那些初次访客（事实上是空缓存用户）优化是获得一个良好用户体验的关键。
使用CDN（Content Delivery Network）
用户与你网站服务器的接近程度会影响响应时间的长短。把你的网站内容分散到多个、处于不同地域位置的服务器上可以加快下载速度。但是首先我们应该做些什么呢？
按地域布置网站内容的第一步并不是要尝试重新架构你的网站让他们在分发服务器上正常运行。根据应用的需求来改变网站结构，这可能会包括一些比较复杂的任务，如在服务器间同步Session状态和合并数据库更新等。要想缩短用户和内容服务器的距离，这些架构步骤可能是不可避免的。
要记住，在终端用户的响应时间中有80%到90%的响应时间用于下载图像、样式表、脚本、Flash等页面内容。这就是网站性能黄金守则。和重新设计你的应用程序架构这样比较困难的任务相比，首先来分布静态内容会更好一点。这不仅会缩短响应时间，而且对于内容分发网络来说它更容易实现。
内容分发网络（Content Delivery Network，CDN）是由一系列分散到各个不同地理位置上的Web服务器组成的，它提高了网站内容的传输速度。用于向用户传输内容的服务器主要是根据和用户在网络上的靠近程度来指定的。例如，拥有最少网络跳数（network hops）和响应速度最快的服务器会被选定。
一些大型的网络公司拥有自己的CDN，但是使用像Akamai Technologies，Mirror Image Internet， 或者Limelight Networks这样的CDN服务成本却非常高。对于刚刚起步的企业和个人网站来说，可能没有使用CDN的成本预算，但是随着目标用户群的不断扩大和更加全球化，CDN就是实现快速响应所必需的了。以Yahoo来说，他们转移到CDN上的网站程序静态内容节省了终端用户20%以上的响应时间。使用CDN是一个只需要相对简单地修改代码实现显著改善网站访问速度的方法。
添加一个Expire或者缓存控制的头部
在这个规则中有两个要点：
对于静态的资源：通过设置超长的过期头部实行“永不过期”策略
对于动态的资源：使用一个合适的缓存控制头部来帮助浏览器处理有条件的请求。
网页设计得越来越丰富多彩，这意味着更多的脚本，样式表，图片和Flash存在于网页上。一个网页的初次访客需要发送一些 HTTP请求，通过设置过期头部你可以缓存这些资源。从而在用户访问接下来的页面时避免了不必要的HTTP请求。过期头部常用于图片，实际上应该对所有资源应用过期头部包括脚本，样式表和Flash等。
浏览器（和代理）使用一个缓存来减少ＨＴＴＰ请求的数量和尺寸，使得网页加载得更快。一个服务器在HTTP响应中使用过期头部来告诉客户端一个资源能够被缓存多久。下面是一个超长的过期头部，告诉浏览器这个资源在2010年4月15前不会过期。
Expires: Thu, 15 Apr 2010 20:00:00 GMT
如果你服务器是Apache，使用ExiresDefault设置一个过期时间。这是一个把过期时间设置到10年以后的例子。
ExpiresDefault “access plus 10 years”
记得，如果你使用一个超长的过期头部，你如果想改动资源就必须改资源的名称。在Yahoo!我们常常把这个做为发布过程中的一部分：一个版本号被做为资源名称的组成部分，例如，yahoo_2.0.6.js
使用一个超长的过期头部只在用户已经访问你的网站以后产生影响。当一个初次访问，空缓存的用户来到你的网站时它是不起作用的。
把资源Gzip
网络传输中的HTTP请求和应答时间可以通过前端机制得到显著改善。的确，终端用户的带宽、互联网提供者、与对等交换点的靠近程度等都不是网站开发者所能决定的。但是还有其他因素影响着响应时间。通过减小HTTP响应的大小可以节省HTTP响应时间。
从HTTP/1.1开始，web客户端都默认支持HTTP请求中有Accept-Encoding文件头的压缩格式：
Accept-Encoding: gzip, deflate
如果web服务器在请求的文件头中检测到上面的代码，就会以客户端列出的方式压缩响应内容。Web服务器把压缩方式通过响应文件头中的Content-Encoding来返回给浏览器。
Content-Encoding: gzip
Gzip是目前最流行也是最有效的压缩方式。这是由GNU项目开发并通过RFC 1952来标准化的。另外仅有的一个压缩格式是deflate，但是它的使用范围有限效果也稍稍逊色。
Gzip大概可以减少70%的响应规模。目前大约有90%通过浏览器传输的互联网交换支持gzip格式。如果你使用的是Apache，gzip模块配置和你的版本有关：Apache 1.3使用mod_zip，而Apache 2.x使用moflate。
浏览器和代理都会存在这样的问题：浏览器期望收到的和实际接收到的内容会存在不匹配的现象。幸好，这种特殊情况随着旧式浏览器使用量的减少在减少。Apache模块会通过自动添加适当的Vary响应文件头来避免这种状况的出现。
服务器根据文件类型来选择需要进行gzip压缩的文件，但是这过于限制了可压缩的文件。大多数web服务器会压缩HTML文档。对脚本和样式表进行压缩同样也是值得做的事情，但是很多web服务器都没有这个功能。实际上，压缩任何一个文本类型的响应，包括XML和JSON，都值得的。图像和PDF文件由于已经压缩过了所以不能再进行gzip压缩。如果试图gizp压缩这些文件的话不但会浪费CPU资源还会增加文件的大小。
Gzip压缩所有可能的文件类型是减少文件体积增加用户体验的简单方法。
把样式表放在顶端
在研究Yahoo!的性能表现时，我们发现把样式表放到文档的<head />内部似乎会加快页面的下载速度。这是因为把样式表放到<head />内会使页面有步骤的加载显示。
注重性能的前端服务器往往希望页面有秩序地加载。同时，我们也希望浏览器把已经接收到内容尽可能显示出来。这对于拥有较多内容的页面和网速较慢的用户来说特别重要。向用户返回可视化的反馈，比如进程指针，已经有了较好的研究并形成了正式文档。在我们的研究中HTML页面就是进程指针。当浏览器有序地加载文件头、导航栏、顶部的logo等对于等待页面加载的用户来说都可以作为可视化的反馈。这从整体上改善了用户体验。
把样式表放在文档底部的问题是在包括Internet Explorer在内的很多浏览器中这会中止内容的有序呈现。浏览器中止呈现是为了避免样式改变引起的页面元素重绘。用户不得不面对一个空白页面。
HTML规范清楚指出样式表要放包含在页面的<head />区域内：“和<a />不同，<link />只能出现在文档的<head />区域内，尽管它可以多次使用它”。无论是引起白屏还是出现没有样式化的内容都不值得去尝试。最好的方案就是按照HTML规范在文档<head />内加载你的样式表。
Yahoo提高网站性能34条最佳实践一
对于前台后台程序员 下面这些都应该是大家在工作要注意的
减少HTTP请求
80%的客户端响应时间耗费在前端上。而其中大部分的时间又用在下载所有页面中需要的资源：图片，样式表，脚本，Flash等等。依次减少渲染页面所需的资源和HTTP请求的数量。这是加速页面显示的关键。
一种减少资源数量的方法是简化页面的设计（- - ||真是个好主意）。但有没有方法在获取快速响应的前提下有一个丰富内容的页面呢？这里有一些能够在不减少页面内容的前提下减少HTTP请求数的技术。
合并文件是一种通过把所有脚本合并到一个脚本中来达到减少HTTP请求数目地的方法，同样也适用于CSS。在不同页面需要不同脚本和样式表的情况下要合并文件显的更为困难，但是把这个做为你发布工程的一部分来改善响应时间。
CSS Sprites是一个很好的减少图片请求数的技巧。把你的背景图合并到一张图片中，使用CSS的background-image和background-position属性去显示需要的部分。
Image maps把多张图片合并到一张图片上。整体的尺寸几乎相同，但是因为减少了HTTP请求数而加速了页面的显示。Image maps仅仅在连续使用的图片下才能起作用，如导航条。制定image maps的坐标是一件枯燥，容易出错的工作。使用image maps的导航条也不易于访问，所以这个不被推荐。
Inline images 使用data: URL scheme来将图片数据嵌入到实际页面中。这样做会增加HTML文档的体积。把inline images合并到你的样式表中能够在避免页面体积增大的前提下减少HTTP请求。Inline images目前还被所有主流浏览器支持。
为你的页面减少HTTP请求数是第一步。这是改善初次访客体验的最重要的原则。正如Tenni Theurer的博客文章Browser Cache Usage - Exposed!中描述的那样，40-60%的网站日常访客都是以一个空缓存的状态进入的。因此为那些初次访客（事实上是空缓存用户）优化是获得一个良好用户体验的关键。
使用CDN（Content Delivery Network）
用户与你网站服务器的接近程度会影响响应时间的长短。把你的网站内容分散到多个、处于不同地域位置的服务器上可以加快下载速度。但是首先我们应该做些什么呢？
按地域布置网站内容的第一步并不是要尝试重新架构你的网站让他们在分发服务器上正常运行。根据应用的需求来改变网站结构，这可能会包括一些比较复杂的任务，如在服务器间同步Session状态和合并数据库更新等。要想缩短用户和内容服务器的距离，这些架构步骤可能是不可避免的。
要记住，在终端用户的响应时间中有80%到90%的响应时间用于下载图像、样式表、脚本、Flash等页面内容。这就是网站性能黄金守则。和重新设计你的应用程序架构这样比较困难的任务相比，首先来分布静态内容会更好一点。这不仅会缩短响应时间，而且对于内容分发网络来说它更容易实现。
内容分发网络（Content Delivery Network，CDN）是由一系列分散到各个不同地理位置上的Web服务器组成的，它提高了网站内容的传输速度。用于向用户传输内容的服务器主要是根据和用户在网络上的靠近程度来指定的。例如，拥有最少网络跳数（network hops）和响应速度最快的服务器会被选定。
一些大型的网络公司拥有自己的CDN，但是使用像Akamai Technologies，Mirror Image Internet， 或者Limelight Networks这样的CDN服务成本却非常高。对于刚刚起步的企业和个人网站来说，可能没有使用CDN的成本预算，但是随着目标用户群的不断扩大和更加全球化，CDN就是实现快速响应所必需的了。以Yahoo来说，他们转移到CDN上的网站程序静态内容节省了终端用户20%以上的响应时间。使用CDN是一个只需要相对简单地修改代码实现显著改善网站访问速度的方法。
添加一个Expire或者缓存控制的头部
在这个规则中有两个要点：
对于静态的资源：通过设置超长的过期头部实行“永不过期”策略
对于动态的资源：使用一个合适的缓存控制头部来帮助浏览器处理有条件的请求。
网页设计得越来越丰富多彩，这意味着更多的脚本，样式表，图片和Flash存在于网页上。一个网页的初次访客需要发送一些 HTTP请求，通过设置过期头部你可以缓存这些资源。从而在用户访问接下来的页面时避免了不必要的HTTP请求。过期头部常用于图片，实际上应该对所有资源应用过期头部包括脚本，样式表和Flash等。
浏览器（和代理）使用一个缓存来减少ＨＴＴＰ请求的数量和尺寸，使得网页加载得更快。一个服务器在HTTP响应中使用过期头部来告诉客户端一个资源能够被缓存多久。下面是一个超长的过期头部，告诉浏览器这个资源在2010年4月15前不会过期。
Expires: Thu, 15 Apr 2010 20:00:00 GMT
如果你服务器是Apache，使用ExiresDefault设置一个过期时间。这是一个把过期时间设置到10年以后的例子。
ExpiresDefault “access plus 10 years”
记得，如果你使用一个超长的过期头部，你如果想改动资源就必须改资源的名称。在Yahoo!我们常常把这个做为发布过程中的一部分：一个版本号被做为资源名称的组成部分，例如，yahoo_2.0.6.js
使用一个超长的过期头部只在用户已经访问你的网站以后产生影响。当一个初次访问，空缓存的用户来到你的网站时它是不起作用的。
把资源Gzip
网络传输中的HTTP请求和应答时间可以通过前端机制得到显著改善。的确，终端用户的带宽、互联网提供者、与对等交换点的靠近程度等都不是网站开发者所能决定的。但是还有其他因素影响着响应时间。通过减小HTTP响应的大小可以节省HTTP响应时间。
从HTTP/1.1开始，web客户端都默认支持HTTP请求中有Accept-Encoding文件头的压缩格式：
Accept-Encoding: gzip, deflate
如果web服务器在请求的文件头中检测到上面的代码，就会以客户端列出的方式压缩响应内容。Web服务器把压缩方式通过响应文件头中的Content-Encoding来返回给浏览器。
Content-Encoding: gzip
Gzip是目前最流行也是最有效的压缩方式。这是由GNU项目开发并通过RFC 1952来标准化的。另外仅有的一个压缩格式是deflate，但是它的使用范围有限效果也稍稍逊色。
Gzip大概可以减少70%的响应规模。目前大约有90%通过浏览器传输的互联网交换支持gzip格式。如果你使用的是Apache，gzip模块配置和你的版本有关：Apache 1.3使用mod_zip，而Apache 2.x使用moflate。
浏览器和代理都会存在这样的问题：浏览器期望收到的和实际接收到的内容会存在不匹配的现象。幸好，这种特殊情况随着旧式浏览器使用量的减少在减少。Apache模块会通过自动添加适当的Vary响应文件头来避免这种状况的出现。
服务器根据文件类型来选择需要进行gzip压缩的文件，但是这过于限制了可压缩的文件。大多数web服务器会压缩HTML文档。对脚本和样式表进行压缩同样也是值得做的事情，但是很多web服务器都没有这个功能。实际上，压缩任何一个文本类型的响应，包括XML和JSON，都值得的。图像和PDF文件由于已经压缩过了所以不能再进行gzip压缩。如果试图gizp压缩这些文件的话不但会浪费CPU资源还会增加文件的大小。
Gzip压缩所有可能的文件类型是减少文件体积增加用户体验的简单方法。
把样式表放在顶端
在研究Yahoo!的性能表现时，我们发现把样式表放到文档的<head />内部似乎会加快页面的下载速度。这是因为把样式表放到<head />内会使页面有步骤的加载显示。
注重性能的前端服务器往往希望页面有秩序地加载。同时，我们也希望浏览器把已经接收到内容尽可能显示出来。这对于拥有较多内容的页面和网速较慢的用户来说特别重要。向用户返回可视化的反馈，比如进程指针，已经有了较好的研究并形成了正式文档。在我们的研究中HTML页面就是进程指针。当浏览器有序地加载文件头、导航栏、顶部的logo等对于等待页面加载的用户来说都可以作为可视化的反馈。这从整体上改善了用户体验。
把样式表放在文档底部的问题是在包括Internet Explorer在内的很多浏览器中这会中止内容的有序呈现。浏览器中止呈现是为了避免样式改变引起的页面元素重绘。用户不得不面对一个空白页面。
HTML规范清楚指出样式表要放包含在页面的<head />区域内：“和<a />不同，<link />只能出现在文档的<head />区域内，尽管它可以多次使用它”。无论是引起白屏还是出现没有样式化的内容都不值得去尝试。最好的方案就是按照HTML规范在文档<head />内加载你的样式表。