# 前端性能测试实践

随着我们进入假期，面向消费者的企业，如零售商、出版商和金融公司的前端性能测试的话题将变得更加重要。 另外，我敢肯定，在我们生活的这个2019冠状病毒疾病世界里，大多数人可能甚至都没有计划如何处理他们网站上比平时更高的流量。

这可能会令人沮丧。 我们的团队一开始可能会投入大量的精力来使我们的网站更快，但是您可能面临的一个挑战是，一旦您的应用程序发布到外部环境中，如何保持在事物的顶端。 我与许多开发人员和测试人员进行了交流，他们都在为如何随着时间的推移监视他们的站点速度，以及如何知道新版本的代码更改对前端性能有什么影响而苦恼。 所以，我从性能专家那里得到了最好的建议，比如 Andy Davies，他是《使用 WebPageTest: 新手和高级用户的 Web 性能测试》一书的作者，也是一位过去的性能指导者。 您将发现一些解决您和您的团队可能面临的前端性能挑战的方法。 继续往下读: The psychology of response times 反应时间的心理学 What front-end performance is and why it matters. 什么是前端性能，为什么它很重要 Ways to measure your application’s client-side performance 度量应用程序客户端性能的方法 A look at some free tools and commercial alternatives 一些免费工具和商业替代品 An example of a workflow your developers can follow 开发人员可以遵循的工作流示例

网页响应时间的心理学 让我们从一点人类心理学开始。 想象一下，回到50年前的1968年，当时鲍勃 · 米勒正在研究我们如何应对拖延。 他发现，只要你在一个动作的十分之一秒内收到回应，你就会立即看到，如果你按下一个按钮，一盏灯在一百毫秒内亮起，你就会感觉到那是瞬间。

当延迟在三分之一秒左右出现时，你会开始注意到亮光。如果你在一秒钟内收到回复，你就可以无缝地继续工作，而且不会中断你的工作流。 https://images.storychief.com/account_3792/ResponseTimesChart_f553f6ed1e1ef470eb4c08d9af602863_800.png

但是，拖延的时间越长，我们就越有可能反弹。 1968年，他们发现这个极限大约是10秒。 几年前，微软进行了类似的研究，发现这个限制超过了7或8秒。

为什么应用程序前端性能响应时间很重要？ 因为钱！ 如果你让人们在你的网站上等待，如果你提供了一个缓慢的体验，这将对你的业务产生根本性的负面影响。 当我们看到人们在网站上获得的真实体验数据，以及这些数据是如何影响他们的行为时，我们可以看到这一点。 这张图表来自于一个衡量真实商业经验并追踪他们行为的产品: https://images.storychief.com/account_3792/SpeedAffactsUserBehavor_1e4ff63934c8a33ed6c237b5edde20a5_800.png 正如你在图表中看到的，有快速体验的人在一个网站上浏览更多的页面。 如果你为零售商工作，这意味着他们会看更多的产品，这可能会导致更多的销售！ 如果你为一家依赖广告的出版商工作，这意味着他们会阅读更多的故事。 速度对人们行为的影响也会从根本上影响我们网站的成功程度。 https://images.storychief.com/account_3792/SiteConversionChart_d0e9990fdfe548b4a637d71672212e04_800.png 上面图表中的橙色线代表跳出率。 什么是跳出率？它表示有多少人访问你的网站，访问一个页面，然后离开。高跳出率意味着人们离开你的网站没有采取任何行动。 情况不妙。 你可以看到跳出率是最低的在三秒的标志，然后爬升之后。你让人们等待的时间越长，他们就越有可能只访问一个页面。

蓝线显示转换率。 转换率是指有多少人花钱买东西。 正如你所看到的，几乎没有人转换低于三秒; 可能是因为很少有页面在三秒之前完成。 我们让别人等得越久，他们就越不可能改变主意。 在四到七秒的时间里，我们的转化率从百分之五下降到百分之四。 这意味着大量的收入损失https://images.storychief.com/account_3792/ImproveSiteSpeedMoreMoney_8bee549e6cbd88f4e5ad92249cf377b1_800.png 上面的图表是 Andy 帮助零售商提高网站速度的一个例子。

在此之前，他们的目标是 Android 用户，他做了一些改变，将 Android 用户的体验中位数提高了4秒。

在做了这个小小的改变之后，他们看到来自这些访问者的收入增加了26% ！ 为什么你需要关注的不仅仅是你的后台表现

你的团队可能会花费大量的资金来建立和调整服务器群和数据库，并测试它们的能力，以确保你的公司能够很快地向你的网站访问者提供初始的 HTML 有效负载。 下面是一些英国网站的例子。 https://images.storychief.com/account_3792/LoadTimeOnFrontEndExample_d2eb780a934cbd66a9aa29e58c3fb55f_800.png 粉红色的条带显示了后端生成初始响应所用的时间。 蓝色代表所有其他资源ーー图像、脚本、样式表; 所有我们需要完成有效负载的东西。 当专注于性能时，不要忽略后端是很重要的，因为直到后端交付了响应，前端就没有工作了。 但是，影响这种体验的大部分工作实际上都发生在浏览器中。 如果你要测量前端性能洞察力，你需要一个心智模型来帮助你理解你收集的指标如何映射到实际的业务经验。

下面的模型是我们经常使用的。 软件用户体验的心智模型 https://images.storychief.com/account_3792/Whatyouarethinkingaboutpageloadtime_769a65a63dee90531a092ee474d488a6_800.png 上面的图片代表了一个访问者可能有的视觉线索，事情正常工作。 在这种情况下，我们可以看到浏览器栏改变了网站的地址，但是在什么时候这个页面才真正变得有用呢？是不是在这种情况下，英雄形象出现在中间？

对于不同的网站，这是不同的。

对于一个新的网站，它可能是当有人可以开始阅读新闻。

当产品图像出现时，访问者可以看到他们在零售商的正确页面上。 然后我们必须考虑: 页面在什么时候变得可用？在这个例子中，这是相当晚的，因为菜单按钮不是立即可用的。

因此，当我们考虑前端性能时，我们考虑的是页面加载需要多长时间才能变得有用？ 需要多长时间才能使用，在开始阶段发生了什么？有两种广泛的方法来衡量页面的性能。 如何测量你的前端页面性能 测量应用程序前端性能主要有两种方法: Synthetic 合成纤维

– in lab-style environments where we have defined test setups in known conditions

• 在实验室风格的环境中，我们在已知条件下定义了测试设置 In the Wild 在野外

– in real people's browsers, using whatever phone they're using, connected to whatever network they're using

• 在真人的浏览器中，使用他们正在使用的任何手机，连接到他们正在使用的任何网络 Both of these approaches have their place. 这两种方法都有各自的用武之地。这篇文章的重点是实验室方法，因为这是最适合我们如何建立性能到我们的初始工作流程。 请阅读这里的一些免费应用程序性能监视(APM)工具列表，您也应该查看。 从哪里开始考虑前端性能？

如果您什么也不做，那么关键的要点就是开始在 SDLC 中构建性能。越早越好是必不可少的！ 以下是一些你应该考虑性能的情况: When you're still in the planning phase, thinking about how big your pages will be and what they will be composed of 当你还在计划阶段的时候，考虑一下你的页面会有多大以及它们由什么组成 When you're running a test on each build to understand whether the build has made the site faster or slower 当您在每个构建上运行测试以了解构建是否使网站变得更快或更慢时 When you’re tracking your releases, and probably using an external APM tool to understand how your performance is changing now that you've released that software 当您跟踪您的发布，并且可能使用外部 APM 工具来了解您的性能是如何变化的，现在您已经发布了该软件 When checking your release(s) using synthetic and real-user-experience monitoring tools to understand what folks are experiencing in the wild, and then using that info to respond and adjust 在使用合成的和真实的用户体验监控工具检查发行版时，了解人们在野外正在经历什么，然后使用这些信息进行响应和调整

如果你决定你的应用程序将包含大量的字体，脚本和图片，当你发布它到野外，你发现你的用户正在经历缓慢的响应时间，你应该修改这些选择和瘦身你的网站。 将性能集成到持续集成(CI)/持续交付管道中，是根据性能 kpi 进行测试的必要步骤，以确保向用户提供良好的性能体验。

那么，如何开始在 SDLC 中构建性能呢？ 此时，您可能会问，“我应该如何开始将性能工程构建到我的开发工作流中? ”

首先，让我们看一些可用于在合成的、实验室类型的环境中测试性能的工具。 然后，您将看到如何将这些工具纳入 CI/CD 流程，以便在每次签入时，了解它们对性能的影响是正面的还是负面的。 介绍 Google Lighthouse 你想要使用的第一个工具是 Google Lighthouse。 内置了 Lighthouse，所以如果你安装了 Chrome，你可以直接开始实验并探索它提供的功能。

当您打开 DevTools 时，您应该看到 Lighthouse 的一个选项(仅供参考: 它过去被称为 Audit panel)。 当您启动 Lighthouse 时，它将开始检查页面的性能、可访问性和 SEO 最佳实践。

您还可以选择在移动方案中使用测试页面，该测试页面使用屏幕尺寸较小的模拟移动设备、慢速 cpu 和较慢的网络。或者，您可以在桌面设备上进行测试。 重复使用现有的自动化测试

将 googlelighthouse 合并到开发过程中的另一种方法是利用现有的自动化测试来获取这些数据。

有很多工具可以做到这一点，其中一个就是 cypress.io。

Io 有一个 Cypress-auditplugin，可以让你使用 Lighthouse。

这下好了！

你的表现数字是多少？

让我们使用英国版本的 Amazon 作为一个测试站点来尝试 Lighthouse 的特性。

当 Lighthouse 完成审计您的站点时，它将生成一个如下所示的报告: https://images.storychief.com/account_3792/LighthouseReport_148f96f5d32a85988a1a82341761bc7b_800.png

本例中的性能得分(20)不是很好，但是最好能够获得一个可以随时间跟踪的度量标准; 这在与公司利益相关者讨论性能时非常有用。

你也可以简单地用它来衡量你是变得更好还是更糟，或者作为与你的竞争对手的比较。

一旦你有了自己的数字，你就可以开始专注于如何改进它。

谷歌灯塔的其他功能 除了主要的性能得分，还有其他指标来衡量访问者在页面加载时可能拥有的体验。

https://images.storychief.com/account_3792/GoogleLighthouseMetrics_40cadb139b625e2c858eb221902eecd7_800.png First Contentful Paint 第一次饱满的油漆 —when did content start to get painted to the screen? 内容是什么时候开始出现在屏幕上的？ Speed Index 速度指数 —measures how long it takes for the visitor screen to go from blank to being fully complete and stable. The faster the better when it comes to the experience your users receive. ー测量访客屏幕从空白到完全完成及稳定所需的时间。用户体验越快越好 Time to Interactive 互动时间 —tries to measure when a visitor can start interacting with your application by being able to click, scroll, or enter text into a text box. ー尝试通过点击、滚动或在文本框中输入文本来测量访问者何时可以开始与您的应用程序进行交互 These metrics help you to judge the visitor's experience. 这些指标可以帮助您判断访问者的体验。 因此，您在报告中看到的总体“性能”评分是一个很好的高级度量标准，可以用来跟踪随时间变化的相对性能。

如果您想深入了解，您可以使用这些较低级别的度量标准来跟踪并查看您可能在哪些方面变得更好或更糟。

灯塔也会给你一些建议，你可以做得更好。

然后，在诊断中，您可以看到一些原因，为什么你得到了你所做的分数。

总的来说，Lighthouse 提供了一个顶级的度量标准来跟踪，而子度量标准则可以用来理解如何使页面更快。 DebugBear 有一些经济有效的商业工具可以帮助你随着时间的推移跟踪 Lighthouse 的得分。 其中一个是 DebugBear，它将在你定期提供的网页或网页集上运行 Lighthouse，并生成类似下面这样的指示板:https://images.storychief.com/account_3792/DebugBear_b3a7c6b8d985c20be9f992222519d6e2_800.png

这样可以很容易地看到所有关键的前端性能指标是如何随着时间而变化的。 Treo Treo 是另一个可以为您创建 Lighthouse 指示板以及随时间变化的跟踪性能的产品。 Treo 提供了最近一次考试的分数、时间和主要分数的快照。然后你可以滚动看看它是如何随着时间变化的。

这些工具可以帮助您利用 Lighthouse 不仅创建快照，还可以将其用作 SDLC 的一部分，以跟踪性能随时间的变化。 WebPageTest WebPageTest 通常被称为性能测试工具的瑞士军刀。 它使用真正的浏览器，不仅仅是 Chrome 作为 Lighthouse，你还可以在 Firefox，Edge，Chrome 和其他浏览器中进行测试。你也可以在真正的移动设备上进行测试。

与 Lighthouse 类似，你基本上可以在世界各地的多个位置进行测试，而 WebPageTest 有四个区域，DebugBear 和 Treo 各有10或13个区域。

当你从 WebPageTest 运行测试时，你有很多选项，包括捕捉视频，这很方便。 测试完成后，它会生成如下的报告: https://images.storychief.com/account_3792/WebPageTestReport_1006dc114d4de88e7f52f0d8efaa3c95_800.png 您将收到一组关于页面的指标，这些指标的详细程度比 Lighthouse 稍低一些。

在这份报告中，安迪首先看到的是页面的视频片段: https://images.storychief.com/account_3792/WebPageTestGileStrip_a4c946b1d31d21e7be6e951df15b9396_800.png

这种观点对于展示关键表演领域是非常有效的，因为每个人都理解幻灯片。 它建立了对访客体验的真实感受的共鸣。 WebPageTest 比 Lighthouse 提供了更丰富、更广泛的指标集。 它还使您能够深入了解这些测试，以收集更多的信息，并真正理解为什么会得到这些结果。 类似于 Lighthouse 的商业版本，WebPageTest 也有商业版本。 SpeedCurve and Calibre 和 Calibre Speedcurve 使用了和 WebPageTest 相同的引擎，并且随着时间的推移跟踪性能。 你可以设置跟踪每小时或每天。 另一个没有内置到 WebPageTest 中但是有类似功能的产品是 Calibre。 SpeedCurve 和 Calibre 都可以帮助您跟踪站点的性能，无论是在交付准备环境中还是在真实的实时环境中。 CI/CD 中 api 的威力 Andy 提到他想引入 DebugBear、 Treo、 SpeedCurve 和 Calibre，因为它们都有 api。 当一个产品拥有一个 API，允许您开始测试或按需调用一个测试，并在测试完成后返回结果时，这意味着您可以开始将其集成到构建流程和开发生命周期中。 当您进行更改时，您可以跟踪这些更改如何影响 Lighthouse 中的分数，或 WebPageTest、 SpeedCurve 和 Calibre 中的绝对原始计时。 我还要提到的另一点是 SpeedCurve 和 Calibre 都具有随时间推移跟踪性能的能力，因为它们都将 Lighthouse 融入其中。 可以把它们看作是与 DebugBear 和 treo 类型产品相比的一个进步。 你可能想知道为什么你应该使用供应商付费的解决方案，当你可以得到很好的开源。 Andy 发现将这些见解作为团队 CI/CD 管道的一部分是非常关键的。付费的解决方案允许你访问这个功能。 根据他的经验，将前端性能测试构建成持续集成周期是客户坚持良好性能实践的最佳方式。 要查看 Andy 演示如何与诸如 GitHub 之类的 CI/CD 工具集成，请务必注册以获取他的会话视频和实时问答。 建议如何开始与前端性能工程 在这篇文章的开头，我提到 Andy 在 Android 零售的例子中对用户响应时间做了大量的改进，但并不总是那么简单。 我们经常获得一系列小的、渐进的收益，最终累积成更大的收益。 将前端性能构建到工作流中也是如此。 从简单的开始ーー也许从 PageSpeed Insights、 Lighthouse 或者其他商业服务开始。 对你现在所处的位置设置一些限制，并利用这些限制来确保在你做出改变的时候事情不会变得更糟。然后，随着时间的推移，开始致力于更先进的速度改进。 请记住: 谷歌正计划开始将性能作为其搜索算法的排名因素之一，这意味着不久后，你的其他业务也将对前端性能产生兴趣。下载安迪的免费前端性能大师级视频获得安迪的大师级视频添加前端性能的测试生命周期。在这个部分中，Andy 探索了网站速度的一些关键方面，为什么它们很重要，以及我们如何衡量它们。然后，他将继续演示我们如何将他们的测试自动化，并将其纳入我们的软件生命周期。下载

对“完整的前端性能测试指南”的一个回应

# author

石头 磊哥 seven 随便叫

# company

thoughtworks（离职了。。。。）

大家好，本人不才，目前依旧混迹于thoughtworks，做着一名看起来像全栈的QA，兴趣爱好前端，目前是thoughtworks 西安QA社区的leader，如果有兴趣分享话题，或者想加入tw，可以找我

# roles

QA（营生） dev（front-end dev 兴趣爱好）

# 联系方式

如果想转载或者高薪挖我 请直接联系我 哈哈

# wechat:

qileiwangnan

# email:

qileilove@gmail.com