Web应用程序的适当页面处理时间是多少？

Question

我正在开发一个Web应用程序，它已经到了我已经拥有大部分必要功能的地步，我开始担心执行速度。所以我做了一些寻找信息，我发现了很多关于通过缩小CSS / JS，设置缓存控制头，使用单独的域用于静态文件，压缩输出等（以及基本服务器）来减少页面加载时间的问题。像memcached这样的技术）。但是，假设我已经优化了所有这些，我关心的是我的Web应用程序生成一个页面实际需要多长时间，即没有缓存命中的纯服务器端处理时间。显然，将时间缩短的技巧将取决于我使用的语言和基础库，但目标是什么是合理的数字？为了进行比较，我对使用现有框架构建的应用程序的处理时间的实际示例感兴趣，执行访问数据库和渲染模板等典型事务。

我坚持使用一些代码来测量处理时间（或者至少是我编写的代码中发生的那部分），我通常会看到50-150ms范围内的值，这看起来相当高。我很想知道我应该把重点放在哪个方面，或者我对这个应用程序的整个方法是否太慢而且我应该放弃并尝试更简单的方法。 （根据Firebug的Net选项卡，我不测量的处理部分通常会增加不到5毫秒，因为我在同一台计算机上同时测试客户端和服务器。）

仅供参考我使用Werkzeug和SQLAlchemy / Elixir在Python中工作。我知道那些不是最有效的技术，但我真的只关心足够快，而不是尽可能快。

编辑：为了澄清一下，上面引用的50-150ms是纯服务器端处理时间，只是用于HTML页面本身。用户看到的页面加载所需的实际时间至少为200毫秒更高（因此，总共250-350毫秒），因为CSS / JS /图像的访问时间（尽管我知道可以通过正确使用缓存和Expires标题，精灵等来改进，这是我将在不久的将来做的事情）。网络延迟会增加更多时间，因此我们可能会谈论总客户端加载时间为500毫秒。

更好的是，这是一个典型示例的Firebug Net选项卡的屏幕截图： Loading times from Firebug http://www.ellipsix.net/ext-tmp/loadtimes.png 这是我要问的顶部74ms。

Answer 1

恕我直言，在大多数情况下，服务器端客户端50-150毫秒都可以。当我衡量一些非常知名的网站的速度时，我很少看到一些快速的东西。大多数情况下，它大约250毫秒，通常更高。

现在，我想强调三点。

1. 一切都取决于具体情况。如果加载需要几秒钟，那么将非常频繁访问的主页或页面会很多。另一方面，如果优化成本很高，网站上一些很少使用的部分可能需要一秒钟。

2. 用户主要关心的是快速完成他们想要的事情。这不是访问单个页面所花费的时间，而是访问信息或实现目标的时间。这意味着最好让一个页面花费250毫秒而不是要求用户一个接一个地访问三个页面来执行相同的操作，每个页面需要150毫秒才能加载。

3. 注意感知的加载时间。例如，Stack Overflow网站上有一个有趣的技巧。当做一些基于AJAX的事情，比如上/下投票，首先你看到效果，然后请求服务器。例如，尝试对您自己的消息进行投票。它将显示消息已经过投票（箭头将变为橙色），然后，200毫秒后，箭头将变为灰色并显示错误框。因此，在向上投票的情况下，当执行请求所花费的实际加载时间为100毫秒时，感知的加载时间（箭头变为橙色）为1毫秒。

编辑： 200毫秒也没关系。如果频繁访问页面或者用户期望页面快速（例如，AJAX请求预期快），500 ms可能会有点伤害。顺便说一下，我在截图中看到你正在使用几个CSS文件和十个PNG图像。通过combining CSS到一个文件并使用CSS sprites，您可以减少感知的加载时间，尤其是在处理网络延迟时。

Answer 2

着名的可用性发言人雅各布·尼尔森几天后发表了一篇文章[1]。他建议在不到1秒的时间内完成交易，100毫秒以下是完美的，因为它会中断用户流程。

正如其他用户指出的那样，它取决于该页面的上下文。如果有人上传文件，他们预计会有延迟。如果他们登录并且需要十秒钟，他们就会开始感到沮丧。

[1] http://www.useit.com/alertbox/response-times.html

Answer 3

当我编写并针对Web服务运行一系列性能测试时，我查看了一些旧的JMeter结果。我将在下面附上一些，当然不是苹果对苹果，而是至少另一个数据点。

时间以毫秒为单位。 Location Req和Map Req的固有延迟分别为15000和3000毫秒。 Invite包括快速拨打移动运营商的ldap服务器。其他人非常标准，主要是数据库读/写。

sampler_label    count    average    min    max
Data Blurp       2750     185        30     2528 
UserAuth         2750     255        41     2025
Get User Acc     820      148        29     2627
Update User Acc  4        243        41     2312
List Invitations 9630     345        47     3966
Invite           2750     591        102    4095
ListBuddies      5500     344        52     3901
Block Buddy      403      419        79     1835
Accept invite    2065     517        94     3043
Remove Buddy     296      411        83     1942
Location Req     2749     16963      15369  20517
Map Req          2747     3397       3116   5926

该软件运行在一个专用的，不错的虚拟机上，与生产虚拟机的调整方式相同。 max结果很慢，我的目标是找到我们可以支持的并发用户数，以便我推动它。

我认为你的号码绝对可以。关于使网站看起来很慢的所有其他内容，如果还没有，请查看YSlow。它与Firebug很好地集成，并提供有关如何加快页面加载的很好的信息。

Answer 4

50-150ms的页面加载时间很好 - 此时您无需进一步优化。

事实是，只要你的页面在一秒钟内加载，你就可以了。

参见this article，其中讨论了转换加载时间的影响（对于亚马逊来说，增加了100毫秒= 1％）。