响应时间指标的探索

最近又看到响应时间的一些讨论，就顺着这个响应时间的一些资料整理了如下内容

1968年

目前能够追溯的最早定义响应时间的文章应该是Rober B.Miller于1968年在AFIPS '68 (Fall, part I): Proceedings of the December 9-11, 1968, fall joint computer conference, part I论文集中的论文《Response time in man-computer conversational transactions》。文中Miller将响应时间分为几个主要的Topic：

• 1 响应控制激活（Response to control activation）：这涉及到用户操作（如按键、开关）的即时反馈，通常不超过0.1秒。
• 2 系统是否在听（Response to "System, are you listening?"）：用户期望系统能够快速响应其输入，通常在激活ON开关后一秒钟内得到响应信号，如电话的拨号音。
• 3 系统能否工作（Response to "System, can you do work for me?"）：用户在提交特定服务请求后，期望系统能够快速确认是否能够执行该工作，通常在两秒内。
• 4 理解我了吗（Response to "System, do you understand me?"）：如果用户输入了一段信息，系统应在用户完成输入后两到四秒内给出错误提示或确认，以免打断用户的思路。
• 5 识别响应（Response to Identification）：用户通过身份验证（如插入卡片）后，期望系统能够快速确认其身份，通常在两秒内。
• 6 下一步工作是什么（Response to "Here I am, what work should I do next?"）：用户完成一项任务后，期望系统能够快速提供下一个任务指示，通常在10到15秒内。
• 7 简单询问列表信息（Response to simple inquiry of listed information）：用户对现有记录的简单查询，期望系统能够迅速提供信息，通常在两秒内。
• 8 简单询问状态（Response to simple inquiry of status）：用户询问特定对象的状态信息，系统可能需要一些时间来处理和搜索，但用户期望的响应时间通常在七到十秒内。
• 9 复杂询问表格形式（Response to complex inquiry in tabular form）：用户需要系统基于逻辑关系收集和显示数据，这种复杂查询的响应时间应在四秒内完成。
• 10 请求下一页（Response to request for next page）：用户在阅读文本时请求下一页，期望系统能够迅速提供，通常不超过一秒。

这些主题涵盖了人机交互中不同场景下的响应实践需求，这也同样揭示了在人机交互过程中的心理预期。也对响应时间做了粒度很细微的划分。这篇发表于1968年的论文为后面持续研究响应时间奠定了基础。

1991年

到1991年，Stuart K.Card, George G.Robertson, Jock D.Mckinlay,在CHI '91: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems论文集发表了《The information visualizer, an information workspace》文中定义了Immediate response time contant（立即响应实践常数），描述如下“人可以在大约一秒钟内对某些刺激做出未经准备的反应。如果超过一秒钟，那么听者会做出后通道反应以表明他们在听（例如，“嗯哼”），或者说话者会做出反应（例如，“嗯...”）以表明他仍在思考下一句话。这些行为使互动双方保持参与感。在认知协处理器中，我们尝试让代理在不超过这个时间常数的间隔内提供状态反馈。立即响应动画（例如，将3D树的分支摆动到视野中）被设计为大约需要一秒钟。如果时间更短，用户将失去对象的恒常性，需要重新定位自己。如果时间更长，用户则会因为等待响应而感到无聊。”这段描述强调了在用户界面设计中，对于用户操作的响应时间的重要性，以及如何通过设计来满足人的即时反应需求。以下是一些与这个时间常数相关的评价和考量：

• 用户体验（User Experience）：如果系统响应时间超过一秒，用户可能会开始感到等待的不耐烦，这会降低用户体验。因此，保持在一秒内的响应时间可以提高用户满意度。
• 认知负荷（Cognitive Load）：响应时间过长可能会导致用户的认知负荷增加，因为他们需要记住更多的信息或者维持注意力在等待响应的任务上，这可能会影响他们处理其他信息的能力。
• 交互流畅性（Interaction Fluidity）：在一秒内提供响应有助于保持交互的流畅性，使得用户可以连续地进行操作而不需要频繁地暂停等待。
• 任务完成时间（Task Completion Time）：快速响应可以减少完成任务所需的总时间，提高工作效率。
• 错误和中断（Errors and Interruptions）：如果响应时间过长，用户可能会在等待期间被打断或分心，这可能导致错误或任务中断。
• 系统设计（System Design）：设计者需要考虑到系统的响应时间，以确保它符合人类的认知和感知限制。这可能涉及到优化算法、提高计算效率或者设计更直观的用户界面。
• 技术限制（Technical Limitations）：在某些情况下，技术限制可能使得实现一秒内的响应时间变得困难。在这些情况下，设计者需要找到平衡，通过其他方式（如提供即时反馈）来补偿技术限制。
• 适应性（Adaptability）：用户可能需要时间来适应新的交互系统。如果系统响应时间一致且符合用户的预期（如一秒内），用户可能会更快地适应并有效使用系统。

这些评价和考量说明了为什么在设计用户界面和交互系统时，考虑人类的时间和认知限制是如此重要。通过遵守这些时间常数，设计者可以创建出更直观、更有效且用户友好的系统。

1993年

接下来就是在1993年Jakob Nielsen发表的《Response Times: The 3 Important Limits》文章访问地址https://www.nngroup.com/articles/response-times-3-important-limits，将响应时间按照不同延迟阈值下用户的心理感受和行为变化分成了三个阶段：

• 0.1秒的响应时间限制：这是用户感觉到系统反应“即时”的极限。在这个时间范围内，用户几乎感觉不到任何延迟，因此不需要特别的反馈，只需要显示结果即可。这种即时性对于保持用户的沉浸感和流畅的交互体验至关重要。
• 1.0秒的响应时间限制：这是用户思考流程不被打断的极限。尽管用户会注意到这个延迟，但通常不需要特别的反馈，除非延迟超过0.1秒但小于1.0秒。在这个时间范围内，用户开始感觉到与系统的直接操作感有所减弱，但思考流程仍能保持连贯。
• 10秒的响应时间限制：这是保持用户注意力集中在对话上的极限。超过10秒的延迟，用户可能会开始寻求执行其他任务，因为他们不知道计算机何时能完成操作。因此，系统应该提供反馈，告知用户预计何时能完成。如果响应时间可能有很大的变化，那么在延迟期间提供反馈尤为重要，因为用户将无法预测接下来会发生什么。

这些阈值强调了在设计人机交互系统时，响应时间的重要性以及对用户体验的影响。

2020年及其以后

2020年6月10日Google最后更新了《使用 RAIL 模型衡量性能》文章，https://web.dev/articles/rail?hl=zh-cn。文章提出了RAIL模型衡量以用户为中心的性能。

让用户成为性能工作的中心。建立了用户对性能延迟的感知：

• 0 至 16 毫秒：用户非常擅长跟踪运动，如果动画不流畅，他们就会不喜欢。只要每秒渲染 60 帧，这类动画就会感觉很流畅。也就是每帧 16 毫秒（包括浏览器将新帧绘制到屏幕上所需的时间），让应用生成一帧大约 10 毫秒。
• 0 至 100 毫秒：在此时间范围内响应用户操作，让用户感觉能够立竿见影。时间再长，操作与反应之间的连接就会中断。
• 100 至 1000 毫秒：在此窗口中，事情感觉像是任务自然和持续推进的一部分。对于网络上的大多数用户，加载页面或更改视图代表着一个任务。
• 1000 毫秒或以上：一旦超过 1,000 毫秒（1 秒），用户就会失去专注于他们正在执行的任务的注意力。
• 10000 毫秒或更长：一旦超过 10,000 毫秒（10 秒），用户就会感到沮丧，并可能放弃任务。他们以后不一定会回来。

并建立了一些准测：

• 响应：在 50 毫秒内处理事件
• 动画：在 10 毫秒内生成一帧
• 空闲：最大限度地延长空闲时间
• 加载：提交内容并在 5 秒内实现互动