前端性能优化清单
原文地址：https://www.smashingmagazine.com/2018/01/front-end-performance-checklist-2018-pdf-pages/
前端性能优化清单
性能很重要——我们都知道。但是，我们是否真的总是知道我们的性能瓶颈究竟是什么？是昂贵的JavaScript，慢Web字体传递，沉重的图像，或缓慢渲染？是否值得借助交叉口观察员，客户提示，css遏制，HTTP / 2和service worker探索摇树优化，范围提升，代码分割以及所有的花式加载模式？最重要的是，我们从哪里开始提高绩效，如何建立一个长期的绩效文化？
早些时候，性能往往只是事后才想到的。通常推迟到项目的最后，这将归结为缩小，串联，资产优化和可能在服务器的配置文件上的一些细微的调整。现在回头看，事情似乎已经发生了相当大的变化。
性能不仅仅是一个技术问题：它很重要，而且在将其引入到工作流程中时，必须通过性能影响来告知设计决策。性能必须不断测量，监控和改进，网络日益复杂的挑战使得很难跟踪指标，因为指标会因设备，浏览器，协议，网络类型和延迟而显着变化（cdns，isps，缓存，代理，防火墙，负载均衡器和服务器都在性能中发挥作用）。
所以，如果我们在提高性能的时候创建了所有事情的概述，从流程的开始到网站的最终发布，这个列表会是什么样的？下面你会发现2018年的一个（希望是公正的，客观的）前端性能检查清单——你可能需要考虑的问题的概述，以确保你的响应时间快，用户交互顺畅，你的网站不流失用户的带宽。
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这样的工具可以帮助您控制预算，并且可以集成到构建过程中。
3、定义环境
3.1、选择并设置您的构建工具（8）
不要太在意这些天过得好酷的东西。坚持你的环境来建设，无论是咕噜咕噜，喝咖啡，webpack，包裹，或工具的组合。只要你得到的结果你需要快速，你没有任何问题，维护你的构建过程，你做得很好。
3.2、逐步增强（9）
保持逐步增强作为前端架构和部署的指导原则是一个安全的选择。先设计和构建核心体验，再用强大的浏览器的先进功能增强体验，创造灵活的体验。如果您的网站运行速度很慢，而且网页浏览器效果不佳，您的网页显示效果不佳，那么在网络不错的浏览器上运行速度会更快。
3.3、选择一个强大的性能基准（10）
有很多未知因素会影响加载 -网络，热调节，缓存驱逐，第三方脚本，解析器阻塞模式，磁盘I / O，ipc jank，安装的扩展，cpu，硬件和内存限制，l2 / l3缓存区别，rtts，图像，Web字体加载行为- JavaScript有最重的经验成本，旁边的Web字体阻止默认渲染和图像往往消耗太多的内存。随着性能瓶颈从服务器移到客户端，作为开发者，我们必须更详细地考虑所有这些未知数。
一个170kb的预算已经包含关键路径html / css / javascript，路由器，状态管理，实用程序，框架和应用程序逻辑，我们必须仔细研究网络传输成本，解析/编译时间和运行时间成本我们选择的框架。
正如seb markbager所指出的那样，衡量框架启动成本的一个好方法是首先渲染一个视图，然后删除它，然后再次渲染，因为它可以告诉你框架是如何扩展的。
第一个渲染往往会预热一堆懒洋洋地编译的代码，一个更大的树可以从它的缩放中受益。第二个渲染基本上是模拟页面上的代码重用如何随着页面复杂度的增长而影响性能特性。
不是每个项目都需要一个框架。事实上，一些项目可以从完全移除现有的框架中受益。一旦选择了一个框架，你至少要呆上几年，所以如果你需要使用框架，请确保你的选择是知情的和充分考虑的。在选择一个选项之前，至少考虑大小和初始解析时间的总成本是一个好主意;preact，inferno，vue，苗条或聚合物等轻量级选项可以让工作顺利完成。基线的大小将定义应用程序代码的约束条件。
请记住，在移动设备上，与台式机相比，您应该预计会有4倍-5倍的放缓。移动设备有不同的gpus，cpu，不同的内存，不同的电池特性。手机上的解析时间比桌面上高36％。因此，请始终在平均设备上进行测试-这是最能代表您的受众群体的设备。
不同的框架将会对性能产生不同的影响，并且需要不同的优化策略，所以你必须清楚地理解你将依赖的框架的所有细节。在构建Web应用程序时，请查看prpl模式和应用程序外壳架构。这个想法非常简单：将初始路由的交互性所需的最小代码推送为快速渲染，然后使用service worker进行缓存和预先缓存资源，然后异步地延迟加载所需的路由。
3.4、你会使用AMP或即时文章么（11）
根据贵组织的优先级和策略，您可能需要考虑使用谷歌的放大器或Facebook的即时文章或苹果的苹果新闻。如果没有它们，你可以获得良好的性能，但是放大器确实提供了一个可靠的内容交付网络（cdn）的性能框架，而即时文章将提高你在Facebook上的知名度和性能。
这些技术对用户的主要好处是保证了性能，所以有时他们甚至可能更喜欢amp- / apple新闻/即时页面链接，而不是“普通”和可能膨胀的页面。对于处理大量第三方内容的内容较重的网站，这些选项可能会大大加速渲染时间。
网站所有者的利益是显而易见的：这些格式在各自的平台上的可发现性以及在搜索引擎中的可见度提高。你也可以建立一个渐进的网络放大器，通过重用amps作为你的pwa的数据源。下行？显然，在围墙花园中的存在使得开发者能够产生并保持其内容的单独版本，并且在即时文章和苹果消息的情况下没有实际的URL。
3.5、明智地选择你的cdn（12）
根据您拥有多少动态数据，您可能能够将某些部分内容“外包”到静态站点生成器，并将其推送到cdn并从中提供静态版本，从而避免数据库请求。你甚至可以选择一个基于cdn的静态托管平台，用交互式组件增强页面（jamstack）。
请注意，cdns也可以提供（和卸载）动态内容。所以，限制你的cdn到静态资产是没有必要的。仔细检查你的cdn是否执行压缩和转换（例如格式化，图像优化压缩和边缘调整），智能http / 2交付，边缘包括，在cdn的边缘组装页面的静态和动态部分（即离用户最近的服务器）以及其他任务。
4、构建优化
4.1、确定你的优先顺序（13）
首先知道你在处理什么是个好主意。运行所有资产（JavaScript，图像，字体，第三方脚本和页面上的“昂贵”模块，如轮播，复杂的信息图表和多媒体内容）的清单，并将其分组。设置一个电子表格。定义传统浏览器的基本核心体验（即完全可访问的核心内容），增强的功能强大的浏览器体验（即丰富的，完整的体验）和额外资源（不是绝对需要的，可以延迟加载的资源，例如网页字体，不必要的风格，旋转木马脚本，视频播放器，社交媒体按钮，大图像）。我们发表了一篇关于“提高粉丝杂志的表现”的文章，详细描述了这个方法。
4.2、考虑使用“切割芥菜”模式（14）
尽管相当古老，但我们仍然可以使用切割芥末技术将核心体验发送到传统浏览器，并增强现代浏览器的体验。在加载资源时要严格：加载核心体验，然后进行增强，然后加入额外的内容。请注意，该技术从浏览器版本中推导设备功能，这已经不是我们现在可以做的事了。例如，发展中国家的廉价Android手机大多运行Chrome，尽管其内存和CPU的能力有限，但仍将切断芥末。这就是prpl模式可以作为一个很好的选择。最终，使用设备内存客户端提示标题，我们将能够更可靠地定位低端设备。在写这篇文章的时候，头文件只能在眨眼的时候才支持（一般用于客户端提示）。由于设备内存也有一个已经在Chrome浏览器中可用的JavaScript API，一个选项可能是基于API的功能检测，并且只有在不受支持的情况下回退到“切割芥末”技术
4.3、解析JavaScript是昂贵的，所以保持小（15）
在处理单页面应用程序时，可能需要一些时间来初始化应用程序，然后才能呈现页面。寻找模块和技术来加速最初的渲染时间（例如，这里是如何调试反应性能，以及如何提高角度性能），因为大多数性能问题来自初始解析时间来引导应用程序。
JavaScript有成本，但不一定是耗尽性能的文件大小。解析和执行时间取决于设备的硬件而显着变化。在一般的手机（moto g4）上，1MB（未压缩）javascript的解析时间将在1.3-1.4s左右，15-20％的时间都在手机上进行解析。随着编译的玩法，只是准备工作的JavaScript平均需要4秒，大约11秒之前，第一次有意义的移动会话。原因：在低端移动设备上，解析和执行时间可以轻松地提高2-5倍。
避免分析成本的一个有趣的方法是使用最近引入的用于实验的二进制模板。这些模板不需要被解析。
这就是为什么检查每个JavaScript依赖关系至关重要的原因，像bundle buddy，webpack-bundle-analyzer和source map explorer这样的工具可以帮助你实现这一点。测量JavaScript解析和编译时间。etsy的设备时间，一个小工具，允许您指示您的JavaScript测量任何设备或浏览器上的解析和执行时间。底线：虽然规模很重要，但这不是一切。当脚本大小增加时，解析和编译时间不一定会线性增加。
4.4、你在使用提前编译器吗？（16）
使用提前编译器将一些客户端渲染卸载到服务器，从而快速输出可用的结果。最后，考虑使用optimize.js更快的初始加载，通过包装急切调用的函数（但可能不再需要）。
4.5、你在使用摇树优化，范围提升和代码分割吗？（17）
树形抖动是一种清理构建过程的方法，仅包含生产中实际使用的代码，并消除webpack中未使用的导出。与webpack 3和汇总，我们也有范围提升，允许这两个工具来检测哪里进口链可以被夷为平地，并转换成一个内联函数而不妥协的代码。与webpack 4，你现在可以使用json树抖动。uncss或氦气可以帮助你从CSS中删除未使用的风格。
另外，你可能要考虑学习如何编写高效的CSS选择器，以及如何避免膨胀和昂贵的风格。感觉就像超越那个？您也可以使用webpack来缩短类名称，并使用作用域隔离来在编译时动态地重命名css类名称。
代码拆分是另一个webpack功能，将您的代码分解为按需加载的“块”。不是所有的JavaScript都必须立即下载，解析和编译。一旦在代码中定义了分割点，webpack就可以处理依赖和输出文件。它使您可以保持最初的下载量小，并在应用程序请求时按需请求代码。另外，请考虑使用preload-webpack-plugin，它采用代码分割的路由，然后使用“preload”>或“prefetch”>提示浏览器预加载它们。
在哪里定义分割点？通过跟踪哪些css / javascript块被使用，哪些不被使用。umar hansa解释了如何使用devtools的代码覆盖率来实现它。
如果您不使用webpack，请注意汇总显示比browserify导出显着更好的结果。虽然我们在这里，但您可能需要查看rollupify，它将ecmascript 2015模块转换为一个大的commonjs模块-因为根据您对bundler和模块系统的选择，小模块可能会有令人惊讶的高性能成本。
最后，es2015在现代浏览器中得到了非常好的支持，可以考虑使用babel-preset-env来仅转发您所定位的现代浏览器不支持的es2015 +功能。然后建立两个版本，一个在es6和一个在es5。我们可以使用script type =“module”来让带有es模块的浏览器支持加载文件，而旧的浏览器则可以使用script nomodule加载遗留的build。
对于lodash，使用babel-plugin-lodash将只加载你在源代码中使用的模块。这可能会为您节省相当多的JavaScript负载。
4.6、利用你的目标JavaScript引擎的优化（18）
研究你的用户群中的JavaScript引擎占主导地位，然后探索优化它们的方法。例如，当在用于闪烁浏览器，node.js运行时和电子的v8优化时，利用脚本流来实现单片脚本。它允许异步或延迟脚本在下载开始后在单独的后台线程上解析，因此在某些情况下可将页面加载时间提高多达10％。实际上，在中使用