### 响应:在 100 毫秒以内响应
在用户注意到滞后之前您有 100 毫秒的时间可以响应用户输入。这适用于大多数输入,不管他们是在点击按钮、切换表单控件还是启动动画。但不适用于触摸拖动或滚动。 如果您未响应,操作与反应之间的连接就会中断。用户会注意到。 尽管很明显应立即响应用户的操作,但这并不总是正确的做法。使用此 100 毫秒窗口执行其他开销大的工作,但需要谨慎,以免妨碍用户。如果可能,请在后台执行工作。 对于需要超过 500 毫秒才能完成的操作,请始终提供反馈机制,比如loading,进度条等。
### 动画:在 10 毫秒内生成一帧
动画不只是奇特的 UI 效果。例如,滚动和触摸拖动就是动画类型。 如果动画帧率发生变化,您的用户确实会注意到。您的目标就是每秒生成 60 帧,每一帧必须完成以下所有步骤:

从纯粹的数学角度而言,每帧的预算约为 16 毫秒(1000 毫秒 / 60 帧 = 16.66 毫秒/帧)。 但因为浏览器需要花费时间将新帧绘制到屏幕上,只有 10 毫秒来执行代码。 在像动画一样的高压点中,关键是不论能不能做,什么都不要做,做最少的工作。 如果可能,请利用 100 毫秒响应预先计算开销大的工作,这样您就可以尽可能增加实现 60fps 的可能性。 如需了解详细信息,请参阅[渲染性能](https://developers.google.com/web/fundamentals/performance/rendering/?hl=zh-cn)。
### 空闲:最大程度增加空闲时间
利用空闲时间完成推迟的工作。例如,尽可能减少预加载数据,以便您的应用快速加载,并利用空闲时间加载剩余数据。 推迟的工作应分成每个耗时约 50 毫秒的多个块。如果用户开始交互,优先级最高的事项是响应用户。

要实现小于 100 毫秒的响应,应用必须在每 50 毫秒内将控制权返回给主线程,这样应用就可以执行其像素管道、对用户输入作出反应,等等。以 50 毫秒块工作既可以完成任务,又能确保及时的响应。
### 加载:在 1000 毫秒以内呈现内容
在 1 秒钟内加载您的网站。否则,用户的注意力会分散,他们处理任务的感觉会中断。侧重于[优化关键渲染路径](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/?hl=zh-cn)以取消阻止渲染。 实际操作中,我们无需在 1 秒内加载所有内容以产生完整加载的感觉,而是启用渐进式渲染和在后台执行一些工作,默认只加载和渲染首屏内容,将非首屏、非必需的加载推迟到空闲时间段处理。
- 第1章 介绍
- 01 介绍与基础要求
- 02 章节内容介绍
- 第2章 性能体验评判模型
- 03 RAIL 评估模型介绍
- 04 RAIL评估模型解析
- 05 加载性能指标
- 06 稳定性和操作体验指标
- 07 Performance High Resolution Time API
- 08 Performance Navigation Timing API
- 09 Performance User Timing API
- 10 Performance Resource Timing 和 Timeline API
- 11 Performance Timing 参数介绍和 FID 指标
- 12 性能和体验指标计算
- 13 页面性能指标数据采集架构
- 第3章 前端网页加载链路优化
- 14 静态资源链路优化
- 15 资源加载过程优化
- 16 浏览器解析渲染过程优化
- 17 Memory/Client/Http/Net/WebViewCache 方案介绍
- 18 Memory/Client/Http/Net/WebViewCache 应用实例
- 19 数据埋点反馈优化和常用软件
- 第4章 前端极致性能体验编码优化
- 20 优化策略和首屏渲染 PRPL 方案
- 21 LazyLoad 懒加载策略与组件案例
- 22 滚动加载分页组件案例
- 23 web worker 思路与方案案例
- 24 task 拆分原理和方案
- 25 代码分割与打包优化
- 26 前端项目架构优化思路与 ES6 原生模块架构案例
- 27 web components 和轻 React 、Vue 和微前端架构思想
