使用 RAIL 模型评估前端性能 [每日前端夜话(0x09)]
RAIL 是一种以用户为中心的性能模型。每个网络应用均具有与其生命周期有关的四个不同方面，且这些方面以不同的方式影响着性能：
内容提要：
- 以用户为中心；最终目标不是让你的网站在任何特定设备上都能运行很快，而是使用户满意。
立即响应用户；在 100 毫秒以内确认用户输入。
设置动画或滚动时，在 10 毫秒以内生成帧。
最大程度增加主线程的空闲时间。
- 持续吸引用户；在 1000 毫秒以内呈现交互内容。
以用户为中心
让用户成为你的性能工作的中心。用户花在网站上的大多数时间不是等待加载，而是在使用时等待响应。了解用户如何评价性能延迟：
响应：在 100 毫秒以内响应
在用户注意到滞后之前你有 100 毫秒的时间可以响应用户输入。这适用于大多数输入，不管他们是在点击按钮、切换表单控件还是启动动画。但不适用于触摸拖动或滚动。
如果你未响应，操作与反应之间的连接就会中断。用户会注意到。
尽管很明显应立即响应用户的操作，但这并不总是正确的做法。使用此 100 毫秒窗口执行其他开销大的工作，但需要谨慎，以免妨碍用户。如果可能，请在后台执行工作。
对于需要超过 500 毫秒才能完成的操作，请始终提供反馈。
动画：在 10 毫秒内生成一帧
动画不只是奇特的 UI 效果。例如，滚动和触摸拖动就是动画类型。
如果动画帧率发生变化，你的用户确实会注意到。你的目标就是每秒生成 60 帧，每一帧必须完成以下所有步骤：
从纯粹的数学角度而言，每帧的预算约为 16 毫秒（1000 毫秒 / 60 帧 = 16.66 毫秒/帧）。 但因为浏览器需要花费时间将新帧绘制到屏幕上，只有 10 毫秒来执行代码。
在像动画一样的高压点中，关键是不论能不能做，什么都不要做，做最少的工作。 如果可能，请利用 100 毫秒响应预先计算开销大的工作，这样你就可以尽可能增加实现 60fps 的可能性。
空闲：最大程度增加空闲时间
利用空闲时间完成推迟的工作。例如，尽可能减少预加载数据，以便你的应用快速加载，并利用空闲时间加载剩余数据。
推迟的工作应分成每个耗时约 50 毫秒的多个块。如果用户开始交互，优先级最高的事项是响应用户。
要实现小于 100 毫秒的响应，应用必须在每 50 毫秒内将控制返回给主线程，这样应用就可以执行其像素管道、对用户输入作出反应，等等。
以 50 毫秒块工作既可以完成任务，又能确保即时的响应。
加载：在 1000 毫秒以内呈现内容
在 1 秒钟内加载你的网站。否则，用户的注意力会分散，他们处理任务的感觉会中断。
侧重于优化关键渲染路径以取消阻止渲染。
你无需在 1 秒内加载所有内容以产生完整加载的感觉。启用渐进式渲染和在后台执行一些工作。将非必需的加载推迟到空闲时间段（请参阅此网站性能优化 Udacity 课程，了解更多信息）。
要根据 RAIL 指标评估你的网站，可以使用 Chrome DevTools Timeline 工具记录用户操作。然后根据这些关键 RAIL 指标检查 Timeline 中的记录时间。
©著作权归作者所有：来自51CTO博客作者mb5ff980b461ced的原创作品，如需转载，请注明出处，否则将追究法律责任更多相关文章
- Chrome将内置原生的懒加载功能
- 关于PHP框架中.env文件的加载过程
- php如何按需加载方式来增加程序的灵活度
- php+javascript实现用户注册模块（附源码）
- 基于PHP微信网页获取用户信息的实例分析
- 分享php+redis实现对200w用户的即时推送服务
- 原生 PHP 实现支付宝 App 第三方登录获取用户信息
- php加载不出图片