今天趁着下班的时间看了下chrome浏览器的网页加载时间分析工具和相关文档，简单写点儿东西记录一下。
以百度首页加载为例，分析下一张图片1.jgp（就是背景图）的加载时间
看右侧的Timing标签，从下往上看各个阶段：
最下面一行，Explanation是一个链接，它链接到了chrome对Timing解释的文档(从这里可以看出chrome对开发人员真的很友好)，这张图片加载总共花费的时间为：36.32ms。
Content Download，浏览器下载响应文件所花费的时间26.84ms，与本地网络有关系。
Waiting(TTFB)，从发起请求到接收到服务器响应的首个字节所花费的时间，它的主要组成部分：服务器响应和网络传输（往返）。
Request sent. The request is being sent. 表示请求正在发出，这个是不占用时间的。
Stalled。The request could be stalled for any of the reasons described in Queueing. 请求会因为各种原因的排队被拖延，与请求队列有关系。这张图片的请求被拖延了1.48ms。
Queueing(排队). The browser queues requests when: 浏览器会在以下情况下将某个请求排队：
- There are higher priority requests. 有更高优先级的请求
- There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only. 在http1.0/1.1协议下，chrome对于同一域名下的并发请求数（连接数）限制为6个。这么做的原因：（1）是基于端口数量和线程切换开销的考虑，浏览器不可能无限量的并发请求：由于 TCP 协议的限制，PC 端只有65536个端口可用以向外部发出连接，而操作系统对半开连接数也有限制以保护操作系统的 TCP\IP 协议栈资源不被迅速耗尽，因此浏览器不好发出太多的 TCP 连接，而是采取用完了之后再重复利用 TCP 连接或者干脆重新建立 TCP 连接的方法。如果采用阻塞的套接字模型来建立连接，同时发出多个连接会导致浏览器不得不多开几个线程，而线程有时候算不得是轻量级资源，毕竟做一次上下文切换开销不小。（2）为了防止过多的并发导致服务器崩溃，这是“有良知的tcp客户端”对于服务器的一种默契。详见：浏览器允许的并发请求资源数是什么意思？
- The browser is briefly allocating space in the disk cache 浏览器正在硬盘的缓存上分配空间。
对于某个请求我们能够优化的主要是TTFB，即，从发起请求到收到服务器响应的时间间隔。从图中也可以看出，它耗费的时间所占的比例也比较大。那么也就主要从服务器响应和网络传输这两方面来下手。如果只考虑网络传输这个因素，那么压缩传输数据，毕竟网络速度有限，减少传送的数据字节数可以加快传输速度。