网站性能测试利器:Puppeteer

译者:CK星空,本文由 DevOps 时代高翻院翻译整理发布

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

1、被测试的应用程序

2、Navigation Timing API

3、Chrome DevTools 性能时间轴面板-首次有意义绘图

4、自定义页面指标

5、从网络跟踪中提取数据

6、模拟低速网络并节制 CPU

7、控制浏览器缓存和 service worker 的重复访问

8、结果

1、被测试的应用程序

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

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

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

2、Navigation Timing API

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

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

整个测试归结为在page上下文中发送,并使用解码结果。

经过所有的页面测试,就能简单地关闭浏览器,它也会删除所有的cache/service workers,因为我们没有传递参数给。

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

{ navigationStart: 1513433544980, unloadEventStart: 0, unloadEventEnd: 0, redirectStart: 1513433544980, redirectEnd: 1513433545292, fetchStart: 1513433545292, domainLookupStart: 1513433545292, domainLookupEnd: 1513433545292, connectStart: 1513433545292, connectEnd: 1513433545292, secureConnectionStart: 0, requestStart: 1513433545019, responseStart: 1513433545289, responseEnd: 1513433545292, domLoading: 1513433545296, domInteractive: 1513433545339, domContentLoadedEventStart: 1513433545540, domContentLoadedEventEnd: 1513433545540, domComplete: 1513433545602, loadEventStart: 1513433545602, loadEventEnd: 1513433545602,}

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

const puppeteer = require('puppeteer');const testPage = require('./testPage');(async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); console.log(await testPage(page)); await browser.close();})();

const extractDataFromPerformanceTiming = (timing, ...dataNames) => { const navigationStart = timing.navigationStart; const extractedData = {}; dataNames.forEach(name => { extractedData[name] = timing[name] - navigationStart; }); return extractedData;};module.exports = { extractDataFromPerformanceTiming,};

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

现在结果被很好地解析并以毫秒表示:

{ // all results are in [ms] responseEnd: 23, domInteractive: 44, domContentLoadedEventEnd: 196, loadEventEnd: 241}

3、Chrome DevTools性能时间轴面板-首次有意义绘图

本章将使用Chrome性能指标(Chrome Performance Metrics)。但是,在上一章中我们不是已经测试性能计时了吗?是的,你可能会感到困惑。是由W3C维护的浏览器不可知测量标准(agnostic measure standard),所有的浏览器都应该有相同的API。

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

[ { name: 'Timestamp', value: 35037.202627 }, { name: 'AudioHandlers', value: 0 }, { name: 'Documents', value: 3 }, { name: 'Frames', value: 2 }, { name: 'JSEventListeners', value: 63 }, { name: 'LayoutObjects', value: 435 }, { name: 'MediaKeySessions', value: 0 }, { name: 'MediaKeys', value: 0 }, { name: 'Nodes', value: 506 }, { name: 'Resources', value: 11 }, { name: 'ScriptPromises', value: 0 }, { name: 'PausableObjects', value: 39 }, { name: 'V8PerContextDatas', value: 1 }, { name: 'WorkerGlobalScopes', value: 1 }, { name: 'UACSSResources', value: 0 }, { name: 'LayoutCount', value: 2 }, { name: 'RecalcStyleCount', value: 5 }, { name: 'LayoutDuration', value: 0.0860430000029737 }, { name: 'RecalcStyleDuration', value: 0.00374899999587797 }, { name: 'ScriptDuration', value: 0.0770069999925909 }, { name: 'TaskDuration', value: 0.297364000020025 }, { name: 'JSHeapUsedSize', value: 6295344 }, { name: 'JSHeapTotalSize', value: 10891264 }, { name: 'FirstMeaningfulPaint', value: 35036.03356 }, { name: 'DomContentLoaded', value: 35036.122972 }, { name: 'NavigationStart', value: 35035.833805 },]

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

目前,在0.13版本中,只有通过才能获得原始协议的方法。在不久的将来会改变的。我们将通过来发送,使用来自原始的DevTools协议的方法getMetrics。

const { getTimeFromPerformanceMetrics, extractDataFromPerformanceMetrics,} = require('./helpers');async function testPage(page) { await page.goto('http://localhost:8080'); await page.waitFor(1000); const performanceMetrics = await page._client.send('Performance.getMetrics'); return extractDataFromPerformanceMetrics( performanceMetrics, 'FirstMeaningfulPaint' );}module.exports = testPage;

这个代码与前一章的代码类似,但是请记住在网页上下文中执行,在浏览器级别上执行(特别是Chrome)。这就是为什么两个指标的navigationStart时间都不相同。

如果你在中发现了奇怪的代码,这就对了。但为什么需要延迟测量?在这个例子中小于加载事件时间,你可能会更困惑(并直到load事件。这是由于不是准时的任意时间点,这个测量是基于一些启发式的,并且是在所有页面渲染完毕后计算的。

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

async function testPage(page) { // ... // await page.waitFor(1000); // const performanceMetrics = await page._client.send('Performance.getMetrics'); let firstMeaningfulPaint = 0; let performanceMetrics; while (firstMeaningfulPaint === 0) { await page.waitFor(300); performanceMetrics = await page._client.send('Performance.getMetrics'); firstMeaningfulPaint = getTimeFromPerformanceMetrics( performanceMetrics, 'FirstMeaningfulPaint' ); } // ...}

现在,当代码没有竞争时(the code is free of race conditions),可以显示示例结果:

{ // result is in [ms] FirstMeaningfulPaint: 175}

4、自定义页面指标

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

这种方法导致“不可思议的谷”,可以被认定是“不可思议的谷”的开始,并且我们的自定义标准将代表“不可思议的谷”结束的时间。

我们必须判断在哪里写入。我推断,方法放在是一个好的做法:

beforeMount() { /* ... */ },mounted() { console.timeStamp('listLinksSpa');},beforeDestroy() { /* ... */ },

现在我们必须在之前注册监听器。当我们的应用程序调用中的回调函数时,我们可以提取这个度量的时间。

const { getTimeFromPerformanceMetrics } = require('./helpers');async function testPage(page) { let listLinksSpa; page.on('metrics', ({ title, metrics }) => { if (title === 'listLinksSpa') { listLinksSpa = metrics.Timestamp * 1000; } }); await page.goto('http://localhost:8080'); const performanceMetrics = await page._client.send('Performance.getMetrics'); const navigationStart = getTimeFromPerformanceMetrics( performanceMetrics, 'NavigationStart' ); await page.waitFor(1000); return { listLinksSpa: listLinksSpa - navigationStart, };}module.exports = testPage;

上面的代码应该没问题。但是代码质量与此是远远不能接受的 - 竞争条件的脆弱性在这里太明显了(the vulnerability to race condition is too obvious here)。我举上面的例子只是为了引出一个简单的例子。下面的代码通过在一个promise中包含page.on(’metrics’,callback)来解决这个问题,并使用了的特性 。

const { getTimeFromPerformanceMetrics, getCustomMetric } = require('./helpers');async function testPage(page) { const listLinksSpa = getCustomMetric(page, 'listLinksSpa'); await page.goto('http://localhost:8080'); const performanceMetrics = await page._client.send('Performance.getMetrics'); const navigationStart = getTimeFromPerformanceMetrics( performanceMetrics, 'NavigationStart' ); return { listLinksSpa: (await listLinksSpa) - navigationStart, };}module.exports = testPage;

现在结果应该是这样的:

{ // result is in [ms] listLinksSpa: 230}

5、从网络跟踪面板中提取数据

在Chrome面板中运行性能测试时,可以将数据保存为JSON文件。在Puppeteer中也是一样。只要在之前用开始记录跟踪,并且当你认为你需要的所有东西都被记录时,用停止记录。

在下面的代码中,我只展示提取CSS文件的开始和结束网络请求时间。

const { getTimeFromPerformanceMetrics, extractDataFromTracing,} = require('./helpers');async function testPage(page) { await page.tracing.start({ path: './trace.json' }); await page.goto('http://localhost:8080'); await page.tracing.stop(); const cssTracing = await extractDataFromTracing( './trace.json', 'common.3a2d55439989ceade22e.css' ); const performanceMetrics = await page._client.send('Performance.getMetrics'); const navigationStart = getTimeFromPerformanceMetrics( performanceMetrics, 'NavigationStart' ); return { cssStart: cssTracing.start - navigationStart, cssEnd: cssTracing.end - navigationStart, };}module.exports = testPage;

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

在代码中,在跟踪类型中搜索请求的文件。当它发现它会得到它的开始时间和。用于在资源结束时查找记录。

const fs = require('fs');const getTimeFromPerformanceMetrics = (metrics, name) => metrics.metrics.find(x => x.name === name).value * 1000;const extractDataFromTracing = (path, name) => new Promise(resolve => { fs.readFile(path, (err, data) => { const tracing = JSON.parse(data); const resourceTracings = tracing.traceEvents.filter( x => x.cat === 'devtools.timeline' && typeof x.args.data !== 'undefined' && typeof x.args.data.url !== 'undefined' && x.args.data.url.endsWith(name) ); const resourceTracingSendRequest = resourceTracings.find( x => x.name === 'ResourceSendRequest' ); const resourceId = resourceTracingSendRequest.args.data.requestId; const resourceTracingEnd = tracing.traceEvents.filter( x => x.cat === 'devtools.timeline' && typeof x.args.data !== 'undefined' && typeof x.args.data.requestId !== 'undefined' && x.args.data.requestId === resourceId ); const resourceTracingStartTime = resourceTracingSendRequest.ts / 1000; const resourceTracingEndTime = resourceTracingEnd.find(x => x.name === 'ResourceFinish').ts / 1000; resolve({ start: resourceTracingStartTime, end: resourceTracingEndTime, }); }); });module.exports = { getTimeFromPerformanceMetrics, extractDataFromTracing,};

CSS文件的跟踪数据如下所示。请记住,这只是数据中一千条记录中的一条。

{ // all results are in [ms] cssStart: 27, cssEnd: 40}

6、模拟低速网络和throttle CPU

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

const puppeteer = require('puppeteer');const testPage = require('./testPage');(async () => { let browser = await puppeteer.launch(); let page = await browser.newPage(); await page._client.send('Network.emulateNetworkConditions', { // 3G Slow offline: false, latency: 200, // ms downloadThroughput: 780 * 1024 / 8, // 780 kb/s uploadThroughput: 330 * 1024 / 8, // 330 kb/s }); await page._client.send('Emulation.setCPUThrottlingRate', { rate: 4 }); console.log(await testPage(page)); await browser.close();})();

现在你可以看到以前章节的汇总结果更加符合实际情况。

{ // all results are in [ms] cssStart: 542, cssEnd: 789, listLinksSpa: 2322, FirstMeaningfulPaint: 1061, responseEnd: 517, domInteractive: 812, domContentLoadedEventEnd: 2111, loadEventEnd: 2336}

7、控制浏览器缓存和service worker的重复访问

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

如果我们想测试重复访问只有缓存没有service worker,我们必须停止service worker在前一个入口注册通过之间的第一个结束第二个输入。 如果我们只想单独测试service worker,也是如此。

注意从其余的例子。 Chrome DevTools协议需要启用特定域名,但其中一些域名是由Puppeteer启用的。 ServiceWorker域名不在Puppeteer中使用,所以我们必须手工启动它。

const puppeteer = require('puppeteer');const testPage = require('./testPage');(async () => { let browser = await puppeteer.launch(); let page = await browser.newPage(); console.log(await testPage(page)); // first enter console.log(await testPage(page)); // second enter with cache and sw await browser.close(); browser = await puppeteer.launch(); page = await browser.newPage(); await testPage(page); // only for creating fresh instance await page._client.send('ServiceWorker.enable'); await page._client.send('ServiceWorker.stopAllWorkers'); console.log(await testPage(page)); // second enter only with cache await browser.close(); browser = await puppeteer.launch(); page = await browser.newPage(); await testPage(page); // only for creating fresh instance await page._client.send('Network.clearBrowserCache'); console.log(await testPage(page)); // second enter only with sw await browser.close();})();

8、结果

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

对于每个plot我运行测试100次,600页的入口,大约需要10 - 20分钟,每个测试套件。

有线网络

对于普通用户来说,最重要的指标是和。这些指标反映了他的网站速度。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 需要一些工作,但是如果仅仅关注良好的网络和好设备的结果,益处并不是那么明显。 如果网络速度下降,一切都会改变。

好设备,慢3G网络

由service worker处理的度量标准的时间与上图中的相同。 由于双重延迟,仅从缓存中提供的请求浪费了大量时间。 这就是为什么大延迟是移动网络中最有问题的因素,而不是小带宽。

总体来看,这一点很明显,这就是为什么service worker会应用到移动设备。 你可以使用service worker提高编程的网站速度,可以提高网络带宽,但不能极大地提高速度。

慢3G网,差设备

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

首次进入速度降低1.4倍

只有缓存的速度要慢2.6倍

service worker慢5.8倍

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

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

只要输入

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180205B0DA6500?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券