【译】2018 前端性能优化清单 —— 第一部分

• 原文地址：Front-End Performance Checklist 2018 - Part 1
• 原文做者：Vitaly Friedman
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：tvChan
• 校对者：mysterytony ryouaki

2018 前端性能优化清单 —— 第一部分

下面你将会看到你可能须要考虑到的前端性能优化问题，以保证你的应用具备快速和流畅的响应时间。

• 2018 前端性能优化清单 —— 第一部分
• 2018 前端性能优化清单 —— 第二部分
• 2018 前端性能优化清单 —— 第三部分
• 2018 前端性能优化清单 —— 第四部分

---

作好准备：计划和指标

微小的优化对于保持性能来讲都是很重要的，可是在头脑中明确的定义 —— 可衡量的目标才是相当重要的。这将会影响你整个过程当中作出的任何决定。有几种不一样的模型，下面讨论的模型都颇有本身的主见 —— 只要确保在一开始能设定本身的优先级就行。

1. 创建性能指标。

在许多组织里，前端开发人员确切的知道常见的潜在问题是什么，而且知道使用什么加载模块来修复它们。然而，只要开发/设计和营销团队之间没有一致性，性能就不能长期维持。研究客户服务中的常见投诉，了解如何提升性能，能够帮助解决这些常见问题。

在移动和桌面设备上运行性能实验和测量结果。它将帮助你的公司量身定作一个根据真实数据而获得的研究案例。此外，利用 WPO 统计 数据对案例进行研究和实验，能够帮助提升业务对性能问题的敏感度，以及它对用户体验和业务指标的影响。仅仅说明性能问题是远远不够的 —— 你也须要创建一些可衡量和可跟踪的目标并对它们进行观察。

2. 目标：至少要比你最快的竞争对手还快 20%。

根据心理学的研究，若是你想让用户感受你的网站比竞争对手的快，你至少须要比它们快 20%。 研究你的主要竞争对手，收集它们是怎么在手机和桌面设备上展现的数据，而且设置阀值来帮助你超过它们。要获取准确的结果和目标，首先要研究你的分析结果，看看你的用户都在作什么。而后，你能够模拟第百分之九十位的实验进行测试。收集数据，建立一个 电子数据表，从中剔除 20%, 并制定你的目标（即 性能预算）。如今你就有一些能够测试的东西了。

若是你但愿保持如今的成本不变，并尽量的少写一些脚本，就能有一个快速的可交互时间。那么你已经走在正确的道路上了。劳拉.霍根的指导你如何用性能预算接近设计 里提供了有用的方向，设计人员，性能预算计算者和 Browser Calories 能够帮助咱们建立预算（感谢 Karolina Szczur 的牵头）。

除了性能预算以外，还要考虑对你的业务最有利的关键客户任务。设置和讨论可接受的关键行为的时间阈值，并创建整个项目组都已经赞成的 ＂UX 就绪＂的用户计时标记。在许多状况下，用户的需求将会影响到许多不一样部门的工做。所以, 在可接受的时间内进行调整，将有助于支持或避免了在优化路上的性能讨论。确保增长资源和功能的额外成本是可预见和可理解的。

此外, 正如 Patrick Meenan 建议的，在设计过程当中制定一个加载顺序及其权衡是很是值得。若是你在早期优先考虑哪些部分更重要，而且定义了它们应该出现的顺序，那么你也将知道哪些部分能够延迟。在理想状况下，该顺序还将反映 CSS 和 JavaScript 的导入顺序。所以，在构建过程当中处理它们会更容易。此外，在加载页面时，请考虑在"中间"状态下的视觉体验 (例如，web 字体还没有加载时)。

计划，计划，计划。在早期的优化里，它可能像是诱人的＂熟水果＂ —— 最终它多是一个很好的能快速取胜的策略 —— 可是，若是没有计划和切合实际的、为公司量身定制的性能目标，就很难将性能放在首位。

3. 选择正确的指标。

并非全部的指标都一样重要。研究哪些标准对你的应用程序最重要：一般它与你开始渲染那些最重要的像素点（以及它们是什么）有多快和如何快速地为这些渲染的像素点提供输入响应有关。这能够帮助你为后续的工做提供最佳的优化结果。无论怎样，不要专一于整个页面的加载时间（例如，经过 onLoad 和 DOMContentLoaded 计时），而是优先加载用户认为重要的页面。这意味着要专一于一组稍有不一样的指标。事实上，选择正确的指标是一个没有对手的过程。

首次有内容渲染，首次有效渲染，视觉完整和可交互时间之间的区别。大图。来自于：@denar90

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

• 首次有效渲染（FMP，是指主要内容出如今页面上所需的时间），
• 英雄渲染时间（页面最重要部分渲染完成所需的时间），
• 可交互时间（TTI，是指页面布局已经稳定，关键的页面字体已经可见，主进程能够足够的处理用户的输入 —— 基本的时间标记是，用户能够在 UI 上进行点击和交互），
• 输入响应，接口响应用户操做所需的时间，
• 速度指标，测量填充页面内容的速度。 分数越低越好，
• 你的自定义指标，由你的业务需求和客户体验来决定。

Steve Souders 对每一个指标都进行了详细的解释。在许多状况下，根据你的应用程序的上下文，可交互时间和输入响应会是最关键的。但这些指标可能会不一样：例如，对于 Netflix 电视的用户界面来讲，关键输入响应、内存使用和可交互时间更为重要。

4. 从具备表明性的观众的设备上收集数据。

为了收集准确的数据，咱们须要完全的选择要测试的设备。也许在一个开放式的实验室里，Moto G4 是一个很好的选择，它是一款中档的三星设备又或者是一个普通的设备，如 Nexus 5X。若是你手边没有设备，能够在节流网络（例如，150 ms 的往返时延，1.5 Mbps 如下，0.7 Mbps 以上）上使用节流 CPU（5× 减速）实如今桌面设备上模拟移动设备的体验。最终，切换到常规的 3G，4G 和 wi-fi。为了使性能体验的影响更明显，你甚至能够在你的办公室里引入 2G Tuesdays 计划或者设置一个节流的 3G 网络，以便进行更快的测试。

引入一周中最慢的一天。Facebook推出了周二 2G 计划，以提升对低速链接的能见度和灵敏度。（图片来源）

幸运地是，有许多很好的选项能够帮助你自动的收集数据，并根据这些指标来衡量在一段时间内你的网站的运行状况。请记住，良好的性能指标是被动和主动监测工具的组合：

• 被动监测工具，是那些模拟用户交互请求（综合测试，如Lighthouse，WebPageTest）和
• 那些不断记录和评价用户交互行为的主动监测工具（真正的用户监控，如 SpeedCurve，New Relic —— 这两种工具也提供综合测试）

前者是在开发过程当中特别有用，由于它能帮助你在产品开发过程当中持续跟踪。后者对于长期维护颇有用，由于它能帮助你了解用户在实际访问站点时的性能瓶颈。利用内置的 RUM API，如导航计时，资源计时，渲染计时，长任务等，被动和主动的性能监测工具能够一块儿为你的应用程序提供完整的性能视图。例如，你可使用PWMetrics，Calibre，SpeedCurve，mPulse，Boomerang 和 Sitespeed.io，这些都是性能监测工具的绝佳选择。

注意：选择网络级别的节流器（在浏览器外部）老是比较安全的，例如，DevTools 与 HTTP/2 推送的交互问题，是由于它的实现方式。（感谢 Yoav!）

Lighthouse一个集成在 DevTools 的性能检测工具。

5. 与你的同事分享性能清单。

为了不误解，要确保你团队里的每一个同事都对清单很熟悉。每一个决策都对性能有影响。项目将极大地受益于前端开发人员正确地将性能价值传达给整个团队。这样每一个人都会对它负责，而不只仅是前端开发人员。根据性能预算和核对表中定义的优先级映射设计决策。

RAIL，以用户为中心的性能模型。

制定现实的目标

6. 60 fps，100 毫秒的响应时间。

为了让交互感受起来很顺畅，接口有 100ms 来响应用户的输入。任何比它长的时间，用户都会认为该应用程序很慢。RAIL，一个以用户为中心的性能模型会为你提供健壮的目标。为了让页面达到小于 100ms 的响应，页面必需要在在每小于 50ms 前将控制返回到主线程。预计输入延迟时间会告诉咱们，若是咱们能达到这个门槛，在理想状况下，它应该低于 50ms。对于像动画这样的高压点，最好不要在你能作到的地方作任何事，也不要作你不能作到的事。

同时，每一帧动画应该要在 16 毫秒内完成，从而达到 60 帧每秒（1秒 ÷ 60 = 16.6 毫秒） —— 最好在 10 毫秒。由于浏览器须要时间将新框架绘制到屏幕上，你的代码应该在触发 16.6 毫秒的标志前完成。保持乐观和明智地利用空闲时间。显然，这些目标适用于运行时的性能，而不是加载性能。

7. 速度指标小于 1250，在 3G 网络环境下可交互时间小于 5s，重要文件的大小预算小于 170kb。

虽然这可能很难实现，但首次有效渲染要低于 1 秒和速度指标的值低于 1250 将会是一个很好的最终目标。考虑到是一个以 200 美金为基准的 Android 手机（如 Moto G4）在一个缓慢的 3G 网络上，模拟 400ms 的往返延时和 400kb 的传输速度。它的目标是可交互时间低于 5s，而且重复访问的速度低于 2s。

请注意，当谈到可交互时间时，最好来区分一下首次交互和一致性交互以免对它们之间的误解。前者是在主要内容已经渲染出来后最先出现的点（窗口至少须要 5s，页面才开始响应）。后者是指望页面能够一直进行输入响应的点。

HTML 的前 14~15kb 加载是是最关键的有效载荷块 —— 也是第一次往返（这是在400 ms 往返延时下 1秒内所获得的）预算中惟一能够交付的部分。通常来讲，为了实现上述目标，咱们必须在关键的文件大小内进行操做。最高预算 170 Kb gzip (0.8-1MB decompressed)（0.8-1MB解压缩），它已经占用多达 1s （取决于资源类型）来解析和在普通电话上进行编译。稍微高于这个值是能够的，可是要尽量地下降这些值。

不过你也能够超出包大小的预算。例如，你能够在浏览器主线程的活动中设置性能预算，即：在开始渲染前的绘制时间或者跟踪前端 CPU 。Calibre，SpeedCurve 和 Bundlesize 这些工具能够帮助你保持你的预算控制，并集成到你的构建过程。

原本就很快的：现代化加载的最佳实践 来自 Addy Osmani（幻灯片 19）

环境搭建

8. 选择和设置你的构建工具。

不要太在乎那些很酷的东西。坚持使用你的构建工具，不管是Grunt，Gulp，Webpack，Parcel，仍是工具间的组合。只须要你能快速的获得结果，而且维护你的构建过程保证没问题。那么，你就作的很好了。

9. 渐进式加强。

将渐进式加强做为前端结构体系和部署的指导原则是一个安全的选择。首先设计和构建核心经验，而后为有能力的浏览器使用高级特性加强体验，创造弹性体验。若是你的网站是在一个网络不佳的而且有个糟糕的显示屏上糟糕的浏览器上运行，速度还很快的话，那么，当它运行在一个快速网络下快速的浏览器的机器上，它只会运行得更快。

10. 选择一个强大的性能基准。

有这么多未知因素影响加载 —— 网络、热保护、缓存回收、第三方脚本、解析器阻塞模式、磁盘的读写、IPC jank、插件安装、CPU、硬件和内存限制、web 字体加载行为 —— JavaScript 的代价是最大的，web 字体阻塞渲染每每是默认和图片消耗了大量的内存所致使的。因为性能瓶颈从服务器端转移到客户端，做为开发人员，咱们必须更详细地考虑全部这些未知因素。

在 170kb 的预算中，已经包括了关键路径的 HTML/CSS/JavaScript、路由器、状态管理、实用程序、框架和应用程序逻辑，咱们必须完全检查网络传输成本，分析/编译时间和咱们选择的框架的运行时的成本。

原本就很快的：现代化加载的最佳实践来自 Addy Osmani(幻灯片1八、19)。

正如 Seb Markbage 所指出，测量框架的启动成本的好方法是首先渲染视图，再删除它，而后再渲染，由于它能够告诉你框架是如何处理的。

第一种渲染倾向于预热一堆编译迟缓的代码，当它扩展时，更大的树能够从中受益。第二种渲染基本上是对页面上的代码重用如何影响性能特性的模拟，由于页面愈来愈复杂。

并非每一个项目都须要框架。事实上，某些项目因移除已存在的框架而从中获益。一旦选择了一个框架，你将会至少与它相处几年。因此，若是你须要使用它，确保你的选择是通过深思熟虑的并且别人是知情的。在进行选择前，至少要考虑总大小的成本 + 初始解析时间：轻量级的选项像 Preact，Inferno，Vue，Svelte 或者 Polymer 均可以把工做作得很好。大小的基准将决定应用程序代码的约束。

JavaScript 解析成本可能有很大差别。原本就很快的: 现代化加载的最佳实践来自Addy Osmani (幻灯片 10)。

请记住，在移动设备上，与台式计算机相比，你会预计有 4x-5x 的减速。由于移动设备具备不一样的 GPU，CPU，内存及电池特性。在手机上的解析时间比桌面设备的要高 36%。因此总在一个普通的设备上测试 —— 一种最能表明你的观众的设备。

不一样的框架将会对性能产生不一样的影响，而且须要不一样的优化策略。所以，你必须清楚地了解你所依赖的框架的全部细节。PRPL 模式和应用程序 shell 体系结构。这个想法很简单: 将初始路由的交互所需的最小代码快速呈现，而后使用 service worker 进行缓存和预缓存资源，而后异步加载所需的路由。

PRPL 表明的是保持推送关键资源，渲染初始路由，预缓存剩余路由和延迟加载必要的剩余路由。

应用程序 shell 是最小的 HTML、CSS 和 JavaScript 驱动的用户界面。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。