微信号:grzlwx

介绍:光荣之路官方资讯

右击 -> 查看源文件看什么?前端性能测试技巧(吱)

2015-06-27 23:05 光荣之路


最近读了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%的人说过不允许 在公司的机器和网络上使用免费、开源、共享、甚至是有时间限制的免费试用版软件。)

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

      o JMeter (http://jakarta.apache.org/jmeter/)

      o WebLoad (http://www.webload.org/)

      o OpenSTA (http://www.opensta.org/)

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

      o Ethereal (http://www.ethereal.com/)

      o Fiddler (http://www.fiddlertool.com/)

  •   免费的浏览器插件

      o Firebug (http://www.getfirebug.com/) with YSlow (http://developer.yahoo.com/yslow/) for Firefox

      o HttpWatch (http://www.httpwatch.com) for IE

  •   免费的助手网站

      o Web Page Analyzer - from Website Optimization: Free Website Performance Tool and Web Page Speed Analysis (http://www.websiteoptimization.com/services/analyze/)

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

(作者:R. Scott Barber 原文:Right Click -> View Source And other tips for performance testing the front end

译者:薛定谔的破猫 译文来源:http://www.cnblogs.com/twocats/archive/2012/02/29/2372853.html)


光荣之路软件测试培训

官网:http://www.gloryroad.cn/

微信公众号:gloryroadtrain

性能测试QQ群:415987441
软件测试招聘QQ群: 203715128
自动化3群QQ: 371211499




 
光荣之路 更多文章 今天晚上的 linux 公开课- Awk 编程 7月28日(今天)晚上的 linux 公开课- shell编程 8月4日(今天)晚上的 linux 公开课- shell编程 9月1日(本周一)晚8点半,光荣之路Web自动化系列基础课—javascript第二讲 推荐本好书《与机器赛跑》
猜您喜欢 独家解析“人机大战”胜负背后的意义 监控与计量|Ceilmetor等OpenStack组件的裂变与兴起 全民K歌后台编译优化:从40分钟到30秒 Apple Watch首个软件升级发布 优化健康功能 MySQL批量SQL插入性能优化