声明：如有翻译不得当之处，还请指出，原文链接：Response Times: The 3 Important Limits，谢谢。
摘自《Usability Engineering》第五章（1993年）
关于响应时间最基本的建议这30年来都不曾变过（1968 ~ 1991）：
0.1秒：让用户感觉到系统在即时响应的界限，这意味着除了显示结果外，不需要专门的反馈。
1.0秒是让用户思绪保持连续的界限，虽然用户能够感觉到延迟。正常情况下，不需要对0.1秒~1.0秒的延迟做特别的反馈，但用户会失去直接操作数据的流畅感。
10秒：让用户的注意力集中在对话上。如果延迟比这还要长，用户就想要在等待期间执行其它任务了，所以必须在任务完成时给出反馈提示。延迟期间的反馈非常重要，因为如果响应时间可能会大幅度波动的话，用户就不知道该做什么了。
正常情况下，响应时间应该尽可能的快，但是也有可能出现计算机响应速度快到用户反应不过来的情况。例如，滚动列表可以滚动得非常快，导致用户没办法在目标元素出现在可视区域中时把它停下来。实际上计算机在表现UI变化时可以非常快，比如动画是根据时钟时间来计时的，而不是按计算机的执行速度计时：即使普及了一种更快的计算机，UI也应该保持其可用性。
如果计算机不能即时响应，就应该以百分比完成度指示器（Myers 1985）的形式给用户提供连续反馈。百分比完成进度指示器应该用在时耗超过10秒的操作上，这是一条黄金准则。进度指示器有三大优点：它们打消了用户对系统是崩溃了还是正在进行任务的疑虑；适时指出用户需要等待的时间；以便用户在长时间等待中去做别的事情；它们还提供了视觉反馈（用户至少可以看到等待提示），让无聊的等待时间稍微好过点。可不能小看最后一个优点，这就是推荐用图形化进度条代替用数字表示的剩余时间的原因。
对于那些无法提前预知时耗的操作来说，不可能用百分比完成度指示器，但还可能根据完成任务的绝对时间来提供运行进度反馈。例如，系统检索数量未知的远程数据库并输出每个数据库的名字的操作过程。如果也不行，那么最后一招是用个不太具体的进度指示器，比如一个旋转的球、一只忙碌的小蜜蜂在屏幕上飞来飞去、状态栏上的点点，或者其它能够反映出系统正在工作的机制，即使不能表现出正在做什么也没关系。添在这篇文章的web版上的笔记：大多数web浏览器都没能提供有用的进度条，因为他们不显示整个页面下载完成的百分比。
对于相当快的操作来说，时耗2到10秒，用百分比指示器就显得小题大做了，实际上，显示进度条违背了显示惯性（屏幕上闪出的变化太快会让用户无法平静或者感到压力）原则。还可以给出不太明显的进度反馈，有个通用的方案是用“繁忙”光标形状结合屏幕底部一小块区域中快速变化的数字来表示完成了多少。
另见：
关于website response times和如何提升响应时间的文章
基于web的应用程序的响应时间
2014年更新，又遇到了这样的问题，所以我决定在这儿回答。
Q: “你多次提及响应时间很重要，而且有很多工具都可以测量响应时间，但基于web的应用响应时间是多少才算可以接受？如果不说购物体验，只针对交互应用的话，用户的容忍（上限）是多少？”
A: 我希望”基于web的应用程序”这个词彻底消失，因为它扰乱了应用UI设计（我们有好几天的课程都是关于这个话题的）中的一个实际问题。没有专门针对C++或者JavaScript实现的应用的指导原则。基本的可用性建议都一样，与实现无关，因为我们讨论的是用户体验，不是编码。
因此，基于web的应用的响应时间指导原则和所有其它应用的一样，这些指导原则到现在已经46年了，所以他们也不太可能因为新技术的出现而发生变化。
0.1秒：用户直接操作UI中的对象的感觉极限。比如，从用户选择表格的一列到该列高亮或向用户反馈已被选择的时间间隔。理想情况下，它也是对列进行排序的响应时间——这种情况下用户会感到他们正在给表格排序。
1秒：用户随意地在计算机指令空间进行操作而无需过度等待的感觉极限。0.2-1.0秒的延迟意味着会被用户注意到，因此感觉到计算机出于对指令的“处理中”，这有别于直接响应用户行为的指令，例如：如果根据被选择的列对表格进行排序，无法再0.1秒内完成，那么必须在1秒内完成，否则用户将感觉到UI变得缓慢且在执行任务中失去“流畅”（flow）的体验。超过1秒的延迟要提示用户计算机正在解决这个问题，例如改变光标的形状。
10秒：用户专注于任务的极限。超过10秒的任何操作都需要一个表粉笔完成指示器，以及一个方便用户中断操作且有清晰标识的方法。假设用户遭遇超过10秒延迟后才返回到原UI的情况，他们将需要重新适应。在用户的工作中，超过10秒的延迟仅仅在自然中断时可以接受，比如切换任务时。
