具体的从两方面进行总结
一, 网络通信 (降低请求次数,降低传输量)
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,递归过程优化(添加缓存)
复制代码