0 至 16 毫秒
用户非常关注轨迹运动，他们不喜欢不流畅的动画。如果每秒渲染 60 个新帧，他们就认为动画很流畅。也就是说，每一帧只有 16 毫秒时间，这包括浏览器将新帧绘制到屏幕所需的时间，因而应用约有 10 毫秒的时间来生成一个帧。在动画之类对计算速度要求极高的场景下，关键在于即使可行，您也不能执行任何其他操作，让不能执行的操作保持绝对最少。只要可能，您就要利用这 10 毫秒的响应时间预先计算最消耗资源的工作，从而最大限度地提高达到 60 fps 的几率。
0 到 100 毫秒
在此时间窗口内响应用户操作会让用户觉得结果是即时呈现的。如果时间更长，操作与用户反应之间的联系就会中断。为了确保在 100 毫秒内产生可见响应，需要在 50 毫秒内处理用户输入事件。这适用于大多数输入，例如点击按钮、切换表单控件或启动动画。但是，这不适用于触摸拖动或滚动。对于需要 50 毫秒以上才能完成的操作，请随时提供反馈。尽管听起来可能有些自相矛盾，但是，即时响应用户输入并非总是正确的做法。您可以利用这 100 毫秒的时间窗口来执行其他需要消耗大量资源的工作，但是，注意不能妨碍用户。如果可能，应在后台工作。目标是在 100 毫秒内响应输入，那么，为什么我们的预算只有 50 毫秒？这是因为除输入处理外，通常还有需要执行其他工作，而且这些工作会占用可接受输入响应的部分可用时间。如果应用程序在空闲时间以推荐的 50 毫秒区块执行工作，这就意味着，如果输入在这些工作区块之一中发生，它最多可能会排队 50 毫秒。考虑到这一点，假设只有剩余的 50 毫秒可用于实际输入处理才是安全地做法。
100 到 1000 毫秒
在此时间窗口内，用户会觉得任务进展基本上是自然连续的。对 Web 上的大多数用户来说，加载页面或更改视图是一项任务超过 1000 毫秒（1 秒），用户的注意力就会从正在执行的任务上转移，超过 10000 毫秒（10 秒），用户会感到失望，并且可能放弃任务。他们以后可能会回来，也可能不会再回来。用户对性能延迟的感知有所不同，具体取决于网络条件和硬件。例如，通过快速 Wi-Fi 连接，在功能强大的台式机上加载站点时，通常只需不到 1 秒时间，用户已经习以为常。通过速度较慢的 3G 网络连接，在移动设备上加载站点则需要更长的时间，因此，移动用户通常会更有耐心。在移动设备上，5 秒钟内完成加载是更现实的目标。最大限度增加空闲时间以提高页面在 50 毫秒内响应用户输入的几率，利用空闲时间完成延缓的工作。例如，对于初始页面加载，应加载尽可能少的数据，然后利用空闲时间加载其余数据，在 50 毫秒或更短的空闲时间内执行工作。如果时间更长，您可能会干扰应用在 50 毫秒内响应用户输入的能力，如果用户在空闲时间工作期间与页面交互，则应中断空闲时间工作，用户交互始终具有最高优先级
