performance - 对于不可接受的 webapp 响应时间，是否有一些行业标准？

Question

有一个我正在定制的婴儿床（商业现成的）应用程序，其中几个页面需要很长时间才能加载某些数据分布。（在这种情况下，页面加载大约需要 3 分钟......而且时间呈指数增长）。

显然这是不可接受的，但是否有研究表明我可以指出可接受的响应时间是多少？

我想要一些很好的研究，可能会讨论响应时间。

score 60 · Accepted Answer

Jakob Nielsen 的研究已经为任何应用程序回答了这个问题（网络应用程序在这方面并不特别）：

因此，对于 Web 应用程序，您应该将页面响应时间平均保持在服务器附近最大 500 毫秒，以拥有一个即使网络延迟为 200-300 毫秒也能愉快使用的 Web 应用程序。

score 13 · Accepted Answer

可接受的 UI 响应时间基于人类心理，因此对于 Web 应用程序与对于传统桌面应用程序的响应时间相同。

根据最终用户如何感知正在执行的操作，可接受的响应时间可能是 1 秒（例如，用于关闭“对话窗口”）或 10 秒（例如，用于显示计算结果）。

可用性专家 Jakob Nielsen 写了一篇关于可接受的 Web 应用程序响应时间的好文章。

已发布的 UI 指南指定了相同的可接受响应时间，例如：

score 2 · Accepted Answer

是的，尼尔森的文章有一些关于心理学如何参与的很好的信息。在这里，您可以找到有关“感知性能”为何重要的更多信息，而不仅仅是实际响应时间。

score 0 · Accepted Answer

我发布了一个相关问题，并得到了一些可能会有所帮助的有趣答案。看

score 0 · Accepted Answer

不久前，一位教授告诉我，普通用户在等待 10 秒后就放弃了，什么也没发生。看到某事发生可能会增加他们等待的倾向。但那是很久以前的事了……当时互联网速度较慢。

score 0 · Accepted Answer

这里有一篇不错的博客文章，认为确实没有行业标准。

也许没有什么好的方法可以做到这一点。

score 0 · Accepted Answer

这个问题的答案集中在 UI 行为上，其中许多假设网络响应时间和 UI 响应性之间总是存在硬联系。

虽然这在 11 年前发布最后一个答案时可能是正确的，但如今实现 Web 页面的策略已经发展，最佳实践意味着许多 XHR 调用独立于使页面立即对用户有价值。

我怀疑即使是这些答案中的人类心理部分也随着时间的推移而发生了变化——人们现在通常对网页有更高的期望和更低的耐心门槛。

score 0 · Accepted Answer

Python请求

这可能更多地出现在服务器端，并且没有考虑到匹配的前端，但我仍然将此文档作为我的指导方针。

连接超时是请求将等待您的客户端在套接字上建立与远程机器的连接（对应于connect()）调用的秒数。最好将连接超时设置为略大于3 的倍数，这是默认的 TCP 数据包重传窗口。

从这些文档

(2.1) 在对发送方和接收方之间发送的段进行往返时间 (RTT) 测量之前，发送方应设置 RTO <- 3秒（根据 RFC 1122 [Bra89]），尽管“退避” （5.5）中讨论的重复重传仍然适用。

请注意，某些实现可能会使用“心跳”计时器，该计时器实际上会产生 2.5 秒到 3 秒之间的值。因此，2.5 秒的下限也是可以接受的，前提是计时器的到期时间永远不会超过 2.5 秒。使用粒度为 G 的心跳计时器的实现不应将计时器设置为低于 2.5 + G 秒。

score -4 · Accepted Answer

∞ 是最不可接受的响应时间。

之后，用户期望花费的最长时间，这取决于您的服务。

动画区域将极大地增加用户的耐心，无论是沙漏、漩涡、圆圈，甚至是一个不断填满和清空自身的条形。只要问题显然不是他们的行动没有被听到，他们就会等待。