一, HTTP 请求过程
一个 HTTP 请求的主要过程是:
DNS 解析(T1) -> 建立 TCP 连接(T2) -> 发送请求(T3) -> 等待服务器返回首字节(T4) -> 接受数据(T5)
查看一个 HTTP 完整请求时间可以在 chrome 控制台 network waterfall 上查看, 如下图
注: Queueing 阶段是请求在浏览器队列中的排队时间, 不计入 HTTP 请求时间.
二, 实验过程分析
1. 资源体积大的情况
理想情况, 随着资源体积变大, 两种加载方式所需时间趋于相同. 从理论上解释, 因为 HTTP 的传输通道是基于 TCP 链接的, 而 TCP 链接具有慢启动的特性, 刚开始时并没有充分利用网络带宽, 经过慢启动过程后, 逐渐占满可利用的带宽. 对于大资源, 带宽是瓶颈, 即使使用更多的 TCP 连接, 也不能带来速度的提升. 资源越大, 慢启动所占的下载时间的比例就越小, 绝大部分时间, 带宽都是被充分利用的, 总数据量相同, 带宽相同, 传输时间当然也相同.(拆分资源导致的额外 Header 在这种情况下完全可以忽略)
2. 资源体积小的情况
当资源体积很小的时候, 数据的下载时间占用的比例很小, 这个时候影响资源加载时间的关键就是 DNS 解析 (T1),TCP 连接建立(T2), 发送请求(T3) 和等待服务器返回首字节(TTFB)(T4). 同时建立多个 HTTP 连接本身就存在额外的资源消耗, 每个 HTTP 的 DNS 查询时间, TCP 连接的建立时间也存在一定的随机性, 这就导致并发资源请求时, 出现某个 HTTP 耗时明显增加的可能性变大. 这种情况下, 并发 HTTP 请求就会导致更大的时间不均匀性和不确定性, 表现结果就往往比使用一个 HTTP 请求加载合并后的资源慢.
但是小资源文件不一定是合并后加载更快. 因为如果文件合并后不能在 1 次网络往返中传输完成, 网络延时又长, 那么合并后耗时就不如并发加载了.
三, 资源大小影响拆分还是合并
对于大资源, 是否合并对于加载时间没有明显影响, 但拆分资源可以更好的利用浏览器缓存, 不会因为某个资源的更新导致所有缓存资源失效. 另外可以利用域名分片技术, 将资源拆分部署到不用域名下, 既可以分散服务器压力, 有可以降低网络抖动带来的影响.
对于小资源, 合并资源往往具有更快的加载速度, 但在网络状况良好的情况下, 因为提升的时间单位以 ms 计量, 收益可以忽略. 如果网络延迟很大, 服务器响应速度又慢, 则可以带来一定收益, 但高延迟的网络场景下, 又要注意合并资源后可能带来网络往返次数的增加, 进而影响到加载时间.
来源: http://www.qdfuns.com/article/46690/d66222c366fff8c20f98eb1e70191af2.html