【发布时间】：2010-05-10 01:57:18
【问题描述】：
您认为 Web 脚本（例如 PHP）在开始对用户造成困扰之前执行的最长时间是可以接受的（平均而言）？我一直认为如果用户必须等待超过 1 秒才能加载页面（这当然是在图像和 css 被缓存之后..这条规则实际上只适用于后续请求）他们会开始生气。
【问题讨论】：
标签： php asp.net dynamic usability
【发布时间】：2010-05-10 01:57:18
【问题描述】：
42 秒。
实际上，这更多地取决于您要迎合的用户的年龄和期望。例如，我的父母可能更能容忍长时间的等待，但也更有可能一次又一次地按下按钮，就像他们按下人行横道或电梯按钮一样。
也就是说，真正的答案是，对于用户来说，没有反馈多久才算太久？即使启动一个快速的沙漏标志或进度条，也可以为用户带来世界上的一切。也就是说，如果您提供的服务应该是实时的并且像桌面应用程序一样运行，那么太长基本上是“任何可感知的”。
所以，逃避回答......这取决于。也就是说，即使是“太长”的等待，也可以通过适当的 UI 设计和客户交互来克服。
【讨论】：
-
+1 以获得反馈。复杂的事情总是需要很长时间（如果不是，它们就不会复杂），但让用户感到沮丧的是缺乏反馈（我的电脑“什么都不做”的感觉）
Jacob Nielsen 做了一些research on this.
- 0.1 秒 大约是让用户感觉到系统在瞬间做出反应的极限，这意味着除了显示结果之外不需要特殊的反馈。
- 1.0 秒 大约是用户思想流保持不间断的极限，即使用户会注意到延迟。正常情况下，超过0.1秒但小于1.0秒的延迟是不需要特殊反馈的，但用户确实会失去直接对数据进行操作的感觉。
- 10 秒 大约是让用户的注意力集中在对话上的极限。对于较长的延迟，用户将希望在等待计算机完成时执行其他任务，因此应向他们提供反馈，指示计算机预计何时完成。如果响应时间可能变化很大，则延迟期间的反馈尤其重要，因为用户将不知道会发生什么。
作为灵感，您可以查看 NetBeans 社区 interpret these values：
- 0.1 秒 - 导航和编辑操作（例如文件夹扩展、在编辑器中粘贴、在编辑器中导航）以及所有菜单栏的绘制必须在此限制内完成
- 1.0 秒 - 所有窗口和对话框的打开都必须在此限制内完成
- 10 秒 - 所有在 1 秒后完成且通常花费不到 10 秒的操作必须显示某种忙碌指示（例如沙漏光标或“请稍候...”文本）;使用 Progress API 提供进度条的所有操作都需要花费超过此限制的时间
【讨论】：
default limit 的 PHP 脚本执行时间为 30 秒。如果您只是从用户的角度询问，那么经验法则是越快越好...
【讨论】：
处理时间超过几秒钟的任何事情都应该以不同的方式处理，这里有一些示例
- 缓存其输出服务器端
- 运行执行处理的 Cron 作业
- 使用
system()使用 PHP 生成一个虚假进程
【讨论】：
看看这个链接：
http://www.simple-talk.com/dotnet/.net-tools/the-cost-of-poor-website-performance/
然后只需确定您的用户可以达到的沮丧程度。
【讨论】：
我的经验法则：
在平均情况下将服务器端处理时间保持在 1 秒以内，在最坏情况下绝对保持在 30 秒以内。
【讨论】：
我会说几秒钟，然后您应该致电 (PHP)ob_flush() 并至少向客户端发送一些东西。否则电梯效果会接管，用户会反复刷新。至于总页面加载，只要您保持用户发布就没有关系。进度条将对此有所帮助。
【讨论】：
久经考验的真正策略始终是管理期望。不要让用户第二次猜测您或您的应用程序。如果根据您的基准，特定页面的平均处理时间将超过 6 秒阈值，请在用户单击按钮之前说明。这很像等待网站向您发送确认电子邮件，却不知道它何时会到达，因为从未提及由于网站无法控制的流量可能需要几个小时。
【讨论】：
根据我的经验，如果某些事情需要超过几秒钟的时间，您至少应该给用户一些通知。可能将 AJAX 与一些花哨的动画一起使用，并注意“这将需要一段时间”。
如果您不能使用 AJAX，并且您的 PHP 脚本加载时间超过 10 秒，请尝试考虑优化它的方法。
【讨论】：