WEB性能优化

写在前面

   Web性能优化是一个近年来新兴的一个产业，该发展迅速主要取决于企业越来越重视用户体验。用户也越来越重视速度方面的体验，很多企业证实网站越快，用户的黏性，忠诚度，转化率才会越来越高。

   对web性能的优化主要就是优化其速度，而要优化速度就要研究影响速度提升的各种因素。对于速度来讲，对其有影响的无外乎带宽与延迟。

延迟 ：分组从信息源发送到目的地所需的时间。

带宽 ：逻辑或物理通信路径最大的吞吐量。

页面加载时间与带宽和延迟的关系

  曾有人对互联网上最热门的一些站点的页面加载时间和带宽与延迟做过一些测试，结果如下图：

页面加载时间与带宽和延迟的关系

  在第一个测试中，连接的延迟时间固定而带宽递增，从 1 Mbit/s 依次递增至 10Mbit/s。注意一开始，从 1 Mbit/s 升级到 2 Mbit/s，页面加载时间几乎减少了一半，这也是我们希望看到的结果。可是，在此之后，带宽递增，加载时间减少得越来越不明显。而当带宽超过 5 Mbit/s 时，加载时间的减少比例只有几个百分点，从 5Mbit/s 升级到 10 Mbit/s，页面加载时间仅降低了 5%。

由此可知，靠提高带宽不会给用户浏览网页带来多大的性能提升。或许用户下载大文件、看视频的速度很快，但加载包含这些文件的页面的时间不会明显缩短。换句话说，增加带宽没有那么重要。然而，在延迟以 20 ms 递减的试验中，页面加载时间呈线性减少趋势。

  当我们的带宽提高已不能快速提升站点性能时，就应该围绕延迟这一因素来对其进行优化。我们无法掌握用户与服务器端的网络状况，和用户手持怎样高级或者怎样烂的一个终端设备来访问我们的站点，但是除此之外的一切都应该是我们所能够操控的。OSI协议模型的有七层结构，每一层都会有一些不必要的延迟产生，让我们对这七层的每一层都做到滴水不漏的优化显然是不可能的。但是努力追求去做到对每一层的优化显然是值得的。

  对于通信信道来讲，其物理属性显然是一个比较硬性的限制，在无法打破光速这个‘天道极限速度’时，只有缩短其数据传输的距离了。

  既然不能让数据跑的更快，那么只能去优化其传输层与应用层。我们可以去消除不必要的往返，请求。缩短传输距离—把数据放置在最后一公里。

对性能优化的建议

  说到底，无论什么网络或者网络协议版本，所有应用都应该致力于消除或者减少不必要的网络延迟，将其需要传输的数据压缩至最少。这两条标准才是最为经典的性能优化建议。

对其优化前人已总结有十条优化准则：

1 减少DNS查找

   每一次主机名解析都需要一次网络往返，从而增加请求的延迟时间，同时还会阻塞后续请求。

2 重用TCP连接

   尽可能使用持久连接，以消除 TCP 握手和慢启动延迟；

3 减少HTTP重定向

   HTTP 重定向极费时间，特别是不同域名之间的重定向，更加费时；这里面既有额外的 DNS 查询、TCP 握手，还有其他延迟。最佳的重定向次数为零。

4 使用 CDN（内容分发网络）

   把数据放到离用户地理位置更近的地方，可以显著减少每次 TCP 连接的网络延迟，增大吞吐量。这一条既适用于静态内容，也适用于动态内容；

5 去掉不必要的资源

   任何请求都不如没有请求快。说到这，所有建议都无需解释。延迟是瓶颈，最快的速度莫过于什么也不传输。然而，HTTP 也提供了很多额外的机制，比如缓存和压缩，还有与其版本对应的一些性能技巧。

6 在客户端缓存资源

  应该缓存应用资源，从而避免每次请求都发送相同的内容。

7 传输压缩过的内容

  传输前应该压缩应用资源，把要传输的字节减至最少：确保每种要传输的资源采用最好的压缩手段。

8 消除不必要的请求开销

  减少请求的 HTTP 首部数据（比如 HTTP cookie），节省的时间相当于几次往返的延迟时间。

9 并行处理请求和响应

  请求和响应的排队都会导致延迟，无论是客户端还是服务器端。这一点经常被忽视，但却会无谓地导致很长延迟。

10 针对协议版本采取优化措施

  HTTP 1.x 支持有限的并行机制，要求打包资源、跨域分散资源，等等。相对而言，HTTP 2.0 只要建立一个连接就能实现最优性能，同时无需针对 HTTP 1.x 的那些优化方法。