So implementiert Webpack das Caching statischer Ressourcen

Einführung

Das Zwischenspeichern statischer Ressourcen ist ein Punkt der Front-End-Leistungsoptimierung. Daher wird der Cache im Front-End-Entwicklungsprozess im Allgemeinen maximal genutzt (hier hauptsächlich starkes Zwischenspeichern). Zurück zum Thema dieses Artikels: Wenn Sie in einem mit Webpack erstellten Projekt nicht aufpassen, kann das erstellte Projekt möglicherweise kein statisches Ressourcen-Caching erreichen, selbst wenn der Server eine Cache-Strategie festlegt. Wie kann Webpack also den Effekt der Cache-Nutzung erzielen? Lassen Sie uns weiter unten über dieses Problem sprechen.

Unterscheiden Sie zwischen mehreren verschiedenen Hashes

Wir alle wissen, dass Webpack verschiedene Hashwerte hat, darunter hash jedes Projektbuilds, den chunkhash verschiedener Einträge und contenthash des Dateiinhalts. Was sind bei so vielen Hashes die Unterschiede zwischen ihnen?

Hash

Hash bezieht sich auf das gesamte Webpack-Build-Projekt. Der dem Hash entsprechende Wert ist bei jedem Erstellen des Projekts unterschiedlich, auch wenn die Projektdatei nicht „geändert“ wurde.

Tatsächlich wurde es geändert, da jedes Mal, wenn Webpack gepackt und kompiliert wird, der Webpack-Laufzeitcode eingefügt wird, was zu Änderungen am gesamten Projekt führt, sodass sich der Hash-Wert jedes Mal ändert.

Am Beispiel meines Projektcodes folgt hier ein Vergleich des Codes vor und nach zwei Builds ohne jegliche Änderungen.

Es ist ersichtlich, dass sich der Hash der entsprechenden Projektbuilds zweimal geändert hat. Daraus lässt sich schließen, dass mit dieser Methode kein Caching erreicht werden kann, da sich der Hash jedes Mal ändert.

chunkhash

Chunkhash ist, wie der Name schon sagt, mit dem von webpack gepackten Chunk verwandt. Insbesondere analysiert webpack die Abhängigkeiten der Eintragskonfigurationsdatei, erstellt darauf basierend den Eintragsblock und generiert den entsprechenden Hashwert. Verschiedene Chunks haben unterschiedliche Hashwerte. Im Allgemeinen werden in einem Projekt die öffentliche Abhängigkeitsbibliothek und die Programmeintragsdateien isoliert und separat verpackt, und Chunkhash wird zum Generieren von Hash-Werten verwendet. Solange die öffentliche Abhängigkeitsbibliothek unverändert bleibt, ändert sich der entsprechende Chunkhash nicht, wodurch der Zweck des Caching erreicht wird.

Im Allgemeinen wird Chunkhash für Webpack-Einträge im Projekt verwendet, was sich speziell im Ausgabekonfigurationselement widerspiegelt:

modul.exporte = {
  Eintrag: {
   App: './src/main.js',
   Anbieter: ['reagieren', 'Redux', 'reagieren-dom', 'reagieren-redux', 'reagieren-router-redux']
  },
  Ausgabe: {
    Pfad:Pfad.join(__dirname, '/dist/js'),
    Dateiname: „[name].[chunkhash].js“
  }
 ...
}

Schließlich lauten die Ergebnisse der Chunkhash-Kompilierung von App und Anbieter wie folgt

Inhaltshash

Contenthash stellt den vom Dateiinhalt generierten Hashwert dar. Unterschiedliche Inhalte generieren unterschiedliche Contenthash-Werte. In einem Projekt besteht die übliche Vorgehensweise darin, das CSS im Projekt zur Referenz in entsprechende CSS-Dateien zu extrahieren. Verwenden Sie es beispielsweise in einer Webpack-Konfiguration wie folgt:

modul.exporte = {
  ...
  Plugins: [
     neues ExtractTextPlugin({
	Dateiname: 'static/[name]_[chunkhash:7].css',
	deaktivieren: false,
	allChunks: wahr
     })
  ...
  ]

Bei der obigen Konfiguration besteht ein Problem, da Chunkhash verwendet wird und Chunkhash mit davon abhängigen Chunks geteilt wird.

Im obigen App-Chunk-Beispiel hängt es beispielsweise von einer index.css-Datei ab. Der Hash von index.css folgt dem Chunkhash der App. Solange sich die App-Datei ändert, ändert sich auch ihr Hashwert, selbst wenn sich die index.css-Datei nicht ändert, was zu einem Cache-Fehler führt.

Dann können wir den contenthash -Wert im Extra-Text-Webpack-Plugin verwenden, um sicherzustellen, dass sich der Hash-Wert nicht ändert, auch wenn sich der Inhalt anderer Dateien im Modul ändert, in dem sich die CSS-Datei befindet, solange der Inhalt der CSS-Datei unverändert bleibt.

Implementieren des JS-Cache

Die Hauptfunktion des Webpack-Plugins CommonsChunkPlugin besteht darin, den gemeinsamen Teil des Webpack-Projekteintragsblocks zu extrahieren. Die spezifische Verwendung wird nicht im Detail vorgestellt. Wenn Sie nicht viel darüber wissen, können Sie die Einführung auf der offiziellen Webpack-Website lesen.

Dieses Plug-In ist eine häufig verwendete Optimierungsfunktion in Webpack-Projekten und wird in fast jedem Webpack-Projekt verwendet. Vorteile der Verwendung dieses Plugins:

• Verbessern Sie die Verpackungsgeschwindigkeit und Projektgröße von Webpack: Extrahieren Sie alle gängigen Codes aus der Chunk-Datei am Webpack-Eintrag, um die Codegröße zu reduzieren und gleichzeitig die Verpackungsgeschwindigkeit von Webpack zu verbessern.
• Nutzen Sie den Cache-Mechanismus: Abhängige öffentliche Moduldateien werden im Allgemeinen selten oder nie geändert, sodass unabhängige Moduldateien extrahiert und für lange Zeit zwischengespeichert werden können.

Wenn das Plug-In im Projekt jedoch falsch geöffnet wird, kann der zweite oben genannte Punkt nicht erreicht werden, da in diesem Fall:

Der mit dem öffentlichen Code oder dem Bibliothekscode gepackte Entry Chunk, der nicht geändert wurde, ändert sich mit den Änderungen anderer Geschäftscodes, was dazu führt, dass der Long-Cache-Mechanismus auf der Seite fehlschlägt.

Öffnen wir also CommonsChunkPlugin richtig.

Falsche Verwendung von CommonsChunkPlugin

Wenn wir die gemeinsamen Bibliotheken unseres Projekts wie React, React-Dom und React-Router vom Geschäftscode isolieren und sie als Vendor-Chunks extrahieren, sieht die Webpack-Konfiguration wie folgt aus:

const webpack = erfordern("webpack");
const path = require('Pfad');
modul.exporte = {
  Eintrag: {
    App: "./src/main.js",
    Anbieter: ["reagieren", "reagieren-dom", "redux", "reagieren-redux", "reagieren-router-redux"]
  },
  Ausgabe: {
    Pfad: Pfad.auflösen(__dirname, 'Ausgabe'),
    Dateiname: "[name].[chunkhash].js"
  },
  Plugins: [
    neues webpack.optimize.CommonsChunkPlugin({Namen: ["Anbieter"]})
  ]
};

Oben werden einige grundlegende Bibliotheken des Projekts in einem Block namens „Vendor“ und geschäftsbezogene Codes in einem Block namens „App“ gepackt.

Die Ergebnisse der Webpack-Verpackung und -Kompilierung sind wie folgt:

Nachdem wir den Geschäftscode app.js geändert haben, sind die Ergebnisse der Neukompilierung wie folgt:

Es kann festgestellt werden, dass sich unter der Konfiguration von CommonsChunkPlugin, wenn sich die Geschäftscode-App ändert, auch der Bibliothekscode ändert und sich auch der Chunkhash des Anbieters ändert. Auf diese Weise ändert sich der Name der Anbieterreferenz, was dazu führt, dass der lange Cache-Mechanismus im Browser fehlschlägt.

Was verursacht das Problem

Die Gründe, warum sich der Anbieter bei jeder Kompilierung von Webpack ändert:

Bei jedem Build generiert Webpack Laufzeitcode. Wenn nur eine Datei vorhanden ist, wird der Laufzeitcode direkt in diese Datei eingefügt. Wenn mehrere Dateien vorhanden sind, wird der Laufzeitcode in die gemeinsame Datei extrahiert, d. h. in den Vendor-Chunk, der oben durch CommonsChunkPlugin konfiguriert wurde.

Den von webpack bei jeder Kompilierung generierten Laufzeitcode, einschließlich der Definition der globalen webpackJsonp-Methode und der Verwaltung der Modulabhängigkeiten, finden Sie hier>>.

Daher werden diese Codes in der CommonsChunkPlugin-Konfiguration von webpack oben bei jeder Kompilierung in den Anbieter gepackt, was dazu führt, dass sich der Chunkhash des Anbieters jedes Mal ändert.

Anschließend können wir den Vendor-Block konfigurieren und den gemeinsamen Code, also den Webpack-Laufzeitcode, extrahieren, sodass die grundlegenden Bibliotheksmodule, von denen das Projekt abhängt, von den Geschäftsmodulen isoliert werden können. Da diese Dateien nicht geändert werden, können sie den Effekt eines langen Caches erzielen. Die konkrete Konfiguration ist wie folgt:

modul.exporte = {
  Eintrag: {
    App: "./app.js",
    Anbieter: ["reagieren", "reagieren-dom", "redux", "reagieren-redux", "reagieren-router-redux"]
  },
  ....
  Plugins: [
    neues webpack.optimize.CommonsChunkPlugin({Namen: ["Anbieter"]}),
    neues webpack.optimize.CommonsChunkPlugin({
        Name: "Manifest",
        Brocken: ['Anbieter']
    })
  ]
};

Auf diese Weise ändert sich der Vendor-Block der Basisbibliothek, von der das Projekt abhängt, auch dann nicht, wenn der Code der Geschäftsanwendung geändert wird. Jedes Mal ändert sich lediglich der extrahierte Manifest-Block. Die Größe dieser Datei ist jedoch sehr klein und diese Methode bietet größere Vorteile als die Vendor-Methode. Wie unten dargestellt:

Das Ergebnis der Paketkompilierung nach der Änderung des App-Codes ist wie folgt. Sie können sehen, dass sich der Vendor-Chunkhash nicht geändert hat.

Beim Konfigurieren von CommonsChunkPlugin in webpack sind einige Dinge zu beachten:

1. Wenn Sie das Ausgabeelement von Webpack konfigurieren, müssen dessen filename und chunkFilename Chunkhash verwenden. Verwenden Sie kein Hash, da sonst auch mit der obigen Konfiguration nicht der erwartete Effekt erzielt wird. Informationen zum Unterschied zwischen Hash und Chunkhash finden Sie in der Antwort von GitHub.

2. Für file-loader der zum Extrahieren statischer Ressourcen wie Bilder und Schriftarten verwendet wird, stellt der konfigurierte Hash den Inhalts-Hashwert der statischen Datei dar, nicht den Hashwert, der von webpack bei jedem Packen und Kompilieren generiert wird. Merken! ! !

3. Für die extrahierten CSS-Style-Dateien müssen Sie contenthash verwenden, was dieselbe Bedeutung hat wie Hash im file-loader . Dies darf kein Chunkhash sein, da es sonst mit dem Chunkhash des Eintrags-Chunks übereinstimmt, aus dem die Stildatei extrahiert wird, wodurch der Zweck des Cachings nicht erreicht wird.

Implementieren von CSS-Caching

Webpack implementiert CSS-Caching mithilfe des oben eingeführten Contenthash. Der Hash-Attributwert wird tatsächlich von extra-text-webpack-plugin berechnet. Um CSS-Caching zu implementieren, können Sie contenthash wie folgt verwenden

modul.exporte = {
  ...
  Plugins: [
     neues ExtractTextPlugin({
	Dateiname: 'static/[name]_[contenthash:7].css',
	deaktivieren: false,
	allChunks: wahr
     })
  ...
  ]

Implementieren Sie das Caching von Bildern/Schriftarten

Bei statischen Ressourcen wie Bildern und Schriftarten wird beim Erstellen und Extrahieren mit webpack tatsächlich file-loader zum Vervollständigen verwendet, und der entsprechende Datei-Hashwert wird vom entsprechenden file-loader berechnet. Welche Hashwerte werden also für diese statischen Dateien verwendet? Tatsächlich handelt es sich um hash -Attributwerte. Wie im folgenden Code gezeigt:

modul.exporte = {
 ...
 Regeln:
   ...
    {
      Test: /\.(gif|png|jpe?g)(\?\S*)?$/,
      Lader: require.resolve('URL-Lader'),
      Optionen:
        Grenze: 10000,
        Name: Pfad.posix.join('statisch', '[Name]_[Hash:7].[ext]')
      }
    },
    Schriftart:
      Test: /\.otf|ttf|woff2?|eot(\?\S*)?$/,
      Lader: require.resolve('URL-Lader'),
      Optionen:
        Grenze: 10000,
        Name: Pfad.posix.join('statisch', '[Name]_[Hash:7].[ext]')
      }
    }
 ]
}

Sie können sehen, dass oben der Hash-Attributwert verwendet wird. Dieser Hash ist nicht der Hash, den Webpack bei jedem Erstellen des Projekts erstellt. Er wird vom Dateilader basierend auf dem Dateiinhalt berechnet. Verwechseln Sie ihn nicht mit dem von Webpack erstellten Hash.

siehe

1. Richtiger Weg zum Öffnen des CommonsChunkPlugin von webpack
2. Webpack füllt Gruben und extrahiert Straßen, unabhängige Dateien (Module)
3. Fähigkeiten zum Aufteilen von Webpack-Code
4. Ich habe gehört, dass Sie webpack verwenden, um den Hash des Dateinamens zu verarbeiten? Dann schlage ich vor, dass Sie überprüfen, ob der von Ihnen generierte Hash korrekt ist.
5. Chunkhash
6. Mehrere Commons-Chunks
7. Verwenden Sie Webpack, um dauerhaftes Caching zu implementieren
8. Der Unterschied zwischen Hash und Chunkash in Webpack und die Hash-Fingerabdruck-Entkopplungslösung für JS und CSS

Dies ist das Ende dieses Artikels über die Implementierung des statischen Ressourcen-Cachings mit Webpack. Weitere relevante Inhalte zum statischen Ressourcen-Caching von Webpack finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!