对Webpack的hash稳定性的初步探索-转载
Posted IFE
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了对Webpack的hash稳定性的初步探索-转载相关的知识,希望对你有一定的参考价值。
欢迎关注 EFE 主席 张立理团队的知乎技术专栏:FE FAME
背景
众所周知,IO是一个很蛋疼的东西,为此我们大量引入异步的操作,甚至改变了编程的模式。而网络更是蛋疼中的蛋疼,其延迟、速度和不可预测性都让Web应用万分难堪。
现代的Web应用的性能其实很大程度上是建立在缓存的基础上的,而其中最为常见的一种最大化利用缓存的形式就是为静态资源加上hash,使用一个不会重复的标识符来达到资源可以永久缓存的目的。
hash的重要性在于它决定了缓存的失效与否,进一步决定了缓存的利用率。在一个迭代更频繁的系统中,hash的稳定性——即尽量保证一个资源的hash在多次发布过程中保持不变——对性能的影响就更为显著。
默认的hash稳定性
第一步,我们希望看一下webpack自身对hash的稳定性是怎么处理的,因此造了一个非常简单的结构:
/src
index.js
a.js
b.js
webpack.config.js
在a.js
中,我们简单地引用并使用一下著名的lodash
库:
import {identity} from 'lodash';identity();
然后作为入口的index.js
去引用a.jx
:
import './a';
为了让webpack能够拆出相应的chunk来,对webpack作了一些简单的配置:
const path = require('path');module.exports = {
mode: 'production',
context: path.join(__dirname, 'src'),
entry: {
index: './index.js',
},
output: {
path: path.join(__dirname, 'dist'),
filename: '[name].[chunkhash].bundle.js',
chunkFilename: '[name].[chunkhash].bundle.js',
publicPath: '/',
},
optimization: {
splitChunks: {
chunks: 'all',
},
runtimeChunk: true,
}};
随后运行webpack(4.3.0),看一下构建后的结果:
runtime~index.bc3506a5bf6b5c36ca7d.bundle.js 1.04 KiB 0 [emitted] runtime~index
vendors~index.d0b760b44e3276af20c4.bundle.js 69 KiB 1 [emitted] vendors~index
index.ffce817c9dbe9b136009.bundle.js 140 bytes 2 [emitted] index
随后,我们让index.js
去同时引用b.js
(该文件是空的,它的内容并不重要):
import './a';import './b';
再次运行webpack,我们得到这样的结果:
runtime~index.bc3506a5bf6b5c36ca7d.bundle.js 1.04 KiB 0 [emitted] runtime~index
vendors~index.3f86a94c0120d9b7fb8b.bundle.js 69 KiB 1 [emitted] vendors~index
index.f770b0f6781e083cd18b.bundle.js 161 bytes 2 [emitted] index
可以看到,除了预期内的index
的hash产生了变化外,vendors
也同样改变了其hash,哪怕我们从头到尾都只引用了一个lodash
,理论上vendors
中的内容没有变化(事实上写这篇的原因就是我天真地以为webpack 4所谓0配置已经解决了这一问题)。随后我们用MD5验证了其内容确实不同:
MD5 (dist/vendors~index.3f86a94c0120d9b7fb8b.bundle.js) = ab1f3168f7f7b96b9be60b8f701c05c7
MD5 (dist/vendors~index.d0b760b44e3276af20c4.bundle.js) = 4f6d1aa1f5aa21b55b20791b20c11ec4
查看原文请点击下方“阅读原文”
以上是关于对Webpack的hash稳定性的初步探索-转载的主要内容,如果未能解决你的问题,请参考以下文章