从一道面试题开始
面试中聊到性能测试、聊到响应时间，有没有被这样的问题给考住？
“你刚才说页面响应时间大于1秒钟，就是性能不好，这个1秒钟是怎么来的？为什么不是10秒钟或者500毫秒”
其实这个看似不起眼，常常是由拍脑袋拍出来的阈值，是性能测试的“第一性”问题，非常值得聊一聊。
性能指标通常分两类，一类是响应时间，一类是资源消耗（比如cpu占用，内存占用），今天我们主要来探讨下，前端页面的响应时间究竟多少才合理。
先来看看谷歌的做法
其实用户判断慢和卡的标准，来自于人类视觉和心理的局限。所以，以下的数据适用于前端web页面（浏览器里展示的那种页面），但思考方式适用于任何带图形界面的场景。（比如安卓/iOS APP，比如你加小朋友的小天才手表）
谷歌的做法-RAIL模型
谷歌把用户对web网页的操作归纳为以下4种场景
结合用户对不同场景下不同的性能预期，制定了如下的标准
场景
合理范围
备注
响应(Response)
50毫秒内处理事件
这里主要是指，提交给主线程的task要在50毫秒内处理完。否则主线程一直阻塞，就无法及时响应用户操作了。
动画(Animation)
10毫秒内生成一帧
fps=60要求16毫秒绘制一帧，这里留了buffer
动画不仅仅指视觉动画、还包括滚动操作、拖动操作等
空闲(idle)
最大限度的延长空闲时间
这里的空闲不是让用户界面闲着不动的意思，是指要让主线程尽量保持空闲，这样才能随时响应用户对界面的操作。
加载(load)
5秒内提供内容并实现交互
这里真的是指用户界面层面了，5秒钟网页还加载不出来还不能交互，就太慢了。
谷歌的依据又是什么
谷歌在描述RAIL模型时提到，上边的时间数据参考了雅各布尼尔森团队（Jakob Nielsen）的人机交互研究成果
1993年Jakob Nielsen在它的文章《Response Times: The 3 Important Limits》中，提到了3个阈值，他说
关于响应时间的基本建议三十年来一直都是一样的 [Miller 1968; Card et al. 1991]：
0.1秒大概是让用户感觉到系统瞬间反应的极限，也就是说除了显示结果之外，不需要任何特殊的反馈。
1.0 秒大概是用户思维不被打断的极限，尽管用户会察觉到延迟。一般来说，延迟超过 0.1 秒但少于 1.0 秒时不需要特别的反馈，但用户确实会失去直接操作数据的感觉。
10 秒是让用户将注意力集中在对话上的极限。对于较长的延迟，用户会希望在等待计算机完成时执行其他任务，因此应向他们提供反馈，表明计算机预计何时完成。如果响应时间可能变化很大，则延迟期间的反馈尤其重要，因为用户将不知道会发生什么。
谷歌在此基础上，增加了0～16毫秒这个时间范围，并制成下表。
所以，现在你知道，开头的那道面试题该怎么答了吧？
说句题外话
去Jakob Nielsen的官网看下，你会感叹，我们常挂在嘴上的所谓“点点点”（用户体验）也能搞出一堆成果，其实大多数情况下都不是工作没有技术含量，让我们套用斯坦尼斯拉夫斯基的那句名言结束这篇文章，“没有小角色，只有小演员”