Wie Webpack persistentes Caching implementiert

Dieses Mal zeige ich Ihnen, wie Webpack persistentes Caching implementiert. Was sind die Vorsichtsmaßnahmen für Webpack, um persistentes Caching zu implementieren?

Vorwort

Vor kurzem habe ich mir angeschaut, wie Webpack persistentes Caching durchführt, und festgestellt, dass es noch einige Fallstricke gibt, die ich danach sortieren und zusammenfassen muss Wenn Sie diesen Artikel lesen, können Sie Folgendes ungefähr verstehen:

1. Was ist persistentes Caching und warum machen wir persistentes Caching?

2. Wie funktioniert Webpack persistent? Zwischenspeichern?

3. Einige Hinweise zum Webpack-Caching.

Persistentes Caching

Zuerst müssen wir erklären, was persistentes Caching ist, im Kontext der aktuellen Beliebtheit von Anwendungen, bei denen Front-End und Unter bestimmten Umständen sind Front-End-HTML, CSS und JS häufig in Form einer statischen Ressourcendatei auf dem Server vorhanden, und Daten werden über Schnittstellen abgerufen, um dynamische Inhalte anzuzeigen. Dabei geht es um die Frage, wie das Unternehmen den Front-End-Code bereitstellt. Es handelt sich also um ein Update-Bereitstellungsproblem. Sollte zuerst die Seite bereitgestellt werden oder zuerst die Ressourcen?

Stellen Sie zuerst die Seite und dann die Ressourcen bereit: Wenn ein Benutzer während des Zeitintervalls zwischen den beiden Bereitstellungen auf die Seite zugreift, wird die alte Ressource in die neue Seitenstruktur geladen und die alte Version der Die Ressource wird als neue Version betrachtet. Wenn die Version zwischengespeichert wird, greift der Benutzer auf eine Seite mit einem ungeordneten Stil zu. Sofern sie nicht manuell aktualisiert wird, bleibt die Seite in einem ungeordneten Zustand, bis der Ressourcencache abläuft.

Zuerst Ressourcen bereitstellen, dann Seiten bereitstellen: Während des Bereitstellungszeitintervalls besuchen Benutzer mit lokal zwischengespeicherten Ressourcen älterer Versionen die Website. Da es sich bei der angeforderten Seite um eine ältere Version handelt, hat sich die Ressourcenreferenz und der Browser nicht geändert Der lokale Cache wird direkt verwendet. Dies ist normal. Wenn jedoch Benutzer ohne lokalen Cache oder abgelaufenem Cache die Website besuchen, lädt die alte Versionsseite die neue Versionsressource, was zu Fehlern bei der Seitenausführung führt.

Deshalb benötigen wir eine Bereitstellungsstrategie, um sicherzustellen, dass Online-Benutzer bei der Aktualisierung unseres Online-Codes reibungslos wechseln und unsere Website korrekt öffnen können.

Es wird empfohlen, zuerst diese Antwort zu lesen: Wie kann man Front-End-Code in einem großen Unternehmen entwickeln und bereitstellen?

Nachdem Sie die obige Antwort gelesen haben, werden Sie ungefähr verstehen, dass die ausgereiftere Lösung für persistentes Caching jetzt darin besteht, einen Hash-Wert nach dem Namen der statischen Ressource hinzuzufügen, da der Hash-Wert bei jeder Änderung der Datei generiert wird Dies hat den Vorteil, dass Dateien inkrementell veröffentlicht werden, um zu vermeiden, dass vorherige Dateien überschrieben werden und der Online-Benutzerzugriff fehlschlägt.

Denn solange die Namen der jedes Mal veröffentlichten statischen Ressourcen (css, js, img) eindeutig sind, kann ich:

1. Für HTML-Dateien: Tun Aktivieren Sie das Caching nicht, legen Sie den HTML-Code auf Ihrem eigenen Server ab, schalten Sie den Cache des Servers aus. Ihr Server stellt nur HTML-Dateien und Datenschnittstellen bereit.

2. Für statische JS-, CSS-, Bilder usw. Datei : Aktivieren Sie CDN und Caching und laden Sie statische Ressourcen zum CDN-Dienstanbieter hoch. Da der Pfad jeder Ressource eindeutig ist, wird die Ressource nicht überschrieben, wodurch die Online-Stabilität gewährleistet wird Benutzerzugriff.

3. Jedes Mal, wenn ein Update veröffentlicht wird, werden zuerst die statischen Ressourcen (js, css, img) an den CDN-Dienst übertragen und dann die HTML-Datei hochgeladen. Dadurch wird sichergestellt, dass alte Benutzer Mit dem normalen Zugriff können neue Benutzer neue Seiten sehen.

Das Obige stellt kurz die gängige Front-End-Lösung für persistentes Caching vor. Warum müssen wir also persistentes Caching durchführen?

Wenn ein Benutzer unsere Website zum ersten Mal mit einem Browser besucht, führt die Seite eine Vielzahl statischer Ressourcen ein. Wenn wir dauerhaftes Caching erreichen können, können wir Cache- im HTTP-Antwort-Header hinzufügen Feld zum Festlegen des Caches, der Browser kann diese Ressourcen einzeln lokal zwischenspeichern.

Wenn der Benutzer bei nachfolgenden Besuchen dieselbe statische Ressource erneut anfordern muss und die statische Ressource nicht abgelaufen ist, kann der Browser direkt den lokalen Cache verwenden, anstatt die Ressource über das Netzwerk anzufordern.

Wie Webpack persistentes Caching durchführt

Nachdem wir das persistente Caching kurz vorgestellt haben, ist das Folgende der entscheidende Punkt. Wie sollten wir also persistentes Caching im Webpack durchführen? Nun, das müssen wir tun Führen Sie die folgenden zwei Dinge aus:

1. Stellen Sie sicher, dass der Hashwert eindeutig ist, dh für jede verpackte Ressource einen eindeutigen Hashwert generiert Hashwerte sind inkonsistent.

2. Um die Stabilität des Hash-Werts sicherzustellen, müssen wir sicherstellen, dass sich beim Ändern eines Moduls nur der Hash-Wert der betroffenen gepackten Datei ändert und der Hash-Wert der gepackten Datei nichts damit zu tun hat Das Modul bleibt unverändert.

Hash-Dateiname ist der erste Schritt zur Implementierung von persistentem Caching. Derzeit verfügt Webpack über zwei Möglichkeiten, Hash zu berechnen ([hash] und [chunkhash])

1. Hash bedeutet, dass jedes Mal, wenn Webpack während des Kompilierungsprozesses einen eindeutigen Hash-Wert generiert, dieser neu erstellt wird, nachdem eine Datei im Projekt geändert wurde, und Webpack dann den neuen Hash-Wert berechnet.

2. Chunkhash ist ein Hash-Wert, der basierend auf dem Modul berechnet wird, sodass Änderungen an einer bestimmten Datei nur ihren eigenen Hash-Wert und keine anderen Dateien beeinflussen.

Wenn Sie also einfach alles in die gleiche Datei packen, kann Hash Sie zufriedenstellen. Wenn Ihr Projekt das Entpacken, Laden in Modulen usw. umfasst, müssen Sie Chunkhash verwenden, um dies sicherzustellen dass sich nach jedem Update nur der jeweilige Datei-Hashwert ändert.

Unsere Webpack-Konfiguration mit persistentem Cache sollte also so aussehen:

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

Die Bedeutung des obigen Codes ist: Verwenden Sie index.js als Einstiegspunkt, um den gesamten Code in eine Datei zu packen heißt index.xxxx.js und wird im dist-Verzeichnis abgelegt. Jetzt können wir jedes Mal, wenn wir das Projekt aktualisieren, eine neu benannte Datei generieren.

Wenn Sie mit einfachen Szenarien zu tun haben, ist dies ausreichend, aber in großen mehrseitigen Anwendungen müssen wir häufig eine Leistungsoptimierung der Seite durchführen:

1. Getrennter Geschäftscode und Code von Drittanbietern: Der Grund für die Trennung von Geschäftscode und Code von Drittanbietern liegt darin, dass der Geschäftscode häufig aktualisiert wird und der Code von Drittanbietern langsam aktualisiert und iteriert wird. Daher trennen wir den Code von Drittanbietern Code (Bibliothek, Framework), sodass der Cache des Browsers vollständig zum Laden von Bibliotheken von Drittanbietern genutzt werden kann.

2. Laden bei Bedarf: Wenn der Benutzer beispielsweise React-Router verwendet und auf eine bestimmte Route zugreifen muss, wird die entsprechende Komponente geladen. Dann muss der Benutzer nicht laden Zu Beginn werden alle Routing-Komponenten lokal heruntergeladen.

3. In mehrseitigen Anwendungen können wir häufig gemeinsame Module wie Kopfzeile, Fußzeile usw. extrahieren, sodass diese gemeinsamen Module beim Seitenwechsel im Cache vorhanden sind kann es direkt laden, anstatt eine Netzwerkanfrage zu stellen.

Für das Entpacken und Laden in Module ist das integrierte Plug-in des Webpacks erforderlich: CommonsChunkPlugin. Im Folgenden erkläre ich anhand eines Beispiels, wie das Webpack konfiguriert wird.

Der Code dieses Artikels befindet sich auf meinem Github. Wenn Sie interessiert sind, können Sie ihn herunterladen und ansehen:

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

Bevor Sie den folgenden Inhalt lesen, empfehle ich Ihnen dringend, meinen zu lesen Vorheriger Artikel: Ein umfassendes Verständnis des Webpack-Dateipaketierungsmechanismus hilft Ihnen, persistentes Caching besser zu implementieren.

Das Beispiel wird grob so beschrieben: Es besteht aus zwei Seiten, SeiteA und SeiteB

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

Der Inhalt der obigen Seite umfasst im Wesentlichen die drei Arten der Aufteilung unserer Module: Aufteilung der öffentlichen Bibliothek , Laden und Aufteilen gemeinsamer Module nach Bedarf. Dann besteht der nächste Schritt darin, das Webpack zu konfigurieren:

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`,
 }),
 ]
}

Das erste CommonsChunkPlugin wird zum Extrahieren öffentlicher Module verwendet, was gleichbedeutend damit ist, Webpack-Chef zu sagen: Wenn Sie sehen, dass ein Modul zweimal oder öfter geladen wird, dann helfen Sie mir bitte beim Umzug Es beträgt hier 2 minChunks und die Granularität ist die kleinste. Sie können auswählen, wie oft Sie die Module verwenden möchten, bevor Sie sie entsprechend Ihrer tatsächlichen Situation extrahieren.

Das zweite CommonsChunkPlugin wird verwendet, um Codes von Drittanbietern zu extrahieren, sie zu extrahieren und festzustellen, ob die Ressourcen von node_modules stammen. Wenn ja, bedeutet dies, dass es sich um Module von Drittanbietern handelt, und extrahieren Sie sie. Dies entspricht der Anweisung an den Webpack-Chef, dass Sie, wenn Sie sehen, dass einige Module aus dem Verzeichnis „node_modules“ stammen und deren Namen mit „.js“ enden, sie bitte in den „Vendor Chunk“ verschieben. Wenn der „Vendor Chunk“ nicht vorhanden ist, erstellen Sie einen neuen.

Was sind die Vorteile dieser Konfiguration? Wenn unser Unternehmen wächst, werden wir wahrscheinlich immer mehr Bibliothekscodes von Drittanbietern verwenden. Wenn wir einen Eingang speziell zum Speichern von Code von Drittanbietern konfigurieren, dann unser Webpack .config.js wird zu:

// 不利于拓展
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 值变化主要由以下四个部分引起的：

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 第三方库里，不然你将大量执行无用的代码。

Fazit

Okay, ich habe das Gefühl, dass ich in letzter Zeit wirklich viel durch das Lesen von Webpack gewonnen habe kann aus dem geernteten Artikel lernen. Darüber hinaus empfehle ich noch einmal den Artikel, den ich zuvor geschrieben habe, der Ihnen helfen kann, den Datei-Caching-Mechanismus besser zu verstehen: Vertiefendes Verständnis des Webpack-Dateipaketierungsmechanismus

Ich glaube, Sie haben die Methode beherrscht, nachdem Sie den Fall gelesen haben Bitte achten Sie auf weitere spannende Artikel auf der chinesischen PHP-Website!

Empfohlene Lektüre:

Zusammenfassung gängiger JS-Funktionen

Welche Methoden gibt es für die Node.js-Registrierungs-E-Mail-Aktivierung

Das obige ist der detaillierte Inhalt vonWie Webpack persistentes Caching implementiert. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!