我坚持使用一些代码来测量处理时间(或至少在我编写的代码中发生的部分),我通常会看到50-150ms范围内的值,这看起来非常高.我很想知道我应该把重点放在哪个方面,或者我对这个应用程序的整个方法是否太慢而且我应该放弃并尝试更简单的方法. (根据Firebug的Net选项卡,我不测量的处理部分通常会增加不到5毫秒,因为我正在同一台计算机上同时测试客户端和服务器.)
仅供参考我使用的是Werkzeug和SQLAlchemy / Elixir.我知道那些不是最有效的技术,但我真的只关心足够快,而不是尽可能快.
编辑:只是为了澄清,我上面引用的50-150ms是纯服务器端处理时间,仅适用于HTML页面本身.用户看到的页面加载所需的实际时间至少高出200ms(因此,总共250-350ms)因为CSS / JS /图像的访问时间(尽管我知道可以通过正确使用缓存和Expires头,精灵等,这是我将在不久的将来做的事情).网络延迟会在此基础上增加更多时间,因此我们可能会谈论总客户端加载时间为500毫秒.
更好的是,这是一个典型示例的Firebug网络选项卡的屏幕截图:
Loading times from Firebug http://www.ellipsix.net/ext-tmp/loadtimes.png
这是我要问的顶部74ms.
现在,我想强调三点.
>一切都取决于具体情况.如果加载需要几秒钟,那么将非常频繁访问的主页或页面会很多.另一方面,如果优化成本昂贵,网站中一些很少使用的部分可能需要一秒钟.
>用户主要关心的是快速完成他们想要的东西.这不是访问单个页面所花费的时间,而是访问信息或完成目标的时间.这意味着最好让一个页面花费250毫秒而不是要求用户一个接一个地访问三个页面来执行相同的操作,每个页面需要150毫秒才能加载.
>注意感知的加载时间.例如,Stack Overflow网站上有一个有趣的技巧.当做一些基于AJAX的事情时,比如上/下投票,首先你会看到效果,然后请求服务器.例如,尝试对您自己的消息进行投票.它会显示消息已经过投票(箭头将变为橙色),然后,200毫秒后,箭头将变为灰色并显示错误框.因此,在向上投票的情况下,当执行请求所花费的实际加载时间为100毫秒时,感知的加载时间(箭头变为橙色)为1毫秒.
编辑:200毫秒也没关系.如果频繁访问页面或者用户希望页面快速(例如,预计AJAX请求很快),500毫秒可能会有点伤害.顺便说一下,我在截图中看到你正在使用几个CSS文件和十个PNG图像.通过combining CSS到一个文件并使用CSS sprites,您可以减少感知的加载时间,尤其是在处理网络延迟时.