【原创】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模块文件 ×（不能忍，会导致浏览器重新下载所有模块）

PS：没测试过之前，我一直以为不会改变所有的hash值。。。。

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

原因分析：

1、默认情况下webpack的模块都是以一个有序数列命名的，也就是[0,1,2....]。
2、当引入/删除模块时，原有的顺序被打乱，导致所有模块的hash值变动，进而导致chunkhash改变。

上述场景【4】为例：

• app.js因为内容变化（引入新模块）而变化
• 页面模块因为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发生变化` √

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

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