今回は、Webpack が永続キャッシュを実装する方法を説明します。Webpack が永続キャッシュを実装するための 注意事項 は何ですか? 以下は実際的なケースです。
まえがき
最近、webpack が永続キャッシュをどのように実行するかを調べていましたが、まだいくつかの落とし穴があることに気づきました。この記事を読んだ後、それらを整理して要約することができます。
永続キャッシュ
まず第一に、フロントエンドとバックエンド、フロントエンドの HTML、CSS を分離するアプリケーションの現在の人気を踏まえて、永続キャッシュとは何なのかを説明する必要があります。 js は静的なリソース ファイルであることが多く、フォームはサーバー上に存在し、データはインターフェイスを通じて取得され、動的コンテンツが表示されます。これには、企業がフロントエンド コードをデプロイする方法の問題が関係するため、ページを最初にデプロイするか、それともリソースを最初にデプロイするかという更新デプロイの問題が関係します。 最初にページをデプロイし、次にリソースをデプロイします: 2 つのデプロイメントの間の時間間隔中に、ユーザーがページにアクセスすると、古いリソースが新しいページ構造にロードされ、リソースの古いバージョンがキャッシュされます。その結果、ユーザーは不規則なスタイルでページにアクセスし、手動で更新しない限り、ページはリソース キャッシュが期限切れになるまで不規則な状態のままになります。 最初にリソースをデプロイし、次にページをデプロイします。デプロイ時間間隔中に、古いバージョンのリソースのローカル キャッシュを持つユーザーが Web サイトにアクセスします。要求されたページは古いバージョンであり、リソース参照が変更されていないため、ブラウザーは直接 Web サイトにアクセスします。ローカル キャッシュを使用するため、これは通常の状況ですが、ローカル キャッシュを持たないユーザー、またはキャッシュの有効期限が切れたユーザーが Web サイトにアクセスすると、古いバージョンのページが新しいバージョンのリソースを読み込むため、ページ実行エラーが発生します。 そのため、オンライン コードを更新するときに、オンライン ユーザーがスムーズに移行して Web サイトを正しく開くことができるようにする展開戦略が必要です。 最初にこの回答を読むことをお勧めします: 大企業でフロントエンド コードを開発およびデプロイするにはどうすればよいですか? 上記の回答を読むと、ファイルが変更されるたびに生成されるハッシュ値が異なるため、現在のより成熟した永続キャッシュ ソリューションは静的リソースの名前の後にハッシュ値を追加することであることが大まかに理解できるでしょう。この利点は、以前のファイルを上書きしてオンライン ユーザー アクセスが失敗することを避けるために、ファイルを段階的に公開することです。 毎回公開される静的リソース (css、js、img) の名前が一意である限り、次のことが可能です:Webpack は永続キャッシュをどのように行うか
永続キャッシュを簡単に紹介した後、次のことが重要なポイントです。では、Webpack で永続キャッシュをどのように実行する必要がありますか? 次の 2 つのことを行う必要があります:ハッシュ値の安定性を確保するには、モジュールが変更されたときに、影響を受けるパッケージ化されたファイルのハッシュ値のみが変更され、モジュールに関係のないパッケージ化されたファイルのハッシュ値は変更されないことを保証する必要があります。
ハッシュ ファイル名は、永続的なキャッシュを実装するための最初のステップです。現在、webpack にはハッシュを計算する 2 つの方法 ([hash] と [chunkhash]) があります。
hash は、webpack がコンパイル中に毎回計算することを意味します。 process プロジェクト内のファイルが変更されたときに再作成される一意のハッシュ値を生成し、webpack が新しいハッシュ値を計算します。
chunkhashはモジュールに基づいて計算されたハッシュ値であるため、特定のファイルを変更してもそのハッシュ値のみに影響し、他のファイルには影響しません。
したがって、すべてを同じファイルにパックするだけであれば、ハッシュで満足できます。プロジェクトに解凍やモジュールのロードなどが含まれる場合は、関連するファイルのハッシュ値のみを使用する必要があります。更新ごとに変更されます。
したがって、永続キャッシュを使用した Webpack 構成は次のようになります:
module.exports = {
entry: dirname + '/src/index.js',
output: {
path: dirname + '/dist',
filename: '[name].[chunkhash:8].js',
}
}上記のコードの意味は、index.js をエントリ ポイントとして使用し、すべてのコードをindex.xxxx js という名前のファイルにパッケージ化して配置します。これで、プロジェクトを更新するたびに新しい名前のファイルを生成できるようになります。
単純なシナリオを扱う場合はこれで十分ですが、大規模なマルチページ アプリケーションでは、多くの場合、ページ上で パフォーマンスの最適化を実行する必要があります:
ビジネス コードとサードパーティ コードを分離する: 理由ビジネス コードとサードパーティ コードが分離されている理由 ビジネス コードは頻繁に更新され、サードパーティ コードは更新と反復が遅いため、サードパーティ コード (ライブラリ、フレームワーク) を分離して、ブラウザのキャッシュを読み込みます。
オンデマンドでのロード: たとえば、React-Router を使用する場合、ユーザーが特定のルートにアクセスする必要がある場合、対応するコンポーネントがロードされるため、最初にすべてのルーティング コンポーネントをダウンロードする必要はありません。地元。
マルチページ アプリケーションでは、ヘッダー、フッターなどの共通モジュールを抽出できることがよくあります。これにより、ページがジャンプしたときに、これらの共通モジュールはキャッシュ内に存在するため、代わりに直接読み込むことができます。さらにネットワーク要求を行う。
したがって、モジュールを解凍してモジュールにロードするには、webpack の組み込みプラグインである CommonsChunkPlugin が必要です。以下では、例を使用して webpack を構成する方法を説明します。
この記事のコードは私の Github にありますので、ご興味があればダウンロードしてご覧ください:
git clone https://github.com/happylindz/blog.git cd blog/code/multiple-page-webpack-demo npm install
以下の内容を読む前に、以前の記事を読むことを強くお勧めします。 webpack ファイルのパッケージ化メカニズムと webpack ファイルについての理解 パッケージング メカニズムは、永続的なキャッシュをより適切に実装するのに役立ちます。
この例は大まかに次のように説明されています: pageA と pageB の 2 つのページで構成されています
// src/pageA.js
import componentA from './common/componentA';
// 使用到 jquery 第三方库，需要抽离，避免业务打包文件过大
import $ from 'jquery';
// 加载 css 文件，一部分为公共样式，一部分为独有样式，需要抽离
import './css/common.css'
import './css/pageA.css';
console.log(componentA);
console.log($.trim(' do something '));
// src/pageB.js
// 页面 A 和 B 都用到了公共模块 componentA，需要抽离，避免重复加载
import componentA from './common/componentA';
import componentB from './common/componentB';
import './css/common.css'
import './css/pageB.css';
console.log(componentA);
console.log(componentB);
// 用到异步加载模块 asyncComponent，需要抽离，加载首屏速度
document.getElementById('xxxxx').addEventListener('click', () => {
import( /* webpackChunkName: "async" */
'./common/asyncComponent.js').then((async) => {
async();
})
})
// 公共模块基本长这样
export default "component X";上記のページ コンテンツには、基本的に、パブリック ライブラリの分割、オンデマンドのロード、およびパブリック モジュールの分割という 3 つのモジュール分割モードが含まれています。次に、次のステップは webpack を設定することです:
const path = require('path');
const webpack = require('webpack');
const ExtractTextPlugin = require('extract-text-webpack-plugin');
module.exports = {
entry: {
pageA: [path.resolve(dirname, './src/pageA.js')],
pageB: path.resolve(dirname, './src/pageB.js'),
},
output: {
path: path.resolve(dirname, './dist'),
filename: 'js/[name].[chunkhash:8].js',
chunkFilename: 'js/[name].[chunkhash:8].js'
},
module: {
rules: [
{
// 用正则去匹配要用该 loader 转换的 CSS 文件
test: /.css$/,
use: ExtractTextPlugin.extract({
fallback: "style-loader",
use: ["css-loader"]
})
}
]
},
plugins: [
new webpack.optimize.CommonsChunkPlugin({
name: 'common',
minChunks: 2,
}),
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor',
minChunks: ({ resource }) => (
resource && resource.indexOf('node_modules') >= 0 && resource.match(/.js$/)
)
}),
new ExtractTextPlugin({
filename: `css/[name].[chunkhash:8].css`,
}),
]
}最初の CommonsChunkPlugin はパブリック モジュールを抽出するために使用されます。これは、webpack ボスと言うのと同じです。モジュールが 2 回以上読み込まれている場合は、それを次の場所に移動するのを手伝ってください。共通チャンク、ここでの minChunks は 2 であり、粒度は最も小さくなります。実際の状況に応じて、モジュールを分割するために使用する回数を選択できます。
2 番目の CommonsChunkPlugin は、サードパーティのコードを抽出し、それらを抽出し、リソースが node_modules からのものであるかどうかを判断し、そうである場合は、それらがサードパーティのモジュールであることを意味し、それらを抽出するために使用されます。これは、webpack ボスに、node_modules ディレクトリからのモジュールがあり、その名前が .js で終わる場合は、ベンダー チャンクに移動してください、ベンダー チャンクが存在しない場合は、新しいチャンクを作成するように指示することと同じです。
この構成の利点は何ですか? ビジネスが成長するにつれて、サードパーティのコードを保存するための入り口を特別に構成する場合、webpack.config.js に依存することが多くなる可能性があります。次のようになります:
// 不利于拓展
module.exports = {
entry: {
app: './src/main.js',
vendor: [
'vue',
'axio',
'vue-router',
'vuex',
// more
],
},
}第三个 ExtractTextPlugin 插件用于将 css 从打包好的 js 文件中抽离，生成独立的 css 文件，想象一下，当你只是修改了下样式，并没有修改页面的功能逻辑，你肯定不希望你的 js 文件 hash 值变化，你肯定是希望 css 和 js 能够相互分开，且互不影响。
运行 webpack 后可以看到打包之后的效果:
├── css │ ├── common.2beb7387.css │ ├── pageA.d178426d.css │ └── pageB.33931188.css └── js ├── async.03f28faf.js ├── common.2beb7387.js ├── pageA.d178426d.js ├── pageB.33931188.js └── vendor.22a1d956.js
可以看出 css 和 js 已经分离，并且我们对模块进行了拆分，保证了模块 chunk 的唯一性，当你每次更新代码的时候，会生成不一样的 hash 值。
唯一性有了，那么我们需要保证 hash 值的稳定性，试想下这样的场景，你肯定不希望你修改某部分的代码(模块，css)导致了文件的 hash 值全变了，那么显然是不明智的，那么我们去做到 hash 值变化最小化呢？
换句话说，我们就要找出 webpack 编译中会导致缓存失效的因素，想办法去解决或优化它？
影响 chunkhash 值变化主要由以下四个部分引起的：
包含模块的源代码
webpack 用于启动运行的 runtime 代码
webpack 生成的模块 moduleid(包括包含模块 id 和被引用的依赖模块 id)
chunkID
这四部分只要有任意部分发生变化，生成的分块文件就不一样了，缓存也就会失效，下面就从四个部分一一介绍：
一、源代码变化：
显然不用多说，缓存必须要刷新，不然就有问题了
二、webpack 启动运行的 runtime 代码：
看过我之前的文章：深入理解 webpack 文件打包机制 就会知道，在 webpack 启动的时候需要执行一些启动代码。
(function(modules) {
window["webpackJsonp"] = function webpackJsonpCallback(chunkIds, moreModules) {
// ...
};
function webpack_require(moduleId) {
// ...
}
webpack_require.e = function requireEnsure(chunkId, callback) {
// ...
script.src = webpack_require.p + "" + chunkId + "." + ({"0":"pageA","1":"pageB","3":"vendor"}[chunkId]||chunkId) + "." + {"0":"e72ce7d4","1":"69f6bbe3","2":"9adbbaa0","3":"53fa02a7"}[chunkId] + ".js";
};
})([]);大致内容像上面这样，它们是 webpack 的一些启动代码，它们是一些函数，告诉浏览器如何加载 webpack 定义的模块。
其中有一行代码每次更新都会改变的，因为启动代码需要清楚地知道 chunkid 和 chunkhash 值得对应关系，这样在异步加载的时候才能正确地拼接出异步 js 文件的路径。
那么这部分代码最终放在哪个文件呢？因为我们刚才配置的时候最后生成的 common chunk 模块，那么这部分运行时代码会被直接内置在里面，这就导致了，我们每次更新我们业务代码(pageA, pageB, 模块)的时候， common chunkhash 会一直变化，但是这显然不符合我们的设想，因为我们只是要用 common chunk 用来存放公共模块(这里指的是 componentA)，那么我 componentA 都没去修改，凭啥 chunkhash 需要变了。
所以我们需要将这部分 runtime 代码抽离成单独文件。
module.exports = {
// ...
plugins: [
// ...
// 放到其他的 CommonsChunkPlugin 后面
new webpack.optimize.CommonsChunkPlugin({
name: 'runtime',
minChunks: Infinity,
}),
]
}这相当于是告诉 webpack 帮我把运行时代码抽离，放到单独的文件中。
├── css │ ├── common.4cc08e4d.css │ ├── pageA.d178426d.css │ └── pageB.33931188.css └── js ├── async.03f28faf.js ├── common.4cc08e4d.js ├── pageA.d178426d.js ├── pageB.33931188.js ├── runtime.8c79fdcd.js └── vendor.cef44292.js
多生成了一个 runtime.xxxx.js，以后你在改动业务代码的时候，common chunk 的 hash 值就不会变了，取而代之的是 runtime chunk hash 值会变，既然这部分代码是动态的，可以通过 chunk-manifest-webpack-plugin 将他们 inline 到 html 中，减少一次网络请求。
三、webpack 生成的模块 moduleid
在 webpack2 中默认加载 OccurrenceOrderPlugin 这个插件，OccurrenceOrderPlugin 插件会按引入次数最多的模块进行排序，引入次数的模块的 moduleId 越小，但是这仍然是不稳定的，随着你代码量的增加，虽然代码引用次数的模块 moduleId 越小，越不容易变化，但是难免还是不确定的。
默认情况下，模块的 id 是这个模块在模块数组中的索引。OccurenceOrderPlugin 会将引用次数多的模块放在前面，在每次编译时模块的顺序都是一致的，如果你修改代码时新增或删除了一些模块，这将可能会影响到所有模块的 id。
最佳实践方案是通过 HashedModuleIdsPlugin 这个插件，这个插件会根据模块的相对路径生成一个长度只有四位的字符串作为模块的 id，既隐藏了模块的路径信息，又减少了模块 id 的长度。
这样一来，改变 moduleId 的方式就只有文件路径的改变了，只要你的文件路径值不变，生成四位的字符串就不变，hash 值也不变。增加或删除业务代码模块不会对 moduleid 产生任何影响。
module.exports = {
plugins: [
new webpack.HashedModuleIdsPlugin(),
// 放在最前面
// ...
]
}四、chunkID
实际情况中分块的个数的顺序在多次编译之间大多都是固定的, 不太容易发生变化。
这里涉及的只是比较基础的模块拆分，还有一些其它情况没有考虑到，比如异步加载组件中包含公共模块，可以再次将公共模块进行抽离。形成异步公共 chunk 模块。有想深入学习的可以看这篇文章：Webpack 大法之 Code Splitting
webpack 做缓存的一些注意点
CSS 文件 hash 值失效的问题
不建议线上发布使用 DllPlugin 插件
CSS 文件 hash 值失效的问题：
ExtractTextPlugin 有个比较严重的问题，那就是它生成文件名所用的[chunkhash]是直接取自于引用该 css 代码段的 js chunk ；换句话说，如果我只是修改 css 代码段，而不动 js 代码，那么最后生成出来的 css 文件名依然没有变化。
所以我们需要将 ExtractTextPlugin 中的 chunkhash 改为 contenthash，顾名思义，contenthash 代表的是文本文件内容的 hash 值，也就是只有 style 文件的 hash 值。这样编译出来的 js 和 css 文件就有独立的 hash 值了。
module.exports = {
plugins: [
// ...
new ExtractTextPlugin({
filename: `css/[name].[contenthash:8].css`,
}),
]
}如果你使用的是 webpack2，webpack3，那么恭喜你，这样就足够了，js 文件和 css 文件修改都不会影响到相互的 hash 值。那如果你使用的是 webpack1，那么就会出现问题。
具体来讲就是 webpack1 和 webpack 在计算 chunkhash 值得不同：
webpack1 在涉及的时候并没有考虑像 ExtractTextPlugin 会将模块内容抽离的问题，所以它在计算 chunkhash 的时候是通过打包之前模块内容去计算的，也就是说在计算的时候 css 内容也包含在内，之后才将 css 内容抽离成单独的文件，
那么就会出现：如果只修改了 css 文件，未修改引用的 js 文件，那么编译输出的 js 文件的 hash 值也会改变。
对此，webpack2 做了改进，它是基于打包后文件内容来计算 hash 值的，所以是在 ExtractTextPlugin 抽离 css 代码之后，所以就不存在上述这样的问题。如果不幸的你还在使用 webpack1，那么推荐你使用 md5-hash-webpack-plugin 插件来改变 webpack 计算 hash 的策略。
不建议线上发布使用 DllPlugin 插件
为什么这么说呢？因为最近有朋友来问我，他们 leader 不让在线上用 DllPlugin 插件，来问我为什么？
DllPlugin 本身有几个缺点：
首先你需要额外多配置一份 webpack 配置，增加工作量。
其中一个页面用到了一个体积很大的第三方依赖库而其它页面根本不需要用到，但若直接将它打包在 dll.js 里很不值得，每次页面打开都要去加载这段无用的代码，无法使用到 webpack2 的 Code Splitting 功能。
第一次打开的时候需要下载 dll 文件，因为你把很多库全部打在一起了，导致 dll 文件很大，首次进入页面加载速度很慢。
虽然你可以打包成 dll 文件，然后让浏览器去读取缓存，这样下次就不用再去请求，比如你用 lodash 其中一个函数，而你用dll会将整个 lodash 文件打进去，这就会导致你加载无用代码过多，不利于首屏渲染时间。
我认为的正确的姿势是：
像 React、Vue 这样整体性偏强的库，可以生成 vendor 第三方库来去做缓存，因为你一般技术体系是固定的，一个站点里面基本上都会用到统一技术体系，所以生成 vendor 库用于缓存。
像 antd、lodash 这种功能性组件库，可以通过 tree shaking 来进行消除，只保留有用的代码，千万不要直接打到 vendor 第三方库里，不然你将大量执行无用的代码。
結論
さて、最近また webpack を読んで本当に多くのことを学んだ気がします。この記事から皆さんが何かを得られることを願っています。さらに、ファイル キャッシュ メカニズムをよりよく理解するのに役立つ、以前に書いた記事を再度お勧めします: Webpack ファイル パッケージ化メカニズムの詳細な理解
この記事のケースを読んだ後、あなたは方法をマスターしたと思います。さらにエキサイティングなコンテンツについては、他の php 中国語 Web サイト関連記事にご注意ください。
推奨読書:
Node.jsの登録メールアドレスを有効にする方法とは何ですか
以上がWebpack が永続的なキャッシュを実装する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
