前言
还记得年初刚来的时候，有人问我要不要接卡顿，又有人跟我说别接啊很难的这个，页面都卡没了不好定位。 去年机缘巧合，卡顿这个事情又到我头上了，同事调侃说性能这个事情接手的都跑路了。 但问题不大，咱没事不惹事，来事不怕事，遇事能抗事。
像腾讯云监控产品RUM（前端性能监控）、APM（终端性能监控）等大型产品，代码复杂，前端页面繁琐，卡顿本身难以监测，即使检测到卡顿的发生，也常常难以快速定位，更别提说想要了解大盘的用户真实体验。
需求产生，便总会要研究解决方案的。
卡顿的定义
理解卡顿之前，我们先了解几个概念：
1、 Google RAIL模型
RAIL 表示 Web 应用生命周期的四个不同方面：响应（Response）、动画（Animation）、空闲（Idel）和加载（Load）。由于用户对每种情境有不同的性能预期，因此，系统会根据情境以及关于用户如何看待延迟的用户体验调研来确定效果目标。
人机交互学术研究由来已久，在 Jakob Nielsen’s work on response time limits 中提出三个阈值：
100 毫秒：大概是让用户感觉系统立即做出反应的极限，这意味着除了显示结果之外不需要特殊的反馈
1 秒：大概是用户思想流保持不间断的极限，即使用户会注意到延迟。一般情况下，大于0.1秒小于1.0秒的延迟不需要特殊反馈，但用户确实失去了直接操作数据的感觉
10 秒：大概是让用户的注意力集中在对话上的极限。对于较长的延迟，用户会希望在等待计算机完成的同时执行其他任务，因此应该向他们提供反馈，指示计算机预计何时完成。如果响应时间可能变化很大，则延迟期间的反馈尤其重要，因为用户将不知道会发生什么。
在此基础上，如今机器性能都有大幅度的提升，因此基于用户的体验，RAIL 增加了一项：
0-16 ms：大概是用户感受到流畅的动画体验的数值。只要每秒渲染 60 帧，这类动画就会感觉很流畅，也就是每帧 16 毫秒（包括浏览器将新帧绘制到屏幕上所需的时间），让应用生成一帧大约 10 毫秒
由于这篇文章我们讨论的是长任务相关，因此主要考虑生命周期中的响应（Response），目标便是要求 100 毫秒内获得可见响应。
###
