【原创】Webpack构建中hash的优化

背景：

• SPA的vue应用，采用webpack2构建，打包入口为main.js
• 输出：main模块打包成app.js，公共lib打包成vendor.js，公共样式打包成app.css，运行时依赖打包成mainfest.js，路由页面动态加载，输出以ID开头的js文件
• 缓存策略：对所有输出的文件加载hash值，服务器加上永久缓存的标志，通过hash来判断是否有新文件

改造前hash值改变的场景：

1、修改某个页面的业务代码：只有对应页面js的hash值改变 √

2、修改公共样式：只有app.css文件的hash值改变 √

3、增加页面（即在路由中动态导入模块）：所有模块的hash值都改变，包括app、vendor、mainfest和所有页面的js模块文件 ×（不能忍，会导致浏览器重新下载所有模块）

3、引入新库（即在Main中静态导入模块）：所有模块的hash值都改变，包括app、vendor、mainfest和所有页面的js模块文件 ×（同上）

原因分析：

1、默认情况下webpack的模块都是以一个有序数列命名的，也就是[0,1,2....]。
2、当引入/删除模块时，原有的顺序被打乱，导致所有模块的hash值改变，进而导致chunkhash改变。
3、所以app因为内容变化而变化，页面因为module.id变化而变化，vendor因为打包进的各个模块module.id发生变化，runtime因为它维护依赖关系而变化。

优化步骤：

1、稳定moduleId，

2、稳定chunkhash，（var WebpackChunkHash = require('webpack-chunk-hash');）

3、去除命名中的chunkId

优化后测试：

1、修改某个页面的业务代码：只有对应页面js的hash值改变 √
2、修改公共样式：只有app.css文件的hash值改变 √
3、增加页面（即在路由中动态导入模块）：仅改变代码的app发生变化 √

4、引入新库（即在Main中静态导入模块）：仅改变代码的app和打包新库的vendor发生变化` √

优化后的速度和压缩率 比对：

	构建总时间（第一次）	构建总时间（3次平均）	构建总大小（第一次）	构建总大小（3次平均）
初始	64849ms	64882ms	2.50MB	2.50MB
优化后	63867ms	62276ms	2.50MB	2.50MB

改动后构建速度和大小没有明显变化，构建时间稍微减少1~2秒。稳定hash不会对性能有影响。