本文探讨了影响网站性能的常见瓶颈，包括未充分利用的缓存、内容压缩以及不理想的HTTP响应代码。建议对HTML进行缓存，压缩字体资源，以及优化HTTP响应代码，以提高SpeedIndex和用户体验。同时指出，过度使用JavaScript框架会增加页面大小，降低加载速度。解决方案包括减少不必要的框架和利用前端优化技术。
当前，许多站点的部署方式都对自身的性能产生了消极影响，而网站的所有者并没有意识到这个问题。我们今天针对性的讨论以下几个常见的影响网站性能的瓶颈，观察其变化趋势，并简单说明一些解决方案来提升网站的性能。
瓶颈一：缓存
在面对静态内容的时候，我们最常用的方式就是通过将其缓存在浏览器、中间代理服务器或者CDN之上。因为能够提供相当大的卸载，这种将静态内容的缓存行为毫无疑问将对终端用户和源站服务器产生良好的影响。根据当前的趋势，我们可以看到，许多站点实际上都在缓存类似于JS，图像，CSS等对象；但是，我们却发现能够对HTML进行缓存的站点却并不多见。基础页面一般是比较动态化的，大部分的网站所有者都不会对这种页面进行缓存，因为HTML页面是在不断变化的。
大量站点没有缓存基础页面，这将对站点的Speed Index（速度参数）造成直接影响。Speed Index能够反映视觉元素的平均完成程度，也是提升客户体验的一个重要方面。
如果页面包含了动态的内容，那么我们可以采取几种方式来确保其可缓存性，或者对动态内容进行潜在复用。
瓶颈二：压缩
另外一种非常常见的提升站点性能的方式就是对内容进行压缩，这样可以确保内容的比特数尽可能小，传输速度尽可能快。压缩一般是针对JS和CSS这种静态对象来使用的，而无需考虑内容变换的速度和频率，因为缓存规则能够使得基于Last-Modified-Since和Time-To-Live这两个值的对象失效。
根据相关数据，一些站点最多能够包括115种字体资源，最少1种，平均4种。但由于种种原因，很少有站点会对字体资源进行压缩，其中一种原因有可能是这些字体资源来自第三方。
所以对这些字体进行压缩就变得异常重要，因为这可以缩短页面加载的时间，并且从终端用户的角度来提升页面渲染的速度。
瓶颈三：HTTP响应代码
毋庸置疑，当内容回到源站服务器（或者缓存）的时候，大部分站点所使用的响应代码都是“200/OK”。也就是说，除了这个特定的响应代码之外，还有相当大比例的请求响应代码在被使用，这也是会对站点性能造成显著影响的一个因素。
我们在上面提到了一些常见的Web性能瓶颈，除了这些因素之外，我们还需要认识到：一些更加明显、更加常见的Web性能瓶颈导致了JavaScript资源的超量使用。下面我们来举一个比较贴切的例子：使用多重JavaScript框架
网站使用多个框架的原因其实显而易见——他们需要在页面上植入来自多个框架和库的多个组件——尤其是那些在github随手就可以拿到的。在github上面，开发和下载特定的装置，可以帮助他们在某一个站点内达成其所期待实现的行为。现在的潮流是，jquery，prototype，d3，bootstrap，angular，foundation和scriptaculous这几种框架比较受欢迎。当某个功能或者特性需要使用多重库的时候，网站就会倾向于使用多个框架，原因有二：样式和功能（取决于用户的互动方式）。所以现在的问题就是：我们为什么需要把资源浪费在下载和解析脚本上呢？而且某些脚本在页面开始加载之前，根本没有被包括在样式里。
进一步说，包含过多的JS框架会使得页面大小进一步增长，因为JavaScript的比特数都会落到页面的整体体积上面。当然，框架数量并不是影响比特数大小的唯一因素，但却仍然会成为影响Web性能的一个瓶颈。这种页面体积的增加，会需要更多的工作和技巧来解决。
除了将站点内不必要的框架移除之外，如果必须要使用多个框架和库，我们还可以通过一些前端优化的技术来改善网站的体验。
当前，我们面对的Web性能瓶颈的数量是很多的。有一些瓶颈是非常常见的，比如没有进行妥当的缓存、压缩以及响应代码的问题等等，这些问题都是可以通过我们上面谈到的方式来解决。此外，我们也可以看到应用多重JavaScript带来的问题，尽管脚本的使用非常必要，但是确实也会对性能和整体的用户体验造成影响。
推荐阅读：
扫一扫
1878
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
