前端性能优化清单

测试积点老人

1、做好准备：计划和指标

微观优化对于保持业绩的顺利进行是非常重要的，但是要明确定义目标是至关重要的——可衡量的目标会影响整个过程中做出的任何决策。有几种不同的模型，下面讨论的模型都是很有见地的——只要确保尽早设置自己的优先级。

1.1、建立一种性能文化（1）

在许多组织中，前端开发人员确切知道哪些常见的底层问题以及应该使用何种加载模式来修复这些问题。但是，只要开发/设计和营销团队之间没有一致，绩效就不会长期持续下去。研究客户服务中常见的抱怨，看看提高性能如何帮助解决这些常见问题。

运行性能实验并测量结果 -无论是在移动设备上还是在桌面上。它将帮助您建立一个公司量身定制的案例研究与真实的数据。此外，使用来自wpo统计信息发布的案例研究和实验的数据可以帮助提高业务对于性能至关重要的敏感性，以及它对用户体验和业务指标的影响。说虽然单靠表演是不够的，你还需要建立一些可衡量和可追踪的目标并观察它们。

1.2、目标：至少比最快的竞争对手快20％（2）

根据心理学研究，如果你希望用户觉得你的网站比竞争对手的网站快，你至少要快20％。研究你的主要竞争对手，收集他们如何在移动和桌面上执行的指标，并设置阈值，将帮助你超越他们。为了获得准确的结果和目标，首先要研究你的分析，看看你的用户在哪里。那么你可以模仿第90百分位的测试经验。收集数据，建立电子表格，削减20％，并以这种方式设定你的目标（即绩效预算）。现在你有一些可以测试的东西。

如果你在考虑预算的情况下，尽量减少最小的脚本以便快速交互，那么你就处于一个合理的路径上。lara hogan关于如何用性能预算来处理设计的指南可以为设计人员提供有用的指针，而性能预算计算器和浏览器卡路里都可以帮助创建预算。

超出绩效预算，考虑对您的业务最有利的关键客户任务。设定和讨论关键行动的可接受的时间阈值，并建立整个组织已经同意的“准备就绪”的用户时间标记。在许多情况下，用户旅程将涉及许多不同部门的工作，因此，按照可接受的时间安排将有助于支持或阻止下一步的业绩讨论。确保额外的资源和功能的额外成本可见和理解。

另外，正如帕特里克·梅南（patrick meenan）所建议的那样，在设计过程中计划一个装载顺序和权衡是值得的。如果您尽早优先考虑哪些部分更为重要，并确定它们应该出现的顺序，您也将知道什么可以推迟。理想情况下，该顺序也将反映您的CSS和JavaScript导入的顺序，所以在构建过程中处理它们将更容易。当页面被加载时（例如当网页字体没有被加载时），考虑“中间”状态下的视觉体验应该是什么。

计划，计划，计划。可能很早就进入快速优化的阶段，并且最终可能成为快速获胜的一个好策略 -但是如果没有规划和现实的公司规划，量身定制的表现目标。

1.3、选择正确的指标（3）

不是所有的指标都同样重要。研究哪些指标对于您的应用程序最为重要：通常，这与您能够以多快的速度开始渲染最重要的像素（以及它们是什么）有关，以及为这些渲染的像素提供输入响应速度的速度。这些知识将为您持续努力提供最佳的优化目标。这样或者那样，而不是专注于整个页面加载时间（例如通过onload和domcontentloaded计时），优先考虑您的客户感知的页面加载。这意味着要关注一组稍微不同的指标。实际上，选择正确的指标是一个没有明显优势的过程。

以下是一些值得考虑的指标：

l 第一个有意义的油漆（fmp，当主要内容出现在页面上），

l 英雄渲染时间（当页面的重要内容完成渲染时），

l 交互的时间（tti，布局已经稳定的点，关键字体是可见的，并且主线程足以处理用户输入-基本上是用户可以点击ui并与之交互的时间标记），

l 输入响应性（界面响应用户操作需要多少时间），

l 知觉速度指数（测量页面内容的可视化速度有多快;得分越低越好），

l 您的自定义指标，由您的业务需求和客户体验所定义。

steve souders有每个指标的详细解释。而在许多情况下，tti和输入响应将是最关键的，这取决于您的应用程序的上下文，这些度量可能有所不同：例如，对于netflix电视用户来说，键盘输入响应能力，内存使用情况和tti更为重要。

1.4、收集代表观众的设备上的数据（4）

为了收集准确的数据，我们需要彻底选择要测试的设备。选择一个motog4，一个中档的三星设备和一个像nexus 5x这样的好的中间设备，或许在一个开放的设备实验室里是个不错的选择。如果您手边没有设备，则可以通过在节流网络（例如150ms rtt，1.5 mbps向下，0.7 mbps向上）上进行测试来模拟桌面上的移动体验（速度为5倍速度减速）。最终切换到常规3G，4G和WiFi。为了使性能影响更加明显，您甚至可以在办公室中引入2g星期二或者在您的办公室中设置一个节流3g网络，以便进行更快的测试。

幸运的是，有很多很棒的选项可以帮助您自动收集数据，并根据这些指标衡量您的网站在一段时间内的表现。请记住，良好的性能指标是被动和主动监控工具的组合：

l 被动监视工具，可以根据请求模拟用户交互（综合测试，例如灯塔，网页测试）

l 主动监控工具，不断记录和评估用户的交互（真实的用户监控，例如speedcurve，新的文物-这两个工具也提供综合测试）。

前者在开发过程中特别有用，因为它可以帮助您在使用产品时保持正轨。后者对于长期维护非常有用，因为它可以帮助您了解当用户实际访问站点时发生的性能瓶颈。通过使用导航时间，资源定时，绘图时间，长时间任务等内置朗姆酒API，无源和有源性能监测工具一起提供应用程序性能的完整画面。例如，您可以使用pwmetrics，calibre，speedcurve，mpulse和boomerang，sitespeed.io，这些都是性能监控的绝佳选择。

注意：在浏览器外部选择网络级别的通道总是比较安全的，例如devtools由于实现的方式，而与http / 2 push有交互问题。

1.5、与同事分享清单（5）

确保清单对您的团队中的每个成员都很熟悉，以避免误解。每个决策都有性能影响，项目将从前端开发人员获得巨大收益，将整个团队的绩效价值正确地传达给每个人，这样每个人都会为此感到责任，而不仅仅是前端开发人员。根据绩效预算和清单中定义的优先顺序制定设计决策。

2、设定切实的目标2.1、100毫秒响应时间，60 fps（6）

为了使交互感觉平滑，界面有100ms响应用户的输入。任何更长的时间，用户觉得应用程序laggy。轨道，一个以用户为中心的性能模型为您提供了健康的目标：为了允许<100毫秒的响应，页面必须在每个<50毫秒后最迟将控制权交还给主线程。估计输入延迟告诉我们，如果我们正在达到这个门槛，理想情况下，它应该低于50ms。对于像动画这样的高压点，最好不要在别的地方做任何事情，在绝对的最小的地方做不到的地方。

而且每帧动画应该在16毫秒内完成，从而达到每秒60帧（1秒÷60 = 16.6毫秒） -最好在10毫秒以下。因为浏览器需要时间将新框架绘制到屏幕上，您的代码应该在达到16.6毫秒之前完成执行。乐观，明智地使用空闲时间。显然，这些目标适用于运行时性能，而不是加载性能。

2.2、速度指数<1250，tg <3s，关键文件大小预算<170kb（7）

尽管实现起来可能非常困难，但是一个好的最终目标将是在1秒内有意义的油漆，在1250以下的速度指数值。考虑到在慢速3G网络上的基线是一个200美元的android手机（例如moto g4），仿真时间为400msrtt和400kbps的传输速度，目标为5s以下互动，重复访问，目标为2s以下。

请注意，在谈到交互式时间时，最好先区分互动性和一致性，以避免误解。前者是主内容呈现之后的最早点（其中至少有5秒钟的页面响应）。后者是页面可以预期总是对输入作出响应的地方。

HTML的第一个14〜15kb是最关键的有效负载块-而且是第一次往返传输的预算的唯一部分（这是你在400ms rtt下1秒内获得的）。更一般地说，为了实现上述目标，我们必须在最大的关键文件大小预算内运行。170KB gzipped（0.8-1mb解压缩）已经将需要长达1秒（取决于资源类型）解析和编译在一般的电话。略高于此就好，但要尽可能降低这些数值。你也可以超越捆绑大小的预算。例如，您可以在浏览器的主线程的活动上设置性能预算，例如在开始渲染之前绘制时间，或者追踪前端cpu hogs。像calibre，speedcurve和bundlesize这样的工具可以帮助您控制预算，并且可以集成到构建过程中。