性能优化模型

时间 2020-02-22

原文原文链接

引子

在 About Performance 的最后提供了一些关注的点，但感受比较零散，有没有理论体系化的思想做为依据，经过查找资料，发现了两种指导方式：RAIL Model 和 PRPL Pattern ，下面是带有我的理解的部分翻译。git

翻译时 RAIL Model 原文 Last updated 2019-02-12 ，PRPL Pattern 原文 Last updated: Nov 5, 2018 。github

RAIL Model

RAIL 是一个以用户为中心的性能模型，它将用户的体验分解为关键的操做。RAIL 的目标和方针旨在帮助开发人员和设计人员确保每个操做都有良好的用户体验。经过设计一个考虑性能的结构，RAIL 使设计人员和开发人员可以有效的关注影响用户体验最大的工做。web

每一个 web 应用程序的生命周期都有四个不一样的方面，性能以不一样的方式适合它们：浏览器

目标和方针

在 RAIL 的上下文中，目标（goals）和方针（guidelines）有特殊的含义：缓存

目标：用户体验相关的关键性能指标。由于人类的感知是相对稳定的，因此这些目标不太可能很快改变。
方针：帮助你实现目标的建议。这些多是特定于当前的硬件和网络链接条件，所以可能随着时间发生改变。

关注用户

让用户成为你的性能工做的焦点。下表描述了用户如何感知性能延迟的关键指标：安全

延迟时间	用户反应
0 - 16ms	人们特别擅长跟踪运动，若是动画不流畅，他们就会对运动心生反感。用户能够感知每秒渲染 60 帧的平滑动画转场。也就是每帧 16ms（包括浏览器将新帧绘制到屏幕上所需的时间），留给应用大约 10ms 的时间来生成一帧。
0 - 100ms	在此时间窗口内响应用户操做，他们会以为获取的结果是当即的。时间再长，操做与反应之间的联系就会中断。
100 - 300ms	用户会体验到轻微的可感知延迟。
300 - 1000ms	在此窗口内，延迟感受像是一个连续任务天然进展的一部分。对于网络上的大多数用户，加载页面或更改视图表明着一个任务。
1000+ms	超过 1s ，用户对正在执行的任务失去注意力。
10,000+ms	用户感到失望，可能会放弃任务，以后他们或许不会再回来。

用户对性能延迟的感知不一样，这取决于网络条件和硬件。例如，经过快速 Wi-Fi 链接在功能强大的台式机上，1000ms 内的加载体验是合理的，所以用户已经习惯了 1000ms 的加载体验。但低于 3G 链接速度较慢的移动设备来讲，5000ms 内的加载体验是一个更实际的目标，所以移动用户一般更耐心。网络

Response：在 50ms 内处理事件

目标

在 100ms 内完成由用户输入启动的过分。用户花费大部分时间是在等待站点响应他们的输入，而不是等待站点加载。app

方针

在 50ms 内处理用户输入事件，是为了保证 100ms 内有可见的响应，不然动做与反应的联系就会断开。这适用于大多数输入，例如单击按钮、切换表单控件或启动动画。这不适用于触摸拖动或滚动。
尽管这听起来可能有违直觉，但对用户输入作出当即响应并不老是正确的。你能够用这个 100ms 的窗口作其它昂贵的工做。但要注意不要阻塞用户，若是可能的话，在后台工做。
对于须要超过 50ms 才能完成的操做，始终提供反馈。

50ms 仍是 100ms ?

目标是在 100ms 内响应输入，那么为何咱们的预算只有 50ms ？这是由于除了输入处理以外，一般还有其它的工做正在处理，而这部分工做占据了可接受输入响应的部分时间。若是应用程序在空闲时间以建议的 50ms 执行工做，这意味着若是在其中一个工做块期间发生输入，则输入的排列等候能够长达 50ms。根据这一点，假设只有剩余 50ms 可用于实际的输入处理是安全的。此效果在下图中可见，显示了在空闲任务队列中，输入是如何接受的，从而缩短了可用的处理时间：ide

Animation：10ms 内生成一帧

目标

在10ms 或更短的时间内生成动画中的每一帧。技术上，每帧的最大预算是 16ms（1000ms / 60帧/s ≈ 16ms），可是浏览器须要大约 6ms 来渲染每一个帧，所以每帧指导方针是 10ms 。
以视觉平滑度为目标。当帧速率变化时，用户会注意到。

方针

在像动画这样的高压点中，关键是不论能不能作，什么都不要作，作最少的工做。若是可能，利用 100ms 响应预先计算开销大的工做，这样你就能够尽量增长实现 60fps 的可能性。
查看 Rendering Performance 中动画优化策略。
识别全部类型的动画。动画不只仅是精致的 UI 效果。这些交互都被视为动画：
- 视觉动画，例如进入、退出、补间和加载提示。
- 滚动，包括抛掷，也就是用户开始滚动，而后放开，页面继续滚动。
- 拖拽，动画一般遵循用户交互，如平移地图或捏缩放。

Idle：最大化空闲时间

目标

最大化空闲时间以增长页面在 50ms 内响应用户输入的可能性。工具

方针

利用空闲时间完成延迟的工做。例如，对于初始页面加载，加载尽量少的数据，而后使用空闲时间加载其他的数据。
在 50ms 或更短的空闲时间内执行工做。再长一点，你就有可能干扰应用程序在 50ms 内响应用户输入的能力。
若是用户在空闲时间工做期间与页面交互，则用户交互应始终具备最高优先级并中断空闲时间工做。

Load：传送内容并在 5s 内具有可交互性

当页面加载缓慢时，用户的注意力就会转移，用户会认为任务已经中断。快速加载的站点具备更长的平均会话时间、更低的跳出率和更高的广告可视性。

目标

快速加载性能的优化与用户用于访问站点的设备和网络功能相关。目前，一个好的目标是，第一次加载的页面，在 5s 或更短的时间内在3G链接速度较慢的中档移动设备上具有可交互性。见 Can You Afford It?: Real-world Web Performance Budgets 。但要注意这些目标可能会随着时间的推移而改变。
对于后续加载，一个好的目标是在 2s 内加载页面。但这个目标也可能随着时间的推移而改变。

方针

在用户之间常见的移动设备和网络链接上测试加载性能。若是您的企业有关于用户使用的设备和网络链接的信息，则可使用该组合并设置本身的加载性能目标。不然，能够参考 The Mobile Economy 中的年度数据，选择合适的目标。
请记住，尽管你的典型移动用户可能声称它的设备是在 2G、3G 或 4G 链接上，但实际上，因为数据包丢失和网络变化，有效链接速度一般要慢得多。
专一于优化 Critical Rendering Path 。
没有必要在 5 秒内加载全部的东西，以产生一种完整加载的感受。启用渐进式渲染并在后台执行某些操做。将非必要加载推迟到空闲时间段。
识别影响页面加载性能的因素：
- 网络速度和延迟
- 硬件（例如 CPU 速度慢）
- 缓存回收
- 二级/三级缓存的差别
- JavaScript 解析

PRPL Pattern

PRPL 描述了一种模式，用于使网页更快的加载并变得可交互：

Push（或者 preload）最重要的资源。
尽快渲染（Render）初始路径。
预缓存（Pre-cache）剩余资源.
延迟加载（Lazy load）其余路由和非关键资源。

Apply instant loading with the PRPL pattern 中主要结合了一种工具进行讲解，偏重实际操做，这里就很少介绍了。