● 服务器花在处理客户请求上的时间。
● 网络花在传输请求和响应上的时间
● 客户花在组装并显示结果内容上的时间。
当然，实际情形远比这要复杂，原因下面分别进行介绍。
服务发现
开始访问任何网站时，客户都需要先找到服务器。通常这是由DNS查询完成的，尽管客户可能已经缓存了服务器的IP地址。有时候可能需要多走几步才能找到正确的服务器，像HTTP重定向这种操作，就会把客户引向另外的地方。
什么时候客户需要从新的服务器获取内容，都要经历这种服务发现过程。结果，对于带有很多组件的网站一这是一个日渐普遍的模式一一都会迫使客户去解析很多网站，并且页面的加载时间也延长了。
现代的网站都依赖于第三方组件提供诸如支付、嵌入式视频、到社会媒体的链接、监控等的功能。然而，每个附加组件都是一个令人担心的失效点，并且也是导致页面加载延迟的罪魁，硬生生地剥夺了高效网站的优势。
发送请求
网络再快，客户与服务器之间的往返也是需要时间的，部分原因是物理学上的限制:光从纽约到拉斯维加斯需要13毫秒，那么数据从纽约到拉斯维加斯就不可能比13毫秒更快从浏览器到内容之间的网络速度是导致延迟的首要因素。
Web请求可能会很简单: GET index.html，然而，更为常见的却是很复杂的请求，包括cookies、URI参数，甚至还有 POSTS上载内容的操作。请求包含的内容越多，则网络用来传输的时间就越长。假如是一个安全页面的话，还会有另外的延迟，用来在客户与服务器之间进行加密协商。
再考虑响应
请求到达服务器的以后，另一个导致延迟的罪魁就登场了:主机。不论是从内存中检索静态对象，还是利用后台的第三方服务来完成一个复杂的请求，主机延迟都会对性能造成影响。关于后台服务造成的延迟，本书其他章节有讨论，这里就不多说了。主机延迟是造成糟糕用户体验的主要原因，所以，除了在后台对其进行测量之外，在网站之外对其进行追踪也是非常重要的。
记住，假如网站依赖于第三方组件，则也要对这些外部网站的主机延迟进行测量，而且还可以针对这些提供商起草一份服务水平协议(SLAs)，确保他们的网站能够满足你的延迟标准。
发送响应
响应内容一旦准备就绪，服务器就可以通过HTTP协议发送这些请求对象，正是这些对对象的发送造成了访客体验到的延迟。
虽然看起来似乎是带宽一一给定时段内客户与服务器之间传送的数据量一一对页面延迟负有责任，事实上，页面中的对象数量以及这些对象从何而来，通常决定着页面加载所花费的时间。
Web页面极少只包含一个对象，对于大多数页面，容器对象(page. html)包含有对组件对象( Image.gif、 video.mo、audio.Wav、movie.Swf)的引引用，从而，这些对象也要抽取过来。而浏览器对于在同时能够检索多少对象上也是有限制的。所以，页面加载所用时间，是对象数量、对象大小、同时能够检索的对象数量、可用带宽的综合作用。
异步通信与刷新
某些应用包括一些客户与服务器之间的通信，这些通信是独立于页面进行的，我们在拖拽Google Mapl时就会观察到这一点，此日时的背景拼贴就是独立进行的，或者在你输入搜索条目时，输人框下面也会出现可供你选择的建议列表。这些异步通信模式在Web2.0风格的网站上日渐普遍。
包含某种异步更新或刷新的应用，有不同的延迟测量指标。我们不能再用“页面加载时间”了，因为此时流向浏览器的是持续的更新流。取而代之的是，我们对“每秒消息数”或“刷新时间”这样的指标进行测量，其中，“刷新时间”表示的是从用户做某件事情(在键盘上输入一个字符，拖动地图)到内容得到刷新(建议列表被刷新，地图被重绘)之间的延迟。
渲染时间
随着客户端越来越复杂，浏览器做的也越来越多。有可能是启动高互联网应用(RIA)，这些RIAs都是构建在 Flash、Flex、HTML5、Java、Javascript以.及 Silverlight之上的，也可能是运行诸如 Quick Time及 Windows媒体播放器等这样的插件，甚至决定如何对复杂页面进行布局也是需要花费时间的。所以，对于大量依赖客户端进行渲染的网站，就必须考虑这种延迟。
好消息是，在构建网站建设客户端时，可以在其中包含代码，对延迟进行测量，然后将数据送回给你，这样就可以了解，对终端用户而言，你的应用到底怎么样。
本文地址：//www.qlpinke.com//article/3343.html
