Comment Webpack gère la mise en cache

Cette fois, je vais vous montrer comment Webpack exploite le cache, et quelles sont les précautions à prendre par Webpack pour faire fonctionner le cache. Ce qui suit est un cas pratique, jetons un coup d'œil.

Avant-propos

Récemment, j'ai examiné comment Webpack effectuait la mise en cache persistante et j'ai découvert qu'il y avait encore quelques pièges. J'ai juste le temps de les trier et de les résumer après. en lisant cet article, vous pouvez à peu près comprendre :

1. Qu'est-ce que la mise en cache persistante et pourquoi faisons-nous de la mise en cache persistante ?

2. Comment Webpack est-il persistant mise en cache ?

3. Quelques notes sur la mise en cache du webpack.

Mise en cache persistante

Nous devons d'abord expliquer ce qu'est la mise en cache persistante, dans le contexte de la popularité actuelle des applications où le front-end et la séparation back-end est Dans ces circonstances, le HTML, le CSS et le js front-end existent souvent sur le serveur sous la forme d'un fichier de ressources statiques, et les données sont obtenues via des interfaces pour afficher du contenu dynamique. Cela implique la question de la manière dont l'entreprise déploie le code front-end, cela implique donc une question de déploiement des mises à jour. La page doit-elle être déployée en premier, ou les ressources doivent être déployées en premier ?

Déployez d'abord la page, puis déployez les ressources : Durant l'intervalle de temps entre les deux déploiements, si un utilisateur accède à la page, l'ancienne ressource sera chargée dans la nouvelle structure de page, et l'ancienne version de la La ressource sera considérée comme la nouvelle. Lorsque la version est mise en cache, le résultat est que l'utilisateur accède à une page avec un style désordonné. À moins d'être actualisée manuellement, la page restera dans un état désordonné jusqu'à l'expiration du cache de ressources.

Déployez d'abord les ressources, puis déployez les pages : pendant l'intervalle de temps de déploiement, les utilisateurs disposant de ressources mises en cache localement d'anciennes versions visitent le site Web. Étant donné que la page demandée est une version plus ancienne, la référence de la ressource n'a pas changé et le navigateur. L'utilisera directement. La mise en cache locale est normale, mais lorsque les utilisateurs qui n'ont pas de mise en cache locale ou dont le cache a expiré visitent le site Web, la page de l'ancienne version chargera la nouvelle version de la ressource, ce qui entraînera une erreur d'exécution de la page.

Nous avons donc besoin d'une stratégie de déploiement pour garantir que lorsque nous mettons à jour notre code en ligne, les utilisateurs en ligne puissent effectuer une transition en douceur et ouvrir notre site Web correctement.

Il est recommandé de lire d'abord cette réponse : Comment développer et déployer du code front-end dans une grande entreprise ?

Après avoir lu la réponse ci-dessus, vous comprendrez à peu près que la solution de mise en cache persistante la plus mature consiste désormais à ajouter une valeur de hachage après le nom de la ressource statique, car la valeur de hachage est générée à chaque fois que le fichier est modifié. est différent. L'avantage est de publier les fichiers de manière incrémentielle pour éviter d'écraser les fichiers précédents et de provoquer l'échec de l'accès des utilisateurs en ligne.

Car tant que les noms des ressources statiques (css, js, img) publiées à chaque fois sont uniques, alors je peux :

1. Pour les fichiers html : Faire n'activez pas la mise en cache, mettez le HTML sur votre propre serveur, désactivez le cache du serveur, votre serveur ne fournit que des fichiers HTML et des interfaces de données

2. Pour les js statiques, les CSS, les images, etc. Fichier : Activez le CDN et la mise en cache, et téléchargez les ressources statiques vers le fournisseur de services CDN. Nous pouvons activer la mise en cache à long terme des ressources. Le chemin de chaque ressource étant unique, cela n'entraînera pas l'écrasement de la ressource, garantissant ainsi la stabilité de la connexion en ligne. accès des utilisateurs.

3. Chaque fois qu'une mise à jour est publiée, les ressources statiques (js, css, img) sont d'abord transférées vers le service cdn, puis le fichier html est téléchargé. Cela garantit que les anciens utilisateurs. L'accès normal permet aux nouveaux utilisateurs de voir de nouvelles pages.

Ce qui précède présente brièvement la solution de mise en cache persistante frontale la plus courante, alors pourquoi devons-nous faire une mise en cache persistante ?

Lorsqu'un utilisateur visite notre site pour la première fois à l'aide d'un navigateur, la page introduit une variété de ressources statiques. Si nous pouvons réaliser une mise en cache persistante, nous pouvons ajouter Cache- dans l'en-tête de réponse http ou Expire. champ pour définir le cache, le navigateur peut mettre en cache ces ressources localement une par une.

Si l'utilisateur doit demander à nouveau la même ressource statique lors de visites ultérieures et que la ressource statique n'a pas expiré, le navigateur peut utiliser directement le cache local au lieu de demander la ressource via le réseau.

Comment Webpack effectue la mise en cache persistante

Après avoir brièvement introduit la mise en cache persistante, ce qui suit est le point clé, alors comment devrions-nous faire la mise en cache persistante dans Webpack Eh bien, nous devons faites les deux choses suivantes :

1. Assurez l'unicité de la valeur de hachage, c'est-à-dire générez une valeur de hachage unique pour chaque ressource empaquetée. Tant que le contenu empaqueté est incohérent, alors Le. les valeurs de hachage sont incohérentes.

2. Pour garantir la stabilité de la valeur de hachage, nous devons nous assurer que lorsqu'un module est modifié, seule la valeur de hachage du fichier empaqueté affecté change, et la valeur de hachage du fichier empaqueté sans rapport avec le module reste inchangé.

Le nom du fichier de hachage est la première étape pour implémenter la mise en cache persistante. Actuellement, webpack dispose de deux façons de calculer le hachage ([hash] et [chunkhash])

1. hash signifie que chaque fois que webpack génère une valeur de hachage unique pendant le processus de compilation, elle sera recréée après la modification d'un fichier du projet, puis webpack calcule la nouvelle valeur de hachage.

2. Chunkhash est une valeur de hachage calculée en fonction du module, donc les modifications apportées à un certain fichier n'affecteront que sa propre valeur de hachage et n'affecteront pas les autres fichiers.

Donc, si vous emballez simplement tout dans le même fichier, alors le hachage peut vous satisfaire. Si votre projet implique le déballage, le chargement de modules, etc., alors vous devez utiliser chunkhash pour vous en assurer. que seule la valeur de hachage du fichier pertinente change après chaque mise à jour.

Donc, notre configuration webpack avec cache persistant devrait ressembler à ceci :

module.exports = {
 entry: __dirname + '/src/index.js',
 output: {
 path: __dirname + '/dist',
 filename: '[name].[chunkhash:8].js',
 }
}

La signification du code ci-dessus est : utilisez index.js comme point d'entrée pour empaqueter tout le code Créer un fichier nommé index.xxxx.js et placez-le dans le répertoire dist. Nous pouvons désormais générer un fichier nouvellement nommé à chaque fois que nous mettons à jour le projet.

Si vous avez affaire à des scénarios simples, cela suffit, mais dans les grandes applications multipages, nous avons souvent besoin d'optimiser les performances de la page :

1. Séparer Code métier et code tiers : la raison pour laquelle nous séparons le code métier et le code tiers est que le code métier est mis à jour fréquemment et que les mises à jour et les itérations du code tiers sont lentes, nous séparons donc le code tiers (bibliothèques, frameworks), qui peut utiliser pleinement le cache du navigateur pour charger des bibliothèques tierces.

2. Chargement à la demande : Par exemple, lors de l'utilisation de React-Router, lorsque l'utilisateur a besoin d'accéder à un certain itinéraire, le composant correspondant sera alors chargé. au début, tous les composants de routage seront téléchargés localement.

3. Dans les applications multipages, nous pouvons souvent extraire des modules communs, tels que l'en-tête, le pied de page, etc., de sorte que lorsque la page saute, ces modules communs existent dans le cache, vous peut le charger directement au lieu de faire une requête réseau.

Alors, comment décompresser et charger dans des modules, cela nécessite le plug-in intégré de webpack : CommonsChunkPlugin Ci-dessous, j'utiliserai un exemple pour expliquer comment configurer webpack.

Le code de cet article est sur mon Github Si vous êtes intéressé, vous pouvez le télécharger et y jeter un œil :

git clone https://github.com/happylindz/blog.git
cd blog/code/multiple-page-webpack-demo
npm install

Avant de lire le contenu suivant, je vous recommande fortement. lisez mes articles précédents : Une compréhension approfondie du mécanisme d'empaquetage de fichiers Webpack vous aidera à mieux implémenter la mise en cache persistante.

L'exemple est grossièrement décrit comme ceci : il se compose de deux pages pageA et pageB

// 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";

Le contenu de la page ci-dessus implique essentiellement les trois modes de fractionnement de nos modules : Spliter les bibliothèques communes, charger et divisez les modules communs à la demande. Ensuite, l'étape suivante consiste à configurer le 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`,
 }),
 ]
}

Le premier CommonsChunkPlugin est utilisé pour extraire les modules publics, ce qui équivaut à parler du patron du webpack. Si vous voyez un module chargé deux fois ou plus, alors. S'il vous plaît, aidez-moi à le déplacer vers le morceau commun. Le minChunks ici est de 2, et la granularité est la plus petite. Vous pouvez choisir combien de fois utiliser les modules avant de les extraire en fonction de votre situation réelle.

Le deuxième CommonsChunkPlugin est utilisé pour extraire des codes tiers, les extraire et déterminer si les ressources proviennent de node_modules. Si tel est le cas, cela signifie qu'il s'agit de modules tiers, puis extrayez-les. Cela équivaut à dire au responsable du webpack que si vous voyez certains modules provenant du répertoire node_modules et que leurs noms se terminent par .js, veuillez les déplacer vers le bloc du fournisseur. Si le bloc du fournisseur n'existe pas, créez-en un nouveau.

Quels sont les avantages de cette configuration ? À mesure que notre activité se développe, nous sommes susceptibles de nous appuyer de plus en plus sur des codes de bibliothèques tierces. Si nous configurons spécialement une entrée pour stocker du code tiers, alors notre webpack. .config.js deviendra :

// 不利于拓展
module.exports = {
 entry: {
 app: './src/main.js',
 vendor: [
  'vue',
  'axio',
  'vue-router',
  'vuex',
  // more
 ],
 },
}

Le troisième plug-in ExtractTextPlugin est utilisé pour extraire le CSS du fichier js emballé et générer un fichier CSS indépendant. Imaginez que lorsque vous modifiez simplement le style, la logique fonctionnelle de la page n'est pas modifiée. Vous ne voulez certainement pas que la valeur de hachage de votre fichier js change. Vous voulez absolument que CSS et js soient séparés les uns des autres et ne s'affectent pas.

运行 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 值变化主要由以下四个部分引起的：

1. 包含模块的源代码

2. webpack 用于启动运行的 runtime 代码

3. webpack 生成的模块 moduleid(包括包含模块 id 和被引用的依赖模块 id)

4. 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 做缓存的一些注意点

1. CSS 文件 hash 值失效的问题

2. 不建议线上发布使用 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 本身有几个缺点：

1. 首先你需要额外多配置一份 webpack 配置，增加工作量。

2. 其中一个页面用到了一个体积很大的第三方依赖库而其它页面根本不需要用到，但若直接将它打包在 dll.js 里很不值得，每次页面打开都要去加载这段无用的代码，无法使用到 webpack2 的 Code Splitting 功能。

3. 第一次打开的时候需要下载 dll 文件，因为你把很多库全部打在一起了，导致 dll 文件很大，首次进入页面加载速度很慢。

虽然你可以打包成 dll 文件，然后让浏览器去读取缓存，这样下次就不用再去请求，比如你用 lodash 其中一个函数，而你用dll会将整个 lodash 文件打进去，这就会导致你加载无用代码过多，不利于首屏渲染时间。

我认为的正确的姿势是：

1. 像 React、Vue 这样整体性偏强的库，可以生成 vendor 第三方库来去做缓存，因为你一般技术体系是固定的，一个站点里面基本上都会用到统一技术体系，所以生成 vendor 库用于缓存。

2. 像 antd、lodash 这种功能性组件库，可以通过 tree shaking 来进行消除，只保留有用的代码，千万不要直接打到 vendor 第三方库里，不然你将大量执行无用的代码。

相信看了本文案例你已经掌握了方法，更多精彩请关注php中文网其它相关文章！

推荐阅读：

JS数值类型数组去重

项目中如何使用better-scroll插件

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!