web性能优化——使用RAIL模型评估性能

RAIL 简介

RAIL 是一种以用户为中心的性能模型。每一个网络应用均具备与其生命周期有关的四个不一样方面，且这些方面以不一样的方式影响着性能：

RAIL核心思想是以用户为中心；最终目标不是让您的网站在任何特定设备上都能运行很快，而是使用户满意。主要包含如下几个方面：

• 当即响应用户；在 100 毫秒之内确认用户输入。
• 设置动画或滚动时，在 10 毫秒之内生成帧。
• 最大程度增长主线程的空闲时间。
• 持续吸引用户；在 1000 毫秒之内呈现交互内容。

以用户为中心

让用户成为您的性能工做的中心。用户花在网站上的大多数时间不是等待加载，而是在使用时等待响应。下表是用户时间与用户反应的关系：

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

响应：在 100 毫秒之内响应

在用户注意到滞后以前您有 100 毫秒的时间能够响应用户输入。这适用于大多数输入，无论他们是在点击按钮、切换表单控件仍是启动动画。但不适用于触摸拖动或滚动。

若是您未响应，操做与反应之间的链接就会中断。用户会注意到。

尽管很明显应当即响应用户的操做，但这并不老是正确的作法。使用此 100 毫秒窗口执行其余开销大的工做，但须要谨慎，以避免妨碍用户。若是可能，请在后台执行工做。

对于须要超过 500 毫秒才能完成的操做，请始终提供反馈。

动画：在 10 毫秒内生成一帧

若是动画帧率发生变化，您的用户确实会注意到。您的目标就是每秒生成 60 帧，每一帧必须完成如下全部步骤：

从纯粹的数学角度而言，每帧的预算约为 16 毫秒（1000 毫秒 / 60 帧 = 16.66 毫秒/帧）。 但由于浏览器须要花费时间将新帧绘制到屏幕上，只有 10 毫秒来执行代码。

在像动画同样的高压点中，关键是不论能不能作，什么都不要作，作最少的工做。 若是可能，请利用 100 毫秒响应预先计算开销大的工做，这样您就能够尽量增长实现 60fps 的可能性。
如需了解详细信息，请参阅渲染性能。

空闲：最大程度增长空闲时间

利用空闲时间完成推迟的工做。例如，尽量减小预加载数据，以便您的应用快速加载，并利用空闲时间加载剩余数据。

推迟的工做应分红每一个耗时约 50 毫秒的多个块。若是用户开始交互，优先级最高的事项是响应用户。

要实现小于 100 毫秒的响应，应用必须在每 50 毫秒内将控制返回给主线程，这样应用就能够执行其像素管道、对用户输入做出反应，等等。

以 50 毫秒块工做既能够完成任务，又能确保即时的响应。

加载：在 1000 毫秒之内呈现内容

在 1 秒钟内加载您的网站。不然，用户的注意力会分散，他们处理任务的感受会中断。

侧重于优化关键渲染路径以取消阻止渲染。

关键 RAIL 指标汇总

要根据 RAIL 指标评估您的网站，请使用 Chrome DevTools Timeline 工具记录用户操做。而后根据这些关键 RAIL 指标检查 Timeline 中的记录时间。

RAIL 步骤	关键指标	用户操做
响应	输入延迟时间（从点按到绘制）小于 100 毫秒。	用户点按按钮（例如打开导航）。
动画	每一个帧的工做（从 JS 到绘制）完成时间小于 16 毫秒。	用户滚动页面，拖动手指（例如，打开菜单）或看到动画。 拖动时，应用的响应与手指位置有关（例如，拉动刷新、滑动轮播）。 此指标仅适用于拖动的持续阶段，不适用于开始阶段。
空闲	主线程 JS 工做分红不大于 50 毫秒的块。	用户没有与页面交互，但主线程应足够用于处理下一个用户输入。
加载	页面能够在 1000 毫秒内就绪。	用户加载页面并看到关键路径内容。