qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

右击 -> 查看源文件,和其他一些前端性能测试技巧

最近读了Steve Souders的High Performance Web Sites: Essential Knowledge for Frontend Engineers(O’Reilly, 2007),这本书的副标题是 “14 Steps to Faster-Loading Web Sites”。在你发现此书面向对象为开发人员,从而停止阅读之前,考虑以下几点:

  ● 作者的研究表明,网页响应时间约80%-90%是由前端设计决定的。而我的经验中,这个数字更应该是50%-80%,但我的经验多来自于那些被重新设计为WEB架构的多用户应用,或者是那些有着严重后端性能问题的应用(请我来定位问题)。

  ● 和性能测试人员有关的几乎所有的工具、培训、文章和会议,都集中在系统的后端。以至于大部分人认为,系统的前端性能无需担心,因为我们无法控制客户端的系统。

  ● 根据我的经验,网站的前端设计和开发,几乎不会考虑到性能问题,除了尽量减小图片的大小。我也从未让团队做过客户端页面的HTML代码审查,从未在这些代码上做过单元测试,也从未见过测试人员有意的对HTML进行一些性能测试。

   结合上面几点,你将得知,没有人关注页面上的可能存在的性能优化,而这种优化很可能是最容易实现,效果却又最明显的。读了这本书我发现,我经常对大多数 的前端性能问题进行测试,但自己却没有意识到。作者提到的一些内容,我可能永远也不会想到去测试,不对这些内容进行更主动的测试是个错误,这些测试的成本 是非常低的,无论是在时间上,还是在所需的工具和资源上。实际上,在测试网站的时候,我经常拿出整个性能测试的前15分钟来完成大部分的前端测试,虽然我 承认,15分钟只够测试几个页面。

  通过这篇文章,我讲解了如何通过手工、负载生成工具、网络协议分析工具、助手网站以及浏览器插件,来进行测试。我已经通过以下免费工具(不是免费试用版,是无任何限制的免费版)完成了这些工作。 如果你的公司不允许使用免费软件,我相信只要简单的搜索一下,就可以找到一堆可以替代的工具,这些工具将花费你公司足够多的钱,从而让他们重视。(如果你 认为这只是个笑话,很可惜它不是。在咨询过我的团队和接受我培训的个人中,有超过50%的人说过不允许在公司的机器和网络上使用免费、开源、共享、甚至是 有时间限制的免费试用版软件。)

  ● 免费或者开源的负载生成工具

    ○ JMeter (http://jakarta.apache.org/jmeter/)
    ○ WebLoad (http://www.webload.org/)
    ○ OpenSTA (http://www.opensta.org/)

  ● 免费或者开源的网络协议分析工具

    ○ Ethereal (http://www.ethereal.com/)
    ○ Fiddler (http://www.fiddlertool.com/)

  ● 免费的浏览器插件

    ○ Firebug (http://www.getfirebug.com/) with YSlow (http://developer.yahoo.com/yslow/) for    Firefox
    ○ HttpWatch (http://www.httpwatch.com) for IE

  ● 免费的助手网站

     ○ Web Page Analyzer - from Website Optimization: Free Website Performance Tool and Web   Page Speed Analysis (http://www.websiteoptimization.com/services/analyze/)
    ○ Gomez Instant Site Test (http://www.gomez.com/info_center/instant_test.php)

  有了这些,让我们来看一些你只需看完本文能做的测试,这些测试只需在web层面上即可进行,却可能会显著的改善终端用户的响应时间。

  HTTP请求数

   页面的获取不是在一个事务中完成的。通常HTML文件需要一个请求,样式表需要一个或多个请求,外部脚本需要一个或多个请求,图片、多媒体内容、以及第 三方那个内容如广告等需要多个请求。即使很多对象已经存在于浏览器缓存中了,还是需要频繁的向服务器发送请求,以确认缓存中的对象是否“fresh”。这 意味着页面上的每一个对象都十分可能会增加负担,进而在用户视角上降低了了性能,即使客户端的浏览器已经缓存了所需的对象。如下几种途径,可以确定页面发 送了多少个请求,以及请求的内容。

  无论你用哪种方法,你将首先清除掉浏览器的缓存,或者访问页面两次(一次通过ctrl + F5来强制刷新缓存)以确保能够看到所有的请求。因为这些方法只能收集到真实的请求,如果不清除或刷新缓存可能会导致一些遗漏,让你以为没有去请求一些样 式表、脚本、图片和多媒体内容,很多配置或条件会对此产生影响,而你可能不知道要去设置这些。

  1、如果你使用了负载生成工具或者网络协 议分析工具,你可以直接开始录制了,然后浏览感兴趣的页面。在你录制的内容中寻找“GET”语句,看一下请求了什么。记住,有些工具,录制下来的脚本默认 只显示基础的HTML请求,不包括子请求(对样式表、图片、脚本等的请求),如果要看到所有的请求需要进一步的设置。

  2、如果你的测试环境允许装浏览器插件,那么有好几种方法可以使这个工作变得简单。根据你所用的浏览器,或者希望测的浏览器,我推荐:

  a)FireFox:FireBug+YSlow

  b)IE: HttpWatch

3、如果你无法使用任何工具,你仍将有几种选择:

  a)访问上面列出的一个助手网站,输入你想测试的页面的URL,点提交。

  b)FireFox中,右击页面,选Page Info,导航至Media Tab。注意,这个方法不会显示脚本和样式表,但会显示出请求的图片和其他多媒体内容。

  c)IE中,右击页面然后选择View Source。这里,你需要搜寻“link”和“img”字段。如果你找到了样式表的连接(到.css文件的连接),你还需要手动的下载每个样式表,然后 在其中搜索“url”字样,因为这些可能会用来请求脚本、图片和多媒体内容。(这是目前为止最笨的方法,但仍能为你提供信息)

  有了你的请求列表以后,第一件事要做的就是看看数量——过多的请求会让页面变慢。有如下几个指标来判断是否是过多的请求。

  1、外部样式表请求多于一个。确实有一些时候是应该将页面样式拆分成几个样式表,但这情况并不常见,而且对性能显然没有好处。一般来说,只有当有一个主样式表应用到很多页面,第二个大的样式表只应用到几个页面时,保留多于一个样式表才是个好方法。

  2、同一域中脚本的请求多于一个。虽然连接多个外部脚本比连接多个样式表有更好的理由,多个外部脚本连接比 一个连接性能更好,仍然是不常见的。如果你测试的页面是一个复杂的数据输入表单,那么将表单的验证脚本同其他页面的通用脚本分离可能会有些意义。这样做会 减少其他页面(除了表单)的大小,从而改善那些页面的性能,但多出的请求还是会轻微的降低表单页面的性能。不管如何,多于一个外部脚本,至少是值得注意一 下的。

  3、大量的图片。我没法说“大量的”是多少,但我可以告诉你,IE7和FireFox 2.x默认每主机名可以有2个并行下载(HTTP/1.1,大部分新网站都是)。这意味着,不管你的图片大小是多少,浏览器一次只能下载两个,只有当之前 的两个都处理完,才会开始接下来的两个。在HTTP/1.0中是不同的,FireFox默认每主机名可以有8并行下载,IE各版本不同,但肯定不会低于 2。这种变化产生的效果就是,使用类似大小但是数量最少的图片易于产生最佳的性能。这和小图片总是好的那种观点是相反的。将几个小图片合成一个或两个大些 的图片,通常会改善性能。当然,这就又会出现一个临界点。图片大小和图片的数量是值得前端工程师仔细研究的,测试多种选择以达到最佳性能。有一个广受好评 的“rull-of-thumb”(提供类似问题的指导),奉劝当一个页面超过12个请求时,一定要谨慎。Souders的这本书和Andrew B. King的in Speed Up Your Site: Web Site Optimization(New Riders, 2003)中都采用了这个数字,而Aaron Hopkins在网站上发表的文章“Optimizing Page Load Time”让这个数字更有说服力。

  HTTP请求的顺序

  很多类似的方法都可以用来确定页面上请求的顺序(前面提到的助手网站和FireFox的“Page Info”除外,为了突出数量和大小等问题,将请求按类型或者大小进行了分组和排序)。我们所关注的顺序是:

  1、首先请求样式表。在样式表下载完之前,页面是不会显示的。或者是下载完样式表要重新刷新页面。基于这一点,让样式表在HTML页面之后第一批请求是非常重要的。

  2、最后请求脚本(至少是要靠后)。当开始请求一个脚本的时候,在脚本完全下载完之前不会再发出对其他对象 的请求。此外,脚本下载过程中,浏览器将暂停显示页面内容。这意味着在脚本下载过程中完成的任何对象的下载,都不会被显示出来,从而给人感觉页面的展现停 止了。所以一定要把脚本的请求放到用户最感兴趣的对象之后。记住,大多数用户眼中的响应速度是由他们感兴趣的内容决定的,而不是整个页面的载入时间。

  不管你是看HTML源文件还是录制请求,你需要关注的就是样式表最先被请求,脚本在最后或者至少是非常靠后时请求。有一个常见的争论,说负责与 用户交互的脚本(如图像映射、对象反转)应该早些被请求,这样用户会有更好的体验,即便整个页面还正在下载过程中。但我的经验里,由于下载而产生的页面停 止比无法获得图像映射、对象反转功能更容易使用户变得焦躁甚至是离开页面。

  重定向和隐藏错误

  你仍然可以使用相同的方法来检查重定向问题(3xx状态码),客户错误(4xx),和服务器错误(5xx)。这里,你关注的信息是:

  1、过多的3xx。3xx状态表示,请求被处理了,但是浏览器需要到另一个地址去获取所需对象,这就产生了 附加的请求和响应。虽然有很多的原因可以使用重定向,检查一下是否有意使用和存在好理由还是值得做的。比如,将一个删除掉的页面重定向到新地址,或者将明 显拼错的页面重定向到正确的地址,这就是个好的使用理由。图片的父级目录被移动了,没有人去维护更新链接,这就不是一个需要使用重定向、从而接受一些性能 下降的好理由。

  2、任何4xx。用户的请求有问题时就会返回4xx状态码。最常见的是404,表示服务器上找不到被请求的对象。一般说来,如果页面的显示和功能都正常,但请求却返回了4xx,那就说明页面请求了不需要的对象,也耗费了多余的时间。

  3、任何5xx。5xx表示处理请求时,服务器上发生了错误。任何5xx的状态都需要开发团队注意。

  我将这些都称作隐藏错误,是因为当它们发生在非主HTML上时,用户通常是察觉不到的。有时,这些状态码预示着有更深层的错误,但是无论如何,它们都导致了与页面内容无关的请求,这些请求通常也都是完全没有必要的。

HTTP响应头

  要检查HTTP响应头,需要使用负载生成工具、网络分析工具或者是浏览器插件。如果你没有这些工具,一个助手网站可以帮到你。我推荐Peter Forret的网站“View and analyze HTTP headers” (http://web.forret.com/tools/analyze.aspx),你只需输入页面的URL,网站就会获取到web服务器返回的一 系列HTTP头,这样就可以检查页面过期和缓存等配置了。至于具体哪些是合适的、哪些是不不要的性能损失,这是和很多内容息息相关的,如网页和对象变化的 频率、用户访问网站的频率、还有用户看到过时内容的相对风险。但是不管怎样,下面的这些是永远值得检查的:

  1、过期时间是否恰当。如果一个对象的HTTP响应中没有过期时间这行,每次用户请求包含这个对象的页面 时,都会向服务器发送一个请求,来判断缓存的这个版本是否“新鲜”。如果你有一些不易过期的对象(如公司的Logo),你可以通过设置一个未来很远的日期 来避免这种有效性检查。过期时间最多应用在图片上,但在脚本、样式表、AJAX和FLASH等内容上也经常是适用的。检查一下没有过期时间的对象吧,看看 是不是有不合适的。

  2、ETags是否恰当。ETags是一种web服务器和浏览器使用的认证手段,用来判断客户机器上缓存的 对象是否和服务器上的匹配。使用ETags的问题在于,它们对于一个特定的服务器通常是唯一的,这意味着如果网站有多个web服务器,ETags是会出现 问题的。如果你确定只有一个web服务器,那么使用ETags是个不错的主意。如果是多个服务器,你就必须查明是否考虑到了这点,或者干脆建议不使用 ETags。

  3、其他缓存控制。你可能会看到类似的内容,Cache-Control、Last-Modified、Pragma、Set-Cookie、Age。如果你看到了,那么确保这些配置是有意义的。如果没有找到,而你又觉得应该有这些东西,那么找人看一下吧。

  说到底,其实本质内容就是你要检查HTTP响应头,来判断网站是否已被合理配置来利用浏览器的缓存。通常,判断这些配置是否恰当的唯一方法,是同管理员和架构师探讨网站是如何使用的、以及是如何设计的,尤其是和浏览器缓存有关的地方。

  源文件和其他对象

  最后,如果你没以前没做过这些,你需要手工检查HTML源文件、css、脚本、图片以及其他对象。到现在,我还没发现任何一款能够节省我们的时 间、对各种情况做出充分检查、并对前端性能提出建议的工具,虽然一些网站使用的HTML、脚本、图片的编辑器还是有一些帮助的。最后,关于前端性能测试, 我的建议是:

  1、确保脚本和CSS没有写在HTML源文件中。将脚本和CSS直接写在HTML中来提高性能,几乎是不可 能的。原因很简单:网页的主HTML是更新最为频繁的部分之一,因此从缓存中受益最少。既然HTML很可能每次都要下载,只有尽量减小大小才是上策。将脚 本和CSS与HTML分离,以便利用缓存,是肯定会提高性能的。

  2、确保样式和脚本不重复。样式和脚本包含重复内容是非常恶心的。有时,不同的文件中有重复内容,有时在同一个文件中就会重复。你可能不想花费时间去做一个全面检查,那么只需快速的扫描一遍源文件,经常就能发现是否存在明显的重复。

  3、检查代码最小化。最小化,指压缩和优化代码,让相关功能使用最少的代码行数。当检查HTML源文件、外部脚本和样式表时,需要注意过多的注释、空格、换行、变量名长度、以及其他能够增加文件大小的内容。

  4、检查图片的大小和压缩。虽然大家都明白,仍然还有很多网页设计者使用这样一些图片格式,要么有不必要的 文件大小、要么是同显示尺寸不同的尺寸、要么就是超过了所需要的品质。通常,GIF格式的图片是被压缩成64位甚至更少颜色的,它们完全满足大部分的图片 和缩略图;JPG格式的图片被压缩成256位或者更少,对于照片来说也完全够用;通过HTML的height/width属性来缩放图片,不如创建再一个 新的大小的图片。

  这些内容,靠常识判断即可。例如,一些网站将所有的文件、目录以及变量的名字减少到两个甚至更少的字符,将这作为一种减小文件大小的策略。从纯 粹的性能角度来看,这是好的;但是,对大多数网站来说,维持这些东西所产生的工作量完全抹杀了它的价值。你需要同团队一起,在去重、最小化、压缩和实用性 之间找到一个平衡点。

  总结

  本文介绍了几种测试,可以用来判断网站是否可能会出现前端性能问题。检查这些可能的性能优化,可能会让用户感受到的响应时间提升50%甚至更 多。我确信,一旦你有了自己的工具箱、插件和助手网站,并且实际的练过几次之后,你只需花费比读这篇文章更少的时间,就能检查一个网站是否有这些问题了。 有了这么大性能优化的可能性,又在时间和工具上投入这么少,我实在是找不到任何不进行这些测似的理由。

posted on 2012-05-30 10:42 顺其自然EVO 阅读(151) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2012年5月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜