5

我正在开发一个 web 应用程序，它已经到了我拥有大部分必要功能的地步，我开始担心执行速度。所以我四处寻找信息，我发现了很多关于通过缩小 CSS/JS、设置缓存控制标头、为静态文件使用单独的域、压缩输出等来减少页面加载时间的方法（以及基本的服务器 - memcached 等辅助技术）。但是假设我已经优化了这一切，我关心的是我的 Web 应用程序实际生成页面需要多长时间，即没有缓存命中的纯服务器端处理时间。显然，减少时间的技巧将取决于我使用的语言和底层库，但合理的目标是多少？为了比较，我

我坚持使用一点代码来测量处理时间（或者至少是我编写的代码中发生的部分时间），我通常看到的值在 50-150ms 范围内，这似乎相当高。我很想知道我应该在多大程度上专注于降低它，或者我对这个应用程序的整个方法是否太慢，我应该放弃它并尝试一些更简单的东西。（基于 Firebug 的 Net 选项卡，考虑到我在同一台计算机上同时使用客户端和服务器进行测试，我未测量的处理部分通常增加不到 5 毫秒。）

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

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

更好的是，这里是 Firebug 的 Net 选项卡中的一个典型示例的屏幕截图： 从 Firebug 加载时间 我要询问的是顶部的 74 毫秒。

4

4 回答 4

5

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

现在，我想强调三点。

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

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

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

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

于 2010-06-24T09:22:05.640 回答
2

几天前，著名的可用性演讲者 Jakob Nielsen 发表了一篇文章 [1]。他建议在 1 秒内完成交易，在 100 毫秒以下是完美的，因为它会更多地中断用户流程。

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

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

于 2010-06-24T09:38:19.840 回答
1

当我针对 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 很好地集成，并提供了有关如何使页面加载更快的重要信息。

于 2010-06-24T09:19:36.583 回答
0

页面加载时间为 50-150 毫秒就可以了——此时您不需要进一步优化。

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

请参阅这篇文章，其中讨论了加载时间对转换的影响（亚马逊增加 100 毫秒 = 1%）。

于 2010-06-24T09:12:27.923 回答