借助外部各种优秀的免费工具和网站，可以快速了解当前网站的性能好坏，可使用的性能测试工具非常多。

3.1.1 使用YSlow进行性能分析

看过Steve Souders所著的《高性能网站建设指南》这本经典性能优化书籍的人，应该都非常熟悉YSlow性能检测插件，它以Firefox插件的形式，几乎成为了所有前端开发人员的标配工具。YSlow遵守基于所有基础的性能最佳实践的规则，快速分析HTML文档代码组成，Steve Souders在《高性能网站建设指南》一书中总结了12条基本规则：

● 尽量减少HTTP请求。

● 使用CDN。

● 静态资源使用Cache。

● 启用Gzip压缩。

● JavaScript脚本尽量放在页面底部。

● CSS样式表放在顶部。

● 避免CSS表达式。

● 减少内联JavaScript和CSS的使用，尽可能使用外部的JavaScript和CSS文件。

● 减少DNS查询。

● 精简JavaScript。

● 避免重定向。

● 删除重复的脚本。

这些规则能够帮助开发者快速地发现页面性能问题。一个页面如果遵守了以上规则进行前端开发，那么抛开网络因素，至少可以保证它在页面加载阶段的性能不会产生问题。

但我们回过头回顾一下这些实践规则，基本上它将焦点都放在了页面的加载阶段，而在加载完成后的浏览器的解析、渲染阶段是空白的。

对于一个常规的相对简单的页面来说，以上规则的检查足够了，但是一旦遇到包含大量JavaScript 文件及复杂布局的页面时，很难通过 YSlow 来分析浏览器在页面解析、渲染各个阶段的时间，从而导致优化无从入手。所以接下来，我们看一下Google开源的优化工具PageSpeed。

3.1.2 使用PageSpeed进行性能分析

和上面提到的YSlow一样，Google提供的优化工具PageSpeed除了有网站的入口，也能够以插件形式在Firefox和Chrome浏览器上运行。它的工作原理类似于YSlow，也是基于一些基础的性能最佳实践规则来分析代码，然后提供一系列能够提高页面性能的优化方案建议。

PageSpeed 也有它的独到之处。它除了能够提供页面在请求加载层面的优化建议，还能提供页面在加载完成后的一系列解析渲染操作的各部分时间，比如：

● 页面包含的JavaScript代码的执行时间。

● 合理高效的CSS样式代码的建议。

● 页面布局渲染的时间等。

使用Chrome的控制台开发工具中的TimeLine可以看到类似图3-1的效果。

图中①代表ParseHTML,②代表Scripting,③代表RecalculateStyle和Layout过程，④代表Paint过程。

有了这些数据，我们就可以知道特定页面在浏览器解析渲染时，在哪里消耗了较多时间，然后对其进行优化。

然而，在现实世界里，用户在浏览页面时的性能体验，并不一定如我们所预期的那样（在本地开发完成并通过性能检查工具检查确认为具有良好性能表现的页面，并不代表用户在真实网络中访问会具有相同的表现）。

假设我们在本地开发页面，并利用上面提到的性能检查工具辅助我们写出具有良好性能实践的页面，然后发布更新交付给用户。但在真实的网络世界里，不同地域的用户、不一样的网络接入提供商、相差很多的网络速度等因素，都直接影响页面的加载速度。

特别是对于做跨境服务的电子商务网站来说，在本地开发出一个具有良好性能的页面是远远不够的。我们需要知道不同地域的用户访问网站的真实性能情况，比如美国和巴西的用户在访问同一个页面时的性能差别，我们购买的CDN服务在不同地域是否都起到正向的网络加速作用等。

当某个地区的用户向产品负责人反馈，他们打开网站很慢，而你只能无奈地在本地又重新打开YSlow或者PageSpeed扫描页面，然后得出结论：“我们这里打开还好，非常快。”

所以我们需要有一种工具，能够帮我们漂洋过海，去了解某个特定地区用户访问网站的真实性能情况。接下来看一下WebPagetest，看看它能帮助我们做哪些事情。

3.1.3 使用WebPagetest进行性能分析

和YSlow、PageSpeed一样，WebPagetest同样也使用和它们相似的一组最佳性能实践来分析网页。

WebPagetest通过浏览器访问，基于输入的Website URL，以及选择的国家城市、浏览器类型、网络带宽等信息，启动对应的远程服务器上的浏览器进行性能分析测试。

正如前面提到的，我们希望有一种工具，能够帮我们漂洋过海，去了解某个特定地区用户访问网站的真实性能情况。WebPagetest就能够提供遍布世界各个角落的代表性城市的页面性能分析测试，基本覆盖亚洲、大洋洲、非洲、欧洲、北美和南美洲。

据官网介绍，他们提供的不同城市的性能分析测试，是通过真实的部署在对应城市的物理服务器来实现的，而不是通过其他类似代理或者虚拟机等方式模拟实现的。

除了常规的性能分析及优化建议，WebPagetest还提供了页面加载过程的视频录制、关键节点截图、页面加载瀑布图等诸多重要信息。

如图3-2所示，在性能报表的概括里，有几个重要的性能指标：

● First Byte 表示首字节响应时间，该时间可以综合反映出当前连接的网络状况和服务器的响应处理速度。

● Start Render表示浏览器开始渲染的时间。

● Speed Index表示一种在WebPagetest中自定义的性能指标。

● Load Time表示加载时间。

其中Start Render、Speed Index、Load Time分别代表了前面提到的几个重要的影响用户性能体验的性能指标：

● 白屏。

● 首屏。

● 页面整体加载。

使用WebPagetest测试页面时，通过对比页面在不同国家的城市中这几个指标的差别，可以大概知道这些国家的用户访问页面的真实体验是怎样的，用户等待空白页面花了多少时间，整个首屏显示完成又花了多少时间，最终用户等待了多少时间才可以正常浏览和使用页面功能。

通过上面的介绍，从 WebPagetest 提供的这些功能来看，它的确是非常优秀的性能分析工具，但它的缺点也显而易见。

● WebPagetest很难对登录态依赖Cookie的网页进行测试，基本上无法为测试页面设置正确的Cookie。

● WebPagetest 上的性能测试服务是由人工触发的。每一次测试服务，都是在特定地区的特定机器上启动特定浏览器进行性能分析的，它的分析结果至多只能作为排查某个国家用户访问性能问题时的一个性能报告参考，并不能真正代表访问网站的真实用户的性能体验。

通过上面的介绍，我们发现 WebPagetest 虽然能提供强大的性能分析服务，但作为免费的测试服务，提供的测试样本数量有限，测试结果也不能真正关联真实用户。

而且如果网站已经过了初创时期，正处在稳步上升的阶段，用户的访问量逐步上升，达到了百万、千万级别，更不可能将网站日常的性能分析和监控，寄望于每日通过 WebPagetest 手动测试得到的样本数量在个位数的性能报告。

所以，如果希望网站能够持续为用户提供最佳的性能体验，就需要建立网站自身的性能监控系统。

下一节笔者会给大家介绍一个基础的真实用户性能监控系统的设计，具有日常页面性能监控、预警等功能，并且能够在网站性能发生问题时提供足够的基础性能分析数据。