Web性能的几个常见瓶颈
转自51cto的微信推送
http://mp.weixin.qq.com/s?__biz=MjM5MDI5MjAyMA==&mid=402654298&idx=2&sn=f2620081eb328abe942e8ef902c8b73b&scene=23&srcid=0328SK5GXpRVAv63Ob9aJ30d#rd
Web性能的几个常见瓶颈
当前，许多站点的部署方式都对自身的性能产生了消极影响，而网站的所有者并没有意识到这个问题。我们今天针对性的讨论以下几个常见的影响网站性能的瓶颈，观察其变化趋势，并简单说明一些解决方案来提升网站的性能。
瓶颈一：缓存
在面对静态内容的时候，我们最常用的方式就是通过将其缓存在浏览器、中间代理服务器或者CDN之上。因为能够提供相当大的卸载，这种将静态内容的缓存行为毫无疑问将对终端用户和源站服务器产生良好的影响。根据当前的趋势，我们可以看到，许多站点实际上都在缓存类似于JS，图像，CSS等对象；但是，我们却发现能够对HTML进行缓存的站点却并不多见。基础页面一般是比较动态化的，大部分的网站所有者都不会对这种页面进行缓存，因为HTML页面是在不断变化的。我们对尽可能多的网站数据进行了评估，结果如下：
根据上图，我们可以看到：34%的独立站点对HTML页面进行了缓存。66%的独立站点没有对HTML页面进行缓存。
分析：
我们发现，大量站点没有缓存基础页面，这将对站点的Speed Index（速度参数）造成直接影响。Speed Index能够反映视觉元素的平均完成程度，也是提升客户体验的一个重要方面。
如果页面包含了动态的内容，那么我们可以采取几种方式来确保其可缓存性，或者对动态内容进行潜在复用。
解决方法：利用低TTL对基础页面进行缓存——如果这样做，我们就能为内容提供一个较低的TTL，然后根据最终用户所在位置等不同变量进行变化，减少HTML请求次数进而卸载源站的负载。
异步JavaScript及XML（Ajax）——利用Ajax来动态地创建多页面组件，这使我们可以对多种存储进行缓存响应，包括session storage和local storage。可缓存的Ajax也是一种将发往源站服务器的请求数量减少的有效方法。
边缘侧包含（Edge Side Include）。
瓶颈二：压缩
另外一种非常常见的提升站点性能的方式就是对内容进行压缩，这样可以确保内容的比特数尽可能小，传输速度尽可能快。压缩一般是针对JS和CSS这种静态对象来使用的，而无需考虑内容变换的速度和频率，因为缓存规则能够使得基于Last-Modified-Since和Time-To-Live这两个值的对象失效。
观察：
根据我们观察到的最新数据，一些站点最多能够包括115种字体资源，最少1种，平均4种。
这一结果说明，由于种种原因，很少有站点会对字体资源进行压缩，其中一种原因有可能是这些字体资源来自第三方：
如图所示：1. 9.6%的本站字体资源经过压缩2. 2.4%的第三方字体资源经过压缩3. 22.4%的本站字体资源未经压缩4. 64.6%的第三方字体资源未经压缩
分析：
我们刚才已经说到了，站点能够包含的字体最多有115种，所以对这些字体进行压缩就变得异常重要，因为这可以缩短页面加载的时间，并且从终端用户的角度来提升页面渲染的速度。
根据最新的数据统计显示，87%的站点没有对字体进行压缩，而22%的站点自己使用的字体没有采用压缩。这些资源是通过主站的域名来进行控制和访问的，所以可以在源站服务器上进行压缩配置。
还有更复杂的情况，也就是使用第三方字体资源的时候，比如来自谷歌等。我们发现，最近有65%的站点使用了第三方字体资源，而这些字体都没有进行压缩。
解决方法：
对于自有的字体资源，压缩可以在源站服务器上来进行，或者在使用代理和CDN的前提下，在最后一公里进行压缩。总体来说，现在的浏览器大部分都支持GZIP，这也使得浏览器对字体压缩不再成为问题。
对于第三方字体资源，Akamai也可以提供更为具体的解决方案，来保证字体能够以最快的速度进行分发。
瓶颈三：HTTP响应代码
毋庸置疑，当内容回到源站服务器（或者缓存）的时候，大部分站点所使用的响应代码都是“200/OK”。也就是说，除了这个特定的响应代码之外，还有相当大比例的请求响应代码在被使用，这也是会对站点性能造成显著影响的一个因素。下面，我们来看看这些代码的使用比例：
右侧图例上现实的响应码分别是：部分内容/206重定向/301/302未修改/304未发现/404错误/4xx/5xx其他非200响应代码
“错误”响应代码
总体而言，“错误”响应代码从低到高代表了不同的意思，最高的493错误代码意味着整个站点都出错了。 而大多数情况下我们看到的错误代码并不是493， 而是像404“未发现”这样的响应代码，原因是内容名称或者内容发生变化、而且没有得到解决。这在使用内容管理系统将资源直接从源站拉出或者推入的时候尤为常见。这种问题的优先级都不是太高，相关人员会更加着急解决其他更为重要的麻烦。随着时间的推移，这些错误就会不断堆积，进而导致缓存率不足而影响源站的性能，或者是由于请求并不存在的内容请求指向源站造成流量上升而影响速度和性能。 服务器端的错误响应代码是5xx，出现这种错误代码的原因有可能是：源站服务器的超时设置、初始链接等待响应的时长等。对源站的健康度检测是预防这种错误代码出现的好办法，如果一旦健康度低于预设的某个阈值，仪表板上的警告机制就会被触发。
“缓存”响应代码304/206
根据上面的图表，304/206响应代码的出现率是相当低的。因为我们得到的数据是基于HTTP Archive上所使用的WebPage Test第一屏结果，这种检测方式对于这两种响应代码的情况反映是不够精确的。
尽管如此，我们还是值得去讨论一下，在源站使用If-Modified-Since的头部文件来产生304响应代码可以如何为网站减压。使用这种响应代码，我们可以尽可能地减少对未变更内容的分发需要。如果我们在终端用户和源站服务器之间使用了代理服务器或者CDN，那么使用304响应代码可以带来的收益就更大了。
对于触发206响应代码的大型对象的请求，将部分对象进行缓存可以提升向最终用户进行分发的效率。这样做，我们可以减少指向源站的请求数量，同时提升大型对象的分发速度。
301/302重定向响应代码
根据上面图表所显示的信息，重定向响应代码占据了相当大的比例，而且也是除了200响应代码之外使用最为频繁的响应代码。对于想要进行品牌再造或者仅仅是想要避免在Web应用服务器侧进行重大变更的网站而言，使用率是相当高的。根据最新的调查结果，网站使用最多的重定向响应码是910，而对于那些使用了CDN服务的网站而言，使用最多的是353。重定向会影响到SEO排名，而更为常见的是，会增加对页面的请求次数，进而拖慢网站或者页面的加载时间。
我们可以看到，使用了CDN服务的网站持续使用了大量的重定向响应代码，那么问题来了：有了CDN的话，尤其是当CDN服务商可以帮助你对路由进行重定向的时候，这么做还有必要吗？
Web性能瓶颈：进阶
我们在上面提到了一些常见的Web性能瓶颈，除了这些因素之外，我们还需要认识到：一些更加明显、更加常见的Web性能瓶颈导致了JavaScript资源的超量使用。下面我们来举一个比较贴切的例子：
使用多重JavaScript框架：
JavaScript的本质是“阻挡（Blocking）”，所以某个页面所包含的JS越多，在页面开始加载或者结束加载之前，就会有更多的内容要求被进行解析。为了了解有多少的页面使用了多重的JavaScript，我们使用了HTTP Archive关于页面和资源请求的分析数据。通过对最新的请求数据的分析，我们可以发现在资源URL自身内部所包含的不同的单一JavaScript框架名称。我们把这些名称返回到最新的页面请求数据内（页面ID），来确定在一个页面中一共使用了多少框架，并获得相应的清单。这个关于JS框架使用的调查最终显示了这样的结果：jquery，dojo，angular，prototype，backbone，emberjs，sencha，scriptaculous，d3，three，bootstrap 和foundation。根据最新的调查结果我们可以发现，大概有20%的网站使用了2到7个框架。大部分使用单一框架的站点主要采用了jQuery，因为通过这一框架，就可以使用许多不同的定制化扩展和装置。
我们可以从上面的图表看到，接近80%的站点使用了1个以上的JS框架。网站使用多个框架的原因其实显而易见——他们需要在页面上植入来自多个框架和库的多个组件——尤其是那些在github随手就可以拿到的。在github上面，开发和下载特定的装置，可以帮助他们在某一个站点内达成其所期待实现的行为。现在的潮流是，jquery，prototype，d3，bootstrap，angular，foundation和scriptaculous这几种框架比较受欢迎。当某个功能或者特性需要使用多重库的时候，网站就会倾向于使用多个框架，原因有二：样式和功能（取决于用户的互动方式）。所以现在的问题就是：我们为什么需要把资源浪费在下载和解析脚本上呢？而且某些脚本在页面开始加载之前，根本没有被包括在样式里。 我们在WebPageTest上获取了一些参数，并把这些参数和框架及库的数量进行比较，就会发现其对性能在整体上产生的不良影响。
右侧的图例分别是：1. 平局渲染时间2. 平均内容加载时间3. 平均加载时间4. 平均完全加载时间5. 平均视觉完成时间6. 平均速度参数
这张图显示的是，随着页面上包含的JS框架数量的增多（X轴从左到右），上述时间参数不断变大（毫秒单位，Y轴从下到上）。 进一步说，包含过多的JS框架会使得页面大小进一步增长，因为JavaScript的比特数都会落到页面的整体体积上面。当然，框架数量并不是影响比特数大小的唯一因素，但却仍然会成为影响Web性能的一个瓶颈。这种页面体积的增加，会需要更多的工作和技巧来解决。
此图显示的是：JS框架增加与其比特数总量的关系。也就是说，框架数量越多，比特数就越大。 除了将站点内不必要的框架移除之外，如果必须要使用多个框架和库，我们还可以通过一些前端优化的技术来改善网站的体验。
解决方法：
1. 脚本在网站中扮演两个主要角色：样式和功能。脚本并不包含在样式里，脚本是包含在导航里的。一旦用户开始加载了某个页面，这就会造成执行的延迟。
a) 在这种情况下，我们可以使用异步的JavaScript以及上传事件后的脚本执行递延来帮忙提升页面渲染的启动及完成效率。
2. 将脚本进行整合，会对页面的请求数量进行大幅度地缩减。通过这种方式，浏览器可以使用其他平行链接来开始下载页面上的其他内容。 a) 通过CDN平台，我们可以将Javascript整合到一个单独的html请求中，这样我们可以缩减JavaScript的封锁请求。
当前，我们面对的Web性能瓶颈的数量是很多的。有一些瓶颈是非常常见的，比如没有进行妥当的缓存、压缩以及响应代码的问题等等，这些问题都是可以通过我们上面谈到的方式来解决。此外，我们也可以看到应用多重JavaScript带来的问题，尽管脚本的使用非常必要，但是确实也会对性能和整体的用户体验造成影响。
瓶颈一：缓存
在面对静态内容的时候，我们最常用的方式就是通过将其缓存在浏览器、中间代理服务器或者CDN之上。因为能够提供相当大的卸载，这种将静态内容的缓存行为毫无疑问将对终端用户和源站服务器产生良好的影响。根据当前的趋势，我们可以看到，许多站点实际上都在缓存类似于JS，图像，CSS等对象；但是，我们却发现能够对HTML进行缓存的站点却并不多见。基础页面一般是比较动态化的，大部分的网站所有者都不会对这种页面进行缓存，因为HTML页面是在不断变化的。我们对尽可能多的网站数据进行了评估，结果如下：
根据上图，我们可以看到：34%的独立站点对HTML页面进行了缓存。66%的独立站点没有对HTML页面进行缓存。
分析：
我们发现，大量站点没有缓存基础页面，这将对站点的Speed Index（速度参数）造成直接影响。Speed Index能够反映视觉元素的平均完成程度，也是提升客户体验的一个重要方面。
如果页面包含了动态的内容，那么我们可以采取几种方式来确保其可缓存性，或者对动态内容进行潜在复用。
解决方法：利用低TTL对基础页面进行缓存——如果这样做，我们就能为内容提供一个较低的TTL，然后根据最终用户所在位置等不同变量进行变化，减少HTML请求次数进而卸载源站的负载。
异步JavaScript及XML（Ajax）——利用Ajax来动态地创建多页面组件，这使我们可以对多种存储进行缓存响应，包括session storage和local storage。可缓存的Ajax也是一种将发往源站服务器的请求数量减少的有效方法。
边缘侧包含（Edge Side Include）。
瓶颈二：压缩
另外一种非常常见的提升站点性能的方式就是对内容进行压缩，这样可以确保内容的比特数尽可能小，传输速度尽可能快。压缩一般是针对JS和CSS这种静态对象来使用的，而无需考虑内容变换的速度和频率，因为缓存规则能够使得基于Last-Modified-Since和Time-To-Live这两个值的对象失效。
观察：
根据我们观察到的最新数据，一些站点最多能够包括115种字体资源，最少1种，平均4种。
这一结果说明，由于种种原因，很少有站点会对字体资源进行压缩，其中一种原因有可能是这些字体资源来自第三方：
如图所示：1. 9.6%的本站字体资源经过压缩2. 2.4%的第三方字体资源经过压缩3. 22.4%的本站字体资源未经压缩4. 64.6%的第三方字体资源未经压缩
分析：
我们刚才已经说到了，站点能够包含的字体最多有115种，所以对这些字体进行压缩就变得异常重要，因为这可以缩短页面加载的时间，并且从终端用户的角度来提升页面渲染的速度。
根据最新的数据统计显示，87%的站点没有对字体进行压缩，而22%的站点自己使用的字体没有采用压缩。这些资源是通过主站的域名来进行控制和访问的，所以可以在源站服务器上进行压缩配置。
还有更复杂的情况，也就是使用第三方字体资源的时候，比如来自谷歌等。我们发现，最近有65%的站点使用了第三方字体资源，而这些字体都没有进行压缩。
解决方法：
对于自有的字体资源，压缩可以在源站服务器上来进行，或者在使用代理和CDN的前提下，在最后一公里进行压缩。总体来说，现在的浏览器大部分都支持GZIP，这也使得浏览器对字体压缩不再成为问题。
对于第三方字体资源，Akamai也可以提供更为具体的解决方案，来保证字体能够以最快的速度进行分发。
瓶颈三：HTTP响应代码
毋庸置疑，当内容回到源站服务器（或者缓存）的时候，大部分站点所使用的响应代码都是“200/OK”。也就是说，除了这个特定的响应代码之外，还有相当大比例的请求响应代码在被使用，这也是会对站点性能造成显著影响的一个因素。下面，我们来看看这些代码的使用比例：
右侧图例上现实的响应码分别是：部分内容/206重定向/301/302未修改/304未发现/404错误/4xx/5xx其他非200响应代码
“错误”响应代码
总体而言，“错误”响应代码从低到高代表了不同的意思，最高的493错误代码意味着整个站点都出错了。 而大多数情况下我们看到的错误代码并不是493， 而是像404“未发现”这样的响应代码，原因是内容名称或者内容发生变化、而且没有得到解决。这在使用内容管理系统将资源直接从源站拉出或者推入的时候尤为常见。这种问题的优先级都不是太高，相关人员会更加着急解决其他更为重要的麻烦。随着时间的推移，这些错误就会不断堆积，进而导致缓存率不足而影响源站的性能，或者是由于请求并不存在的内容请求指向源站造成流量上升而影响速度和性能。 服务器端的错误响应代码是5xx，出现这种错误代码的原因有可能是：源站服务器的超时设置、初始链接等待响应的时长等。对源站的健康度检测是预防这种错误代码出现的好办法，如果一旦健康度低于预设的某个阈值，仪表板上的警告机制就会被触发。
“缓存”响应代码304/206
根据上面的图表，304/206响应代码的出现率是相当低的。因为我们得到的数据是基于HTTP Archive上所使用的WebPage Test第一屏结果，这种检测方式对于这两种响应代码的情况反映是不够精确的。
尽管如此，我们还是值得去讨论一下，在源站使用If-Modified-Since的头部文件来产生304响应代码可以如何为网站减压。使用这种响应代码，我们可以尽可能地减少对未变更内容的分发需要。如果我们在终端用户和源站服务器之间使用了代理服务器或者CDN，那么使用304响应代码可以带来的收益就更大了。
对于触发206响应代码的大型对象的请求，将部分对象进行缓存可以提升向最终用户进行分发的效率。这样做，我们可以减少指向源站的请求数量，同时提升大型对象的分发速度。
301/302重定向响应代码
根据上面图表所显示的信息，重定向响应代码占据了相当大的比例，而且也是除了200响应代码之外使用最为频繁的响应代码。对于想要进行品牌再造或者仅仅是想要避免在Web应用服务器侧进行重大变更的网站而言，使用率是相当高的。根据最新的调查结果，网站使用最多的重定向响应码是910，而对于那些使用了CDN服务的网站而言，使用最多的是353。重定向会影响到SEO排名，而更为常见的是，会增加对页面的请求次数，进而拖慢网站或者页面的加载时间。
我们可以看到，使用了CDN服务的网站持续使用了大量的重定向响应代码，那么问题来了：有了CDN的话，尤其是当CDN服务商可以帮助你对路由进行重定向的时候，这么做还有必要吗？
Web性能瓶颈：进阶
我们在上面提到了一些常见的Web性能瓶颈，除了这些因素之外，我们还需要认识到：一些更加明显、更加常见的Web性能瓶颈导致了JavaScript资源的超量使用。下面我们来举一个比较贴切的例子：
使用多重JavaScript框架：
JavaScript的本质是“阻挡（Blocking）”，所以某个页面所包含的JS越多，在页面开始加载或者结束加载之前，就会有更多的内容要求被进行解析。为了了解有多少的页面使用了多重的JavaScript，我们使用了HTTP Archive关于页面和资源请求的分析数据。通过对最新的请求数据的分析，我们可以发现在资源URL自身内部所包含的不同的单一JavaScript框架名称。我们把这些名称返回到最新的页面请求数据内（页面ID），来确定在一个页面中一共使用了多少框架，并获得相应的清单。这个关于JS框架使用的调查最终显示了这样的结果：jquery，dojo，angular，prototype，backbone，emberjs，sencha，scriptaculous，d3，three，bootstrap 和foundation。根据最新的调查结果我们可以发现，大概有20%的网站使用了2到7个框架。大部分使用单一框架的站点主要采用了jQuery，因为通过这一框架，就可以使用许多不同的定制化扩展和装置。
我们可以从上面的图表看到，接近80%的站点使用了1个以上的JS框架。网站使用多个框架的原因其实显而易见——他们需要在页面上植入来自多个框架和库的多个组件——尤其是那些在github随手就可以拿到的。在github上面，开发和下载特定的装置，可以帮助他们在某一个站点内达成其所期待实现的行为。现在的潮流是，jquery，prototype，d3，bootstrap，angular，foundation和scriptaculous这几种框架比较受欢迎。当某个功能或者特性需要使用多重库的时候，网站就会倾向于使用多个框架，原因有二：样式和功能（取决于用户的互动方式）。所以现在的问题就是：我们为什么需要把资源浪费在下载和解析脚本上呢？而且某些脚本在页面开始加载之前，根本没有被包括在样式里。 我们在WebPageTest上获取了一些参数，并把这些参数和框架及库的数量进行比较，就会发现其对性能在整体上产生的不良影响。
右侧的图例分别是：1. 平局渲染时间2. 平均内容加载时间3. 平均加载时间4. 平均完全加载时间5. 平均视觉完成时间6. 平均速度参数
这张图显示的是，随着页面上包含的JS框架数量的增多（X轴从左到右），上述时间参数不断变大（毫秒单位，Y轴从下到上）。 进一步说，包含过多的JS框架会使得页面大小进一步增长，因为JavaScript的比特数都会落到页面的整体体积上面。当然，框架数量并不是影响比特数大小的唯一因素，但却仍然会成为影响Web性能的一个瓶颈。这种页面体积的增加，会需要更多的工作和技巧来解决。
此图显示的是：JS框架增加与其比特数总量的关系。也就是说，框架数量越多，比特数就越大。 除了将站点内不必要的框架移除之外，如果必须要使用多个框架和库，我们还可以通过一些前端优化的技术来改善网站的体验。
解决方法：
1. 脚本在网站中扮演两个主要角色：样式和功能。脚本并不包含在样式里，脚本是包含在导航里的。一旦用户开始加载了某个页面，这就会造成执行的延迟。
a) 在这种情况下，我们可以使用异步的JavaScript以及上传事件后的脚本执行递延来帮忙提升页面渲染的启动及完成效率。
2. 将脚本进行整合，会对页面的请求数量进行大幅度地缩减。通过这种方式，浏览器可以使用其他平行链接来开始下载页面上的其他内容。 a) 通过CDN平台，我们可以将Javascript整合到一个单独的html请求中，这样我们可以缩减JavaScript的封锁请求。
当前，我们面对的Web性能瓶颈的数量是很多的。有一些瓶颈是非常常见的，比如没有进行妥当的缓存、压缩以及响应代码的问题等等，这些问题都是可以通过我们上面谈到的方式来解决。此外，我们也可以看到应用多重JavaScript带来的问题，尽管脚本的使用非常必要，但是确实也会对性能和整体的用户体验造成影响。
