资源压缩与合并

概述

    web前端的性能优化，从最基础的说起，应该就是资源的合并与压缩了。如今现代的前端开发都会有比较成熟的压缩资源合并和压缩工具，例如webpack、fis3等；但是为什么要进行资源的压缩与合并，是基于怎么样的理论基础，是值得研究的。

HTTP请求过程

HTTP请求过程

可以看到，我们去访问一个页面经历了以下过程：

（1）在浏览器输入一个url地址后，浏览器会将域名发送给DNS服务器，返回IP；

（2）浏览器会去请求资源，经历了：局域网-交换机-路由器-主干网络；

（3）到服务端通过一个MVC框架，返回相应的资源给浏览器；

（4）浏览器获取到资源后进行渲染；

从整个流程看，前端优化的方向还是比较多的，例如：

（1）是否可以减少dns查询时间？

（2）网络请求能否走最近的网络环境，以便请求速度加快？

（3）静态资源能否缓存？

（4）能否减少http请求次数以及请求量的大小？

（5）渲染能否在服务端做？

html/css/js的压缩

    为什么要进行资源压缩呢？实际上，为了开发人员的便捷，开发完的代码的结构是很清晰的，但是这对于浏览器来说并没有什么好处，浏览器反而还需要对你的代码进行解析，多余的空格，过长的变量等都会使得文件变大，或者解析时间加长；

    于是，文件的压缩很好的解决了这个问题，比如：

网站：http://tool.oschina.net/jscompress/

压缩示例

从例子可以看出，压缩后的格式发生了变化，也可以进行代码混淆，方式泄露敏感信息：

js代码混淆和加密

代码压缩后，实际文件大小也会变小，有利于加快请求速度，例如jquery的压缩前后对比：

jquery.js和jquery.min.js对比

HTML和CSS的压缩也是类似，这里也就不过多说明了。

文件合并

不合并文件的问题

假如我们需要请求一套js文件资源（共10个），如果我们不进行合并，可能会有如下结果：

（1）建立10次http请求，承担了10次网络延时；

（2）丢包的概率加大；

（3）经过代理服务器可能会断开（keep-alive请求问题）；

    如果我们进行10个资源的合并，则减少了9个网络延时（如果网速还不错的话，一个延时在几十毫秒），如果数量多了，这个请求时间的优化是非常可观的；其次减小了如上所说的（2）和（3）的问题；

过度文件合并的问题

    当然也不是说把所有文件都合成一个文件就是最好的，有存在以下问题：

（1）首屏渲染问题

    如果一个文件的体积过大，承担的任务过重，则浏览器很可能在前面的很长时间都在请求资源，且现在类似vue框架都是依赖vue.js库进行渲染，会导致白屏时间长，用户体验差。

（2）缓存问题

    修改过的文件通过会在打包时，将文件名加上md5戳，来标记是否修改；如果均打包成一个文件，则一旦代码稍作改动，就会导致协商缓存整体失效；

合并的建议

（1）不经常变动的公共库进行合并；

（2）根据页面的不同进行合并；

（3）根据具体的业务场景进行合并；

如何合并

（1）现有的工具，如：webpack、fis3、nodejs等；

（2）在线网站进行合并；