webpack uglify部分压缩

[klouskingsley]

起因

公司的项目使用一个用webpack打包的多页面应用，entry多达100多个，在每次上线打包时，打包一次需要30多分钟时间，而uglify就花费了90%以上的时间，所以优化这一块是很有必要的。

分析

100多个页面的应用，每次上线所修改或新增的页面一般都在5个或者5个以下，而另外多达90多个未修改的页面也进行了重新打包，而这些页面完全可以直接使用上次已经打包好了文件。

方案

• 第一步

webpack编译时设置output.filename的时候加上chunkhash，这样每次编译(此时不压缩)后生成的文件名中都有一个hash字符串，然后可以根据这个字符串是否改变来判断编译后的文件和上一次编译后的文件不同。

这里有一个小插曲，即时每次值更改一个entry的文件，其他entry编译生成的文件hash也会变化，这是由于webpack在每次编译时对模块的id命名都是不同的，因而编译出来的文件也是不同的，此时需要设置recordsPath，让webpack对模块命名时优先使用上次已经记录好的命名。

• 第二步

根据上一步得出前后两次编译不同的文件，这些文件就是需要重新压缩的文件，只需要将他们压缩之后上传cdn即可，但是webpack是按照模块为单位进行处理的，如果直接对编译后得到的文件进行压缩的话，话发现压缩率非常低(比如：985k -> 980k，正常编译压缩可以压缩到100k以下)，需要对这些文件对应的entry进行重新编译压缩，此时才能得到比较满意的压缩率，然后上传cdn，至此，第二步结束。

• 第三步

经过前两步之后，我们得到了我们想要的效果，但最后还有些东西要处理，比如如果你使用了Assets Plugin的话，你可能需要手动生成一个assets文件，因为上面两步已经把正常生成的assets文件给破坏了。

成果

现在公司的项目有此前的每次构建需要编译压缩40多分钟，变成了现在的7分钟以内。
由以前的每次构建编译压缩全部文件，并且上传全部文件的方式，变成了第一次只进行编译，第二次进行编译并压缩真正改变的文件(通常只有1~2个文件)，然后只上传真正改变的文件。

注意

• 提速

值得注意的是，node_modules下的文件，如果没有使用yarn.lock或者package-lock等功能锁定版本的话，也会导致文件hash的频繁变化，所以建议锁定其版本，但如果你的项目是迭代非常频繁的话，其实也影响不大。

• 省钱

由于之前每次上线都会把所有文件上传并让用户请求新的文件，即使里面的代码其实没有改变，这里有两个文件：1，每次都上传新的文件，oss的存储需要定时删除旧文件(可能会有回滚，所以不能每次上线后就把旧文件都删除)，否则oss会产生很多垃圾文件；2，用户每次到要请求一些新的但代码是没有更改的文件，会消耗用户和cdn的流量。

经过上面的优化，只需上传代码真正修改的文件，用户请求的文件(不被修改的)可以从浏览器的缓存中读取，也就很好的解决了上面的两个问题。