屏幕在被认为是性能问题之前需要花费多长时间？

我参与了具有各种屏幕的Windows应用程序的开发。其中之一需要十秒钟才能显示，没有微调器或其他迹象表明屏幕正在加载。我认为这是一个严重的性能问题，但我似乎是唯一关心的问题。

我是不是太热心了？等待屏幕出现的可接受时间是多少？

这是一项古老的研究，但10秒很糟糕：

http://www.useit.com/papers/responsetime.html

从页面：

关于响应时间的基本建议已经有三十年了[Miller 1968; 卡德等。1991]：

•0.1秒是让用户感觉系统正在做出即时反应的极限，这意味着除了显示结果外，不需要任何特殊反馈。

•1.0秒是关于即使用户注意到延迟也不会中断用户思想流的极限。通常，在大于0.1秒但小于1.0秒的延迟期间，不需要特殊的反馈，但是用户确实会失去直接操作数据的感觉。

•10秒左右是使用户的注意力集中在对话上的极限。对于更长的延迟，用户将希望在等待计算机完成操作时执行其他任务，因此应向他们提供反馈，指示计算机预期何时完成。如果响应时间可能变化很大，则延迟期间的反馈尤为重要，因为用户将不知道会发生什么。

没有沙漏超过两秒钟，我已经很怀疑了。不同的人会有不同的期望，但是我希望没有任何反馈的10秒钟甚至会承认我单击了按钮或任何会使几乎任何人都烦恼的东西。惹恼用户是否重要是另一个问题。

此应用程序的目标用户有何想法？如果他们同意，那就不用担心。在某些必须处理大量数据的应用程序中，打开窗口的命令在打开之前会有一点延迟是可以的。

如果有可能添加一个启动画面或进度条或东西来表示用户，它的工作，将是不错的。如果我的测试显示一个窗口通常需要2-4秒以上的时间才能显示，我通常会尝试添加某种进度指示器。

我们坚持的原则是，任何反馈都不会超过2秒。

我说任何反馈都是因为有时无法在2秒钟内加载整个页面。您必须让用户知道头2秒后会发生什么。

尽管DKnight在他的回答中引用了很好的研究，但是要考虑的另一件事是系统的性能要求。用户是在做一些对时间敏感的工作，还是出于某种原因需要快速的要求？如果您能以某种方式询问用户他们希望看到的响应时间，特别是在最小可接受时间方面，那将是最好的。进行观察性的可用性测试对于整体可用性也是有益的，并且如果您看到用户在执行特定操作后因等待而感到沮丧，那么您就知道要重新查看系统那部分的性能。

但是，就一般性而言，我怀疑10秒的确是很长的时间。有一些长时间运行的操作，如果确实如此，则向用户提供系统仍在工作并继续等待的提示很重要。

我同意10秒肯定是太多了。我在Software House（仅供员工内部使用）中处理Intranet应用程序，加载页面时的最大延迟为5秒。对我来说这是极限。

但是，我看到了其他内部应用程序，的确非常复杂，但是加载时间却很戏剧化。在最坏的情况下，由于执行了大量记录/查询，因此大约需要2分钟！但这当然与一般情况相距太远。

因此，我可以得出结论，说3到4秒是提供良好响应服务的极限。

这样不是性能问题，而是GUI问题。应该告诉用户程序的工作，如果花费的时间超过1-2秒，则应显示进度条。

这就是说，有可能是一个原因，如果使用要快，但是这不是你问什么。

此类应用程序的典型问题是物理内存不足，因此磁盘I / O成为加载和交换的瓶颈。也可能仅仅是因为数据集变得如此之大，以至于O（N ^ 3）算法现在可以照亮了。