瓶颈一：缓存
在面对静态内容的时候，我们最常用的方式就是通过将其缓存在浏览器、中间代理服务器或者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框架。
