网站性能测试利器:Puppeteer

  网站性能测试从来没有像今天这么重要。测试的工具有Lighthouse,WebPagetest,PageSpeed Insights,或只是浏览器中的性能面板。在这篇文章中,我会利用Puppeteer进行网站自动化测试。

  我选了Vue Hacker News 2.0作为测试,这是HNPWA其中的一个应用。我选择这个app是因为它有良好的性能测试实践。而且很容易克隆和在本地环境运行。

  所有的例子都是在本地运行的,但如果你不想这么做的话,你还可以使用live demo,网址是简单地用我的例子http:// localhost:8080替换为。

  但是,如果你使用live demo,则无法测量自定义页面指标,因为它需要在源代码中插入console.timeStamp()。

  一开始,我们要测量网页加载速度。输出的数据应该和在浏览器控制台运行window.performance.timing相同。

  上面的代码涵盖了所有”Hello World”的需要。puppeteer.launch()在无头模式下创建新的浏览器实例,接下来的browser.newPage()可以通过创建新的标签来识别。page.goto(将一直等到事件加载发生或在30秒内发生不好的情况。

  运行node index.js之后,你将看到如下所示的原始页面加载数据:

  这个结果没有告诉你有用的信息?我也是。正如你所看到的那些点是在某个任意时间点是准时的。我们应该计算每个点的差异和navigationStart时间。并不是所有的点对我们都有用,我们可以过滤掉一些不相关的。另外,现在是重构的时候了。

  index.js包含特定的浏览器启动代码,testPage.js只关注正在运行的测试,而helpers.js具有用于解析的特定的函数和转换结果。

  另一方面,本章中的“性能指标”是基于Chrome浏览器的特定指标(如性能面板),它们不仅有计时,还包含一些其他指标,如:

  现在是时候解释一下为什么Puppeteer是比Chrome DevTools协议更高级的API。Puppeteer真的有助于普通的测试任务(如点击元素和填充输入等)。但有些功能你能用原始的Chrome DevTools 协议实现,而Puppeteer API不能。

  如果你在testPage.js中发现了奇怪的代码page.waitFor(1000),这就对了。但为什么需要延迟测量首次有意义绘图?在这个例子中首次有意义绘图小于加载事件时间,你可能会更困惑(并await page.goto(http:// localhost:8080)直到load事件。这是由于首次有意义绘图不是准时的任意时间点,这个测量是基于一些启发式的,并且是在所有页面渲染完毕后计算的。

  首次有意义绘制没有在合适的场景下准备,所以我们不能精确地检测这个标准是什么时候完成的。但是,如果度量标准已准备就绪,我们可以制定一个解决方法来检查每个时间点:

  前面的章节涵盖了可用于所有网站的指标 - 它们是通用的。现在我们将尝试衡量一些app-specific的指标。我选择一个例子来说明,分页导航按钮是由JavaScript控制。为什么这个点准时是重要的?因为这个app在客户端使用hydration markup 的SSR。

  trace.json真的是一个信息地雷,对于这个简单的app大小达到683 KB。对于典型的网站,它可以达到几MB。这个文件中的数据是相当原始的,你应该准备深入挖掘里面的信息。

  以上所有的结果不可思议的快。这是因为我使用本地主机上的高端设备运行所有测试。真实的用户的网络连接一般较弱,他们的计算能力没那么强大。我们可以使用Network.emulateNetworkConditions和Emulation.setCPUThrottlingRate轻松地模拟这种情况。而且,设置固定的网络条件有助于测试的可重复性。这一个CPU节流器只是相对延缓你的CPU(在不同的机器你会得到不同的结果)。

  我们没有测试service worker对性能的影响,因为我们的测试总是使用纯净的浏览器实例。要测量网页将如何与缓存或service worker呈现,我们必须在同一个浏览器实例中第二次运行我们的测试。之后,当我们调用browser.close()时,所有的缓存数据和service worker都将被清除,因为我们没有在puppeteer.launch()中指定任何userDataDir。

  你可以用各种原因来分析这些数据。 研究新功能对性能变化的影响,观察持续集成中的某些性能下降,简单地展示一些像我将要做的奇特的功能。

  对于每个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提高编程的网站速度,可以提高网络带宽,但不能极大地提高速度。

  受影响最严重的service worker的结果是减少6倍的CPU性能。这个图用loadEventEnd和上一个进行比较:

  Service worker看起来没有像传统的缓存优化的性能那么高 - 但仍然是一项新技术。

  不管你想要研究什么,我希望我已经帮助了你如何用Puppeteer获得结果。这个工具很容易安装。

相关阅读