网站性能测试从来没有像今天这么重要。测试的工具有Lighthouse,WebPagetest,PageSpeed Insights,或只是浏览器中的性能面板。在这篇文章中，我会利用Puppeteer进行网站自动化测试。
1、被测试的应用程序
2、Navigation Timing API
3、Chrome DevTools 性能时间轴面板-首次有意义绘图
4、自定义页面指标
5、从网络跟踪中提取数据
6、模拟低速网络并节制 CPU
7、控制浏览器缓存和 service worker 的重复访问
8、结果
我选了Vue Hacker News 2.0作为测试，这是HNPWA其中的一个应用。我选择这个app是因为它有良好的性能测试实践。而且很容易克隆和在本地环境运行。
所有的例子都是在本地运行的，但如果你不想这么做的话，你还可以使用live demo，网址是https://vue-hn.now.sh.简单地用我的例子http：// localhost：8080替换为https://vue-hn.now.sh。
但是，如果你使用live demo，则无法测量自定义页面指标，因为它需要在源代码中插入console.timeStamp()。
一开始，我们要测量网页加载速度。输出的数据应该和在浏览器控制台运行window.performance.timing 相同。
上面的代码涵盖了所有”Hello World”的需要。puppeteer.launch()在无头模式下创建新的浏览器实例，接下来的browser.newPage()可以通过创建新的标签来识别。page.goto('http://localhost:8080')将一直等到事件加载发生或在30秒内发生不好的情况。
整个测试归结为page.evaluate（）在page上下文中发送window.performance.timing，并使用JSON.parse（）解码结果。
经过所有的页面测试，browser.close（）就能简单地关闭浏览器，它也会删除所有的cache/service workers，因为我们没有传递userDataDir参数给puppeteer.launch（）。
运行node index.js之后，你将看到如下所示的原始页面加载数据：
这个结果没有告诉你有用的信息？我也是。正如你所看到的那些点是在某个任意时间点是准时的。我们应该计算每个点的差异和navigationStart时间。并不是所有的点对我们都有用，我们可以过滤掉一些不相关的。另外，现在是重构的时候了。
index.js包含特定的浏览器启动代码，testPage.js只关注正在运行的测试，而helpers.js具有用于解析的特定的函数和转换结果。
现在结果被很好地解析并以毫秒表示：
本章将使用Chrome性能指标(Chrome Performance Metrics)。但是，在上一章中我们不是已经测试性能计时了吗？是的，你可能会感到困惑。window.performance.timing是由W3C维护的浏览器不可知测量标准(agnostic measure standard)，所有的浏览器都应该有相同的API。
另一方面，本章中的“性能指标”是基于Chrome浏览器的特定指标（如性能面板），它们不仅有计时，还包含一些其他指标，如：
现在是时候解释一下为什么Puppeteer是比Chrome DevTools协议更高级的API。Puppeteer真的有助于普通的测试任务（如点击元素和填充输入等）。但有些功能你能用原始的Chrome DevTools 协议实现，而Puppeteer API不能。
目前，在0.13版本中，只有通过page._client.send（）才能获得原始协议的方法。在不久的将来会改变的。我们将通过page._client.send（'Performance.getMetrics'）来发送，使用来自原始的DevTools协议的方法getMetrics。
这个代码与前一章的代码类似，但是请记住window.performance.timing在网页上下文中执行，Performance.getMetrics在浏览器级别上执行（特别是Chrome）。这就是为什么两个指标的navigationStart时间都不相同。
如果你在testPage.js中发现了奇怪的代码page.waitFor（1000），这就对了。但为什么需要延迟测量首次有意义绘图？在这个例子中首次有意义绘图小于加载事件时间，你可能会更困惑（并await page.goto（'http：// localhost：8080'）直到load事件。这是由于首次有意义绘图不是准时的任意时间点，这个测量是基于一些启发式的，并且是在所有页面渲染完毕后计算的。
首次有意义绘制没有在合适的场景下准备，所以我们不能精确地检测这个标准是什么时候完成的。但是，如果度量标准已准备就绪，我们可以制定一个解决方法来检查每个时间点：
现在，当代码没有竞争时（the code is free of race conditions），可以显示示例结果：
前面的章节涵盖了可用于所有网站的指标 - 它们是通用的。现在我们将尝试衡量一些app-specific的指标。我选择一个例子来说明，分页导航按钮"<prev""more>" 是由JavaScript控制。为什么这个点准时是重要的？因为这个app在客户端使用hydration markup 的SSR。
这种方法导致“不可思议的谷”，FirstMeaningfulPaint可以被认定是“不可思议的谷”的开始，并且我们的自定义标准listLinksSpa将代表“不可思议的谷”结束的时间。
我们必须判断在哪里写入console.timeStamp（'listLinksSpa'）。我推断，mounted（）方法放在ItemList.vue是一个好的做法：
现在我们必须在page.goto（）之前注册监听器page.on（'metrics'，callback）。当我们的应用程序调用page.on（'metrics'，callback）中的console.timeStamp（'listLinksSpa'）回调函数时，我们可以提取这个度量的时间。
上面的代码应该没问题。但是代码质量与此await page.waitFor（1000）是远远不能接受的 - 竞争条件的脆弱性在这里太明显了(the vulnerability to race condition is too obvious here)。我举上面的例子只是为了引出一个简单的例子。下面的代码通过在一个promise中包含page.on（’metrics’，callback）来解决这个问题，并使用了async/await的特性 。
现在结果应该是这样的：
在Chrome面板中运行性能测试时，可以将数据保存为JSON文件。在Puppeteer中也是一样。只要在page.goto（）之前用page.tracing.start（{path：'./trace.json'}）开始记录跟踪，并且当你认为你需要的所有东西都被记录时，用page.tracing.stop（）停止记录。
在下面的代码中，我只展示提取CSS文件的开始和结束网络请求时间。
trace.json真的是一个信息地雷，对于这个简单的app大小达到683 KB。对于典型的网站，它可以达到几MB。这个文件中的数据是相当原始的，你应该准备深入挖掘里面的信息。
在代码中，getTimeFromPerformanceMetrics（）在ResourceSendRequest跟踪类型中搜索请求的文件。当它发现它会得到它的开始时间和resourceId。resourceId用于在资源结束时查找记录。
CSS文件的跟踪数据如下所示。请记住，这只是数据中一千条记录中的一条。
以上所有的结果不可思议的快。这是因为我使用本地主机上的高端设备运行所有测试。真实的用户的网络连接一般较弱，他们的计算能力没那么强大。我们可以使用Network.emulateNetworkConditions和Emulation.setCPUThrottlingRate轻松地模拟这种情况。而且，设置固定的网络条件有助于测试的可重复性。这一个CPU节流器只是相对延缓你的CPU（在不同的机器你会得到不同的结果）。
现在你可以看到以前章节的汇总结果更加符合实际情况。
我们没有测试service worker对性能的影响，因为我们的测试总是使用纯净的浏览器实例。要测量网页将如何与缓存或service worker呈现，我们必须在同一个浏览器实例中第二次运行我们的测试。之后，当我们调用browser.close（）时，所有的缓存数据和service worker都将被清除，因为我们没有在puppeteer.launch（）中指定任何userDataDir。
如果我们想测试重复访问只有缓存没有service worker，我们必须停止service worker在前一个入口注册通过ServiceWorker.stopAllWorkers之间的第一个结束第二个输入。 如果我们只想单独测试service worker，Network.clearBrowserCache也是如此。
注意从其余的例子page._client.send（'ServiceWorker.enable'）。 Chrome DevTools协议需要启用特定域名，但其中一些域名是由Puppeteer启用的。 ServiceWorker域名不在Puppeteer中使用，所以我们必须手工启动它。
你可以用各种原因来分析这些数据。 研究新功能对性能变化的影响，观察持续集成中的某些性能下降，简单地展示一些像我将要做的奇特的功能。
对于每个plot我运行测试100次，600页的入口，大约需要10 - 20分钟,每个测试套件。
对于普通用户来说，最重要的指标是FirstMeaningfulPaint和listLinksSpa。这些指标反映了他的网站速度。domInteractive与网站对用户交互的时间没有任何关系，这个度量在本例中由一个自定义listLinksSpa表示。
responseEnd是显示网络带宽和延迟对页面的影响的一个很好的指标。 第二次只进入高速缓存，通常状态为304，并且其服务速度不会超过双倍延迟时间-这就是为什么来自高速缓存的responseEnd发生在60-70毫秒左右的原因。另一方面，responseEnd,service worker省略了网络层，并且不受延迟的影响。 service worker 提供服务时，只有设备处理能力（CPU）会影响此度量标准。
只有service worker（sw）和有缓存的service worker之间没有统计上的显着差异，这是因为app中的所有网络请求都被service worker覆盖。例如，如果有一些不是由service worker处理的图片，而只是通过传统的缓存，我们将看到service worker和缓存相结合的好处。
配置service worker 需要一些工作，但是如果仅仅关注良好的网络和好设备的结果，益处并不是那么明显。 如果网络速度下降，一切都会改变。
由service worker处理的度量标准的时间与上图中的相同。 由于双重延迟，仅从缓存中提供的请求浪费了大量时间。 这就是为什么大延迟是移动网络中最有问题的因素，而不是小带宽。
总体来看，这一点很明显，这就是为什么service worker会应用到移动设备。 你可以使用service worker提高编程的网站速度，可以提高网络带宽，但不能极大地提高速度。
慢3G网，差设备
受影响最严重的service worker的结果是减少6倍的CPU性能。这个图用loadEventEnd和上一个进行比较：
首次进入速度降低1.4倍
只有缓存的速度要慢2.6倍
service worker慢5.8倍
Service worker看起来没有像传统的缓存优化的性能那么高 - 但仍然是一项新技术。
不管你想要研究什么，我希望我已经帮助了你如何用Puppeteer获得结果。这个工具很容易安装。
只要输入npm install puppeteer