网站性能的优化

具体的从两方面进行总结

一, 网络通讯 (下降请求次数,下降传输量)

1,合并文件 (下降请求次数)
复制代码

1.资源缓存

1.1 使用CDN

将网站的静态资源分离，如静态HTML、图片Image、样式CSS、脚本JS等，把静态资源部署到CDN中，能够明显加快这部分资源的加载速度。
复制代码

1.2 利用HTTP缓存机制

HTTP缓存会把浏览器加载过的资源缓存到本地，下次加载时，只要缓存的资源没有过时，就能够直接使用本地的资源，减小了HTTP请求次数，加快了资源加载速度。具体作法是设置HTTP Header 中的Cache-Control参数。HTTP 1.0 中使用Pragma和Expires两个参数进行缓存，不过早已不推荐使用。
复制代码

2. 资源的合并压缩

2.1 减小HTTP请求

用一个HTTP请求去加载一个10M的文件，和把这个文件拆分红1M的10个文件，用10个HTTP请求并行去加载，哪种方式能更快完成加载？既然提到减小HTTP请求能够提升网站响应速度，那么结论貌似应该是用一个HTTP请求的方式更快。其实正确的答案是：不必定！
我作了一个小实验：有两个html文件，index1.html和index2.html，index1.html中用1个<script>标签加载一个2M的js文件bundle.js，index2.html中用6个<script>标签分别加载bundle1.js, bundle2.js …… bundle6.js，这6个js文件由bundle.js平均拆分获得。分别请求index1.html和index2.html 10次，获得加载bundle.js的时间和加载bundle1.js 到 bundle6.js的时间（以最后一个js文件加载完成为结束时间），计算平均加载时间分别为：1.07s 和 1.87s。
实验结论证实了，一个HTTTP请求加载一个合并后的资源文件，比多个HTTTP请求并发加载多个资源文件效率高。但结论只是针对平均加载时间而言，对于单次的比较，彻底可能出现相反的结论，例如个人实验过程当中，单一HTTTP请求加载时间的最大值为2.36s，超过了第二种加载方式的平均时间1.87s。可能有些人会比较疑惑，为何并行的效率反而比串行的要低呢？其实，HTTP请求加载资源的瓶颈在带宽，而不是请求的数量，在一个请求已经利用带宽很充分的状况下，增长新的请求并不能减小总体的资源加载时间。
其实，减小HTTP请求来提升网站性能主要是基于如下2个缘由：

HTTP链接的创建是比较耗时的，通常须要上百ms，每一个HTTP请求还有必定的网络延时，须要的HTTP请求越多，这两部分产生的耗时也就越多。固然，HTTP 1.1 对keep-alive的默认支持，能够实现链接的复用，很大程度上优化了这个问题。

2）每一个HTTP请求都须要附带额外的数据，好比请求和响应中的头信息，Cookie信息。当请求的资源很小时，附带的额外数据可能比实际的资源还大。
复制代码

3. 服务器端开启gzip

服务端开启gzip压缩，能够减小资源文件在网络传输过程当中的体积大小。 启用gzip压缩(网络传输的压缩传输的数据代码量会减少为原来的三分之一, 传入后再进行解压)

4, 图片的压缩

减少文件的体积

使用WebP格式的图片。WebP是一种支持有损压缩和无损压缩的图片文件格式，派生自图像编码格式 VP8。根据 Google 的测试，无损压缩后的 WebP 比 PNG 文件少了 45％ 的文件大小，即便这些 PNG 文件通过其余压缩工具压缩以后，WebP 仍是能够减小 28％ 的文件大小。

2）使用字体图标IconFont。能够任意设置Icon图形的大小和颜色（只能是单色，由于本质上是给字体设置颜色）。
3）使用CSS Sprites将多张图片合并成一张，从而减小HTTP请求数量。
4）使用Base64直接把图片编码成字符串写入CSS文件，也是从减小HTTP请求数量考虑。但须要注意，Base64编码的图片最好是小图片（最好几十字节级别的），由于图片通过Base64编码后，通常会比原文件更大些。并且太长的Base64编码字符串也会影响CSS的总体可读性。
5）对于须要大量图片的网站，应该把图片资源单独部署，并使用不一样的域名来访问。由于图片资源占带宽很大，若是把图片和其余资源部署到一台服务器或一个集群中，服务器端的出口带宽会受到很大影响。使用不一样的域名加载图片资源，能够更好的利用浏览器并行下载的特性，由于浏览器对于一个域名下的最大并行请求数是有限制的。
复制代码

二, 代码层

节省内存,节省CPU

1,尽可能不使用闭包(节省内存)

2,杜绝无效的循环

3,递归过程优化(添加缓存)
复制代码