(右击查看源文件和其他一些前端性能测试技巧.docxVIP

右击 - 查看源文件，和其他一些前端性能测试技巧本文为原创翻译原文为Right Click - View Source And other tips for performance testing the front endBy?R. Scott Barber右击 - 查看源文件，和其他一些前端性能测试技巧　最近读了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 (/jmeter/)?　o ? WebLoad (/)　o ? OpenSTA (/)?　免费或者开源的网络协议分析工具　o Ethereal (/)?　o Fiddler (/)　免费的浏览器插件　o Firebug (/) with YSlow?(/yslow/) for 　Firefox?　o HttpWatch () for IE　免费的助手网站　o Web Page Analyzer - from Website Optimization: Free Website Performance Tool?and Web 　Page Speed Analysis?(/services/analyze/)?　o Gomez Instant Site Test (/info_center/instant_test.php)　有了这些，让我们来看一些你只需看完本文能做的测试，这些测试只需在web层面上即可进行，却可能会显著的改善终端用户的响应时间。HTTP请求数　页面的获取不是在一个事务中完成的。通常HTML文件需要一个请求，样式表需要一个或多个请求，外部脚本需要一个或多个请求，图片、多媒体内容、以及第三方那个内容如广告等需要多个请求。即使很多对象已经存在于浏览器缓存中了，还是需要频繁的向服务器发送请求，以确认缓存中的对象是否“fresh”。这意味着页面上的每一个对象都十分可能会增加负担，进而在用户视角上降低了了性能，即使客户端的浏览器已经缓存了所需的对象。如下几种途径，可以确定页面发送了多少个请求，以及请求的内容。　无论你用哪种方法，你将首先清除掉浏览器的缓存，或者访问页面两次（一次通过ctrl + F5来强制刷新缓存）以确保能够看到所有的请求。因为这些方法只能收集到真实的请求，如果不清除或刷新缓存可能会导致一些遗漏，让你以为没有去请求一些样式表、脚本、图片和多媒体内容，很多配置或条件会对此产生影响，而你可能不知道要去设置这些。如果你使用了负载生成工具或者网络协议分析工具，你可以直