Finden des richtigen Weges zum Trennen von Website-Inhalten mithilfe von Webpack

Den besten Weg zu finden, um Webprojektmaterialien zu organisieren, kann eine entmutigende Aufgabe sein. Es gibt viele verschiedene Szenarien für Benutzer, um mit Projekten zu arbeiten, viele Technologien und andere Faktoren, die berücksichtigt werden müssen.

Der Autor des Materials, dessen Übersetzung wir heute veröffentlichen, sagt, dass er hier alles erzählen möchte, was Sie für die kompetente Vorbereitung von Webprojektmaterialien für die Arbeit wissen müssen. Zunächst geht es darum, wie Sie eine Strategie zum Trennen von Site-Dateien auswählen, die für ein bestimmtes Projekt und seine Benutzer am besten geeignet ist. Zweitens werden die Mittel zur Umsetzung der gewählten Strategie geprüft.

Allgemeine Informationen

Laut dem Webpack-Glossar gibt es zwei Strategien für die gemeinsame Nutzung von Dateien. Dies ist Bundle-Splitting und Code-Splitting. Diese Begriffe scheinen austauschbar zu sein, sind es aber nicht.

• Das Aufteilen eines Bundles ist eine Technik zum Aufteilen großer Bundles in mehrere Teile, bei denen es sich um kleinere Dateien handelt. Solche Dateien werden in jedem Fall, wenn Sie mit einem einzelnen Bundle arbeiten, von allen Benutzern der Site heruntergeladen. Die Stärke dieser Technik besteht darin, die Verwendung browserbasierter Caching-Mechanismen zu verbessern.
• Die Codetrennung ist ein Ansatz, bei dem der Code bei Bedarf dynamisch geladen wird. Dies führt dazu, dass der Benutzer nur den Code herunterlädt, den er benötigt, um zu einem bestimmten Zeitpunkt mit einem bestimmten Teil der Site zu arbeiten.

Die Code-Aufteilung scheint viel interessanter zu sein als die Code-Aufteilung. Tatsächlich besteht das Gefühl, dass in vielen Artikeln zu unserem Thema der Schwerpunkt auf der Trennung von Code liegt. Diese Technik wird als der einzig sinnvolle Weg zur Optimierung von Site-Materialien angesehen.

Ich möchte jedoch sagen, dass es für viele Websites die erste Strategie ist, die viel wertvoller ist - die Trennung von Bündeln. Und vielleicht können buchstäblich alle Webprojekte von ihrer Implementierung profitieren.

Lassen Sie uns näher darauf eingehen.

Trennung von Bündeln

Die Technik zum Teilen von Bündeln basiert auf einer sehr einfachen Idee. Wenn Sie eine große Datei haben und eine einzelne Codezeile darin ändern, muss der normale Benutzer beim nächsten Besuch der Website die gesamte Datei herunterladen. Wenn Sie diese Datei jedoch in zwei Dateien aufteilen, muss derselbe Benutzer nur die geänderte herunterladen, und die zweite Datei wird aus dem Browser-Cache entnommen.

Da die Optimierung von Site-Materialien durch Aufteilen von Bundles mit dem Caching verbunden ist, müssen Benutzer, die die Site zum ersten Mal besuchen, ohnehin alle Materialien herunterladen, sodass es für sie keinen Unterschied macht, ob diese Materialien als einzelne Datei oder als mehrere Dateien dargestellt werden .

Es scheint mir, dass zu viel über die Leistung von Webprojekten gesprochen wird, wenn Benutzer die Website zum ersten Mal besuchen. Vielleicht liegt dies zum Teil daran, dass der erste Eindruck, den das Projekt auf den Benutzer hinterlässt, wichtig ist und dass die Datenmenge, die den Benutzern beim ersten Besuch der Website übermittelt wird, einfach und bequem zu messen ist.

Wenn es um regelmäßige Besucher geht, kann es schwierig sein, die Auswirkungen der auf sie angewendeten Materialoptimierungstechniken zu messen. Aber wir müssen einfach die Konsequenzen solcher Optimierungen kennen.

Um diese Dinge zu analysieren, benötigen Sie so etwas wie eine Tabelle. Sie müssen auch eine strenge Liste von Bedingungen erstellen, unter denen wir jede der untersuchten Caching-Strategien testen können.

Hier ist ein Skript, das der allgemeinen Beschreibung im vorherigen Absatz entspricht:

• Alice besucht unsere Seite 10 Wochen lang einmal pro Woche.
• Wir aktualisieren die Seite einmal pro Woche.
• Jede Woche aktualisieren wir die Produktlistenseite.
• Darüber hinaus haben wir eine Seite mit Produktdetails, an der wir jedoch noch nicht arbeiten.
• In der fünften Woche fügen wir den Projektmaterialien ein neues npm-Paket hinzu.
• In der achten Woche aktualisieren wir eines der bereits im Projekt verwendeten npm-Pakete.

Es gibt Leute (wie mich), die versuchen, ein solches Szenario so realistisch wie möglich zu gestalten. Aber das müssen Sie nicht tun. Das reale Szenario spielt hier keine Rolle. Warum das so ist - wir werden es bald herausfinden.

▍ Ausgangsbedingungen

Angenommen, die Gesamtgröße unseres JavaScript-Pakets beträgt beachtliche 400 KB, und wir übertragen dies unter den aktuellen Bedingungen als einzelne main.js Datei an den Benutzer. Wir haben eine Webpack-Konfiguration, die im Allgemeinen der folgenden ähnelt (ich habe die Dinge entfernt, die für unsere Konversation nicht relevant sind):

 const path = require('path'); module.exports = { entry: path.resolve(__dirname, 'src/index.js'), output: {   path: path.resolve(__dirname, 'dist'),   filename: '[name].[contenthash].js', }, }; 

Webpack benennt die resultierende Datei main.js , wenn die Konfiguration einen einzelnen Eintrag enthält.

Wenn Sie keine sehr gute Vorstellung davon haben, mit dem Cache zu arbeiten, denken Sie daran, dass ich jedes Mal, main.js ich main.js hier schreibe, etwas wie main.xMePWxHo.js . Eine verrückte Folge von Zeichen ist ein Hash des Inhalts einer Datei, was in der Konfiguration als contenthash . Die Verwendung dieses Ansatzes führt dazu, dass sich beim Ändern des Codes auch die Dateinamen ändern, wodurch der Browser gezwungen wird, neue Dateien herunterzuladen.

In Übereinstimmung mit dem obigen Szenario ändert sich die contenthash Zeile des Pakets, wenn wir jede Woche einige Änderungen am Site-Code vornehmen. Infolgedessen muss Alice beim wöchentlichen Besuch unserer Website eine neue Datei mit 400 KB hochladen.

Wenn wir ein schönes Tablet (mit einer bisher nutzlosen Ergebniszeile) erstellen, das Daten zum wöchentlichen Datenvolumen enthält, das pro Datei geladen wird, erhalten wir Folgendes.


Die vom Benutzer hochgeladene Datenmenge

Als Ergebnis stellt sich heraus, dass der Benutzer in 10 Wochen 4,12 MB Code heruntergeladen hat. Dieser Indikator kann verbessert werden.

▍ Trennung von Paketen von Drittanbietern vom Hauptcode

Teilen Sie das große Paket in zwei Teile. Unser eigener Code befindet sich in der Datei main.js und Code von Drittanbietern in der Datei vendor.js . Dies ist ganz einfach. Die folgende Webpack-Konfiguration hilft uns dabei:

 const path = require('path'); module.exports = { entry: path.resolve(__dirname, 'src/index.js'), output: {   path: path.resolve(__dirname, 'dist'),   filename: '[name].[contenthash].js', }, optimization: {   splitChunks: {     chunks: 'all',   }, }, }; 

Webpack 4 versucht, dem Entwickler das Leben so einfach wie möglich zu machen. Er tut also alles, was er kann, und verlangt nicht, dass ihm genau gesagt wird, wie die Bündel in Teile zerlegt werden sollen.

Diese Art des automatischen Verhaltens des Programms führt zu einigen Freuden, wie zum Beispiel: "Nun, was für ein Reiz dieses Webpacks ist", und zu vielen Fragen im Geiste: "Was wird mit meinen Bundles gemacht?".

In jedem Fall teilt das Hinzufügen von optimization.splitChunks.chunks = 'all' zur Konfigurationskonfiguration Webpack mit, dass es alles aus node_modules und in die vendors~main.js des vendors~main.js .

Nachdem wir das Bundle so grundlegend getrennt haben, lädt Alice, die regelmäßig wöchentlich unsere Website besucht, bei jedem Besuch die Datei main.js mit 200 main.js herunter. Sie wird die Datei vendor.js nur dreimal herunterladen. Dies wird während der Besuche in der ersten, fünften und achten Woche geschehen. Hier ist die entsprechende Tabelle, in der nach dem Willen des Schicksals die Größen der vendor.js main.js und vendor.js in den ersten vier Wochen zusammenfallen und 200 main.js vendor.js .


Die vom Benutzer hochgeladene Datenmenge

Als Ergebnis stellt sich heraus, dass die vom Benutzer über 10 Wochen heruntergeladene Datenmenge 2,64 MB betrug. Das heißt, im Vergleich zu vor der Trennung des Bündels verringerte sich das Volumen um 36%. Kein so schlechtes Ergebnis durch Hinzufügen einiger Zeilen zur Konfigurationsdatei. Übrigens, bevor Sie weiterlesen - machen Sie dasselbe in Ihrem Projekt. Und wenn Sie ein Upgrade von Webpack 3 auf 4 benötigen, machen Sie es und machen Sie sich keine Sorgen, da der Vorgang recht einfach und dennoch kostenlos ist.

Es scheint mir, dass die hier betrachtete Verbesserung etwas abstrakt aussieht, da sie sich über 10 Wochen erstreckt. Wenn wir jedoch die Datenmenge berücksichtigen, die an einen treuen Benutzer gesendet wird, bedeutet dies eine ehrliche Reduzierung dieses Volumens um 36%. Dies ist ein sehr gutes Ergebnis, das jedoch verbessert werden kann.

▍ Markieren Sie Pakete in separaten Dateien

Die Datei vendor.js das gleiche Problem wie die ursprüngliche main.js Es besteht in der Tatsache, dass das Ändern eines in dieser Datei enthaltenen Pakets dazu führt, dass ein normaler Benutzer die gesamte Datei erneut herunterladen muss.

Warum erstellen wir nicht für jedes npm-Paket separate Dateien? Es ist nicht schwierig, dies zu tun. Zerlegen wir also unsere react , lodash , redux , moment usw. in separate Dateien. Die folgende Webpack-Konfiguration hilft uns dabei:

 const path = require('path'); const webpack = require('webpack'); module.exports = { entry: path.resolve(__dirname, 'src/index.js'), plugins: [   new webpack.HashedModuleIdsPlugin(), //        ], output: {   path: path.resolve(__dirname, 'dist'),   filename: '[name].[contenthash].js', }, optimization: {   runtimeChunk: 'single',   splitChunks: {     chunks: 'all',     maxInitialRequests: Infinity,     minSize: 0,     cacheGroups: {       vendor: {         test: /[\\/]node_modules[\\/]/,         name(module) {           //  ,   node_modules/packageName/not/this/part.js           //  node_modules/packageName           const packageName = module.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)[1];           //  npm- ,   ,           //  URL,        @           return `npm.${packageName.replace('@', '')}`;         },       },     },   }, }, }; 

In der Dokumentation finden Sie eine hervorragende Erklärung der hier verwendeten Konstruktionen, aber ich widme noch einige Zeit dem Erzählen einiger Dinge, da ich viel Zeit gebraucht habe, um sie richtig zu verwenden.

• Webpack verfügt über recht vernünftige Standardinstallationen, die in der Tat nicht so vernünftig sind. Beispielsweise ist die maximale Anzahl von Ausgabedateien auf 3 festgelegt, die minimale Dateigröße beträgt 30 KB (dh kleinere Dateien werden zusammengeführt). Ich habe es neu definiert.
• cacheGroups wir die Regeln fest, wie Webpack Daten in Ausgabedateien gruppieren soll. Ich habe hier eine Gruppe, vendor , die für jedes Modul verwendet wird, das von node_modules geladen node_modules . Normalerweise wird der Name für die Ausgabedatei als Zeichenfolge angegeben. Aber ich habe den name als Funktion angegeben, die für jede verarbeitete Datei aufgerufen wird. Dann nehme ich den Paketnamen aus dem Modulpfad. Als Ergebnis erhalten wir eine Datei für jedes Paket. Zum Beispiel npm.react-dom.899sadfhj4.js .
• encodeURI müssen für die Verwendung in URLs geeignet sein, damit sie in npm veröffentlicht werden können. encodeURI müssen wir die encodeURI Operation nicht für packageName . Ich bin jedoch auf ein Problem gestoßen, dass der .NET-Server sich weigert, mit Dateien zu arbeiten, deren Namen das @ -Symbol enthalten (solche Namen werden für Pakete mit einem bestimmten Namensbereich verwendet, die sogenannten Scoped-Pakete), also ich in den entsprechenden Codefragment, ich werde solche Zeichen los.

Die obige Konfiguration von Webpack ist insofern gut, als Sie es einmal konfigurieren und dann vergessen können. Es ist nicht erforderlich, bestimmte Pakete namentlich zu referenzieren, daher bleibt es nach seiner Erstellung auch bei Änderung der Zusammensetzung von Paketen relevant.

Alice, unsere regelmäßige Besucherin, main.js jede Woche main.js 200-Kilobyte- main.js ersten Besuch der Website muss sie 200 KB npm-Pakete herunterladen, muss jedoch nicht zweimal dieselben Pakete herunterladen.

Unten finden Sie eine neue Version der Tabelle mit Informationen zum Umfang der wöchentlichen Datendownloads. Durch einen seltsamen Zufall beträgt die Größe jeder Datei mit npm-Paketen 20 KB.


Die vom Benutzer hochgeladene Datenmenge

Jetzt beträgt das in 10 Wochen heruntergeladene Datenvolumen 2,24 MB. Dies bedeutet, dass wir den Leitzins um 44% verbessert haben. Das Ergebnis ist bereits sehr anständig, aber es stellt sich die Frage, ob dies möglich ist, um ein Ergebnis von mehr als 50% zu erzielen. Wenn dies passiert, wird es einfach großartig sein.

▍ Anwendungscode in Fragmente aufteilen

Wir kehren zur Datei main.js , die die unglückliche Alice ständig herunterladen muss.

Wie ich oben sagte, gibt es zwei separate Abschnitte auf unserer Website. Die erste ist eine Liste von Produkten, die zweite ist eine Seite mit detaillierten Informationen über das Produkt. Die Größe des Codes, die für jeden von ihnen eindeutig ist, beträgt 25 KB (und 150 KB Code werden sowohl dort als auch dort verwendet).

Die Produktinformationsseite kann nicht geändert werden, da wir sie bereits perfektioniert haben. Wenn wir den Code in eine separate Datei extrahieren, wird diese Datei, die meistens mit der Site arbeitet, aus dem Cache in den Browser heruntergeladen.

Darüber hinaus haben wir, wie sich herausstellte, eine riesige integrierte SVG-Datei für das Rendern von Symbolen, die bis zu 25 KB wiegt und sich nur selten ändert.

Damit muss etwas getan werden.

Wir haben manuell mehrere Einstiegspunkte erstellt und Webpack mitgeteilt, dass für jede dieser Entitäten eine separate Datei erstellt werden muss.

 module.exports = { entry: {   main: path.resolve(__dirname, 'src/index.js'),   ProductList: path.resolve(__dirname, 'src/ProductList/ProductList.js'),   ProductPage: path.resolve(__dirname, 'src/ProductPage/ProductPage.js'),   Icon: path.resolve(__dirname, 'src/Icon/Icon.js'), }, output: {   path: path.resolve(__dirname, 'dist'),   filename: '[name].[contenthash:8].js', }, plugins: [   new webpack.HashedModuleIdsPlugin(), //        ], optimization: {   runtimeChunk: 'single',   splitChunks: {     chunks: 'all',     maxInitialRequests: Infinity,     minSize: 0,     cacheGroups: {       vendor: {         test: /[\\/]node_modules[\\/]/,         name(module) {           //  ,   node_modules/packageName/not/this/part.js           //  node_modules/packageName           const packageName = module.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)[1];           //  npm- ,   ,           //  URL,        @           return `npm.${packageName.replace('@', '')}`;         },       },     },   }, }, }; 

Das hart arbeitende Webpack erstellt außerdem Dateien für die gängigen ProductList , z. B. ProductList und ProductPage , ProductPage es gibt keinen doppelten Code.

Was wir gerade getan haben, wird es Alice ermöglichen, fast jede Woche 50 Kb Verkehr zu sparen. Bitte beachten Sie, dass wir die Symbolbeschreibungsdatei in der sechsten Woche bearbeitet haben. Hier ist unser traditioneller Tisch.


Die vom Benutzer hochgeladene Datenmenge

In nur zehn Wochen wurden nur 1,815 MB Daten heruntergeladen. Dies bedeutet, dass die Verkehrseinsparungen beeindruckende 56% betrugen. In Übereinstimmung mit unserem theoretischen Szenario wird ein regulärer Benutzer immer mit dieser Einsparungsstufe arbeiten.

All dies erfolgt aufgrund von Änderungen an der Webpack-Konfiguration. Wir haben den Anwendungscode nicht geändert, um solche Ergebnisse zu erzielen.

Ich habe bereits darüber gesprochen, dass das spezifische Szenario, in dem ein solcher Test durchgeführt wird, tatsächlich keine besondere Rolle spielt. Dies wird aufgrund der Tatsache gesagt, dass unabhängig von dem verwendeten Szenario die Schlussfolgerung aus allem, worüber wir gesprochen haben, dieselbe ist: Durch die Aufteilung der Anwendung in kleine Dateien, die bei Anwendung auf ihre Architektur sinnvoll sind, können wir das Volumen der Site-Daten reduzieren. von seinen regulären Benutzern geladen.

Bald werden wir über die Codetrennung sprechen, aber zuerst möchte ich drei Fragen beantworten, über die Sie jetzt wahrscheinlich nachdenken.

▍ Frage Nummer 1. Beeinträchtigt die Notwendigkeit, viele Anforderungen auszuführen, nicht die Geschwindigkeit beim Laden der Site?

Sie können eine einfache kurze Antwort auf diese Frage geben: "Nein, es schadet nicht." Eine ähnliche Situation führte früher zu einem Problem, als das HTTP / 1.1-Protokoll verwendet wurde, und wenn HTTP / 2 verwendet wurde, ist dies nicht mehr relevant.

Es sollte jedoch beachtet werden, dass in diesem Artikel, der 2016 veröffentlicht wurde, und in diesem Artikel der Khan Academy 2015 die Schlussfolgerungen gezogen werden, dass selbst bei Verwendung von HTTP / 2 die Verwendung zu vieler Dateien den Download verlangsamt. Aber in diesen beiden Materialien bedeutet "zu viel" "mehrere hundert". Beachten Sie daher, dass Einschränkungen bei der parallelen Datenverarbeitung die Download-Geschwindigkeit beeinträchtigen können, wenn Sie mit Hunderten von Dateien arbeiten müssen.

Wenn Sie interessiert sind, ist die HTTP / 2-Unterstützung in IE 11 unter Windows 10 verfügbar. Außerdem habe ich eine umfassende Studie unter denjenigen durchgeführt, die ältere Systeme verwenden. Sie erklärten einstimmig, dass die Ladegeschwindigkeit ihrer Website nicht besonders besorgniserregend sei.

▍ Frage Nummer 2. Webpack-Bundles haben Hilfecode. Erzeugt es eine zusätzliche Belastung des Systems?

Ja das stimmt.

▍ Frage Nummer 3. Wenn Sie mit vielen kleinen Dateien arbeiten, verschlechtert sich deren Komprimierungsgrad, oder?

Ja, das stimmt auch. In der Tat möchte ich Folgendes sagen:

• Mehr Dateien bedeuten mehr Webpack-Hilfecode.
• Mehr Dateien bedeuten weniger Komprimierung.

Lassen Sie es uns herausfinden, um zu verstehen, wie schlimm das ist.

Ich habe gerade einen Test durchgeführt, bei dem der Code aus einer 190-KB-Datei in 19 Teile aufgeteilt wurde. Dies erhöhte die an den Browser gesendete Datenmenge um etwa 2%.

Infolgedessen stellt sich heraus, dass der Benutzer beim ersten Besuch der Website 2% mehr Daten hochlädt und bei nachfolgenden Besuchen 60% weniger, und dies wird sehr, sehr lange so bleiben.
Lohnt es sich also, sich Sorgen zu machen? Nein, das ist es nicht wert.

Als ich ein System mit 1 Datei und ein System mit 19 Dateien verglichen habe, habe ich es mit verschiedenen Protokollen getestet, einschließlich HTTP / 1.1. Die folgende Tabelle unterstützt nachdrücklich die Idee, dass mehr Dateien besser sind.


Daten zur Arbeit mit 2 Versionen einer Site, die auf einem statischen Firebase-Hosting gehostet wird, dessen Code 190 KB groß ist, im ersten Fall jedoch in eine Datei gepackt und im zweiten Fall in 19 Dateien unterteilt ist

Bei der Arbeit in 3G- und 4G-Netzwerken dauerte das Herunterladen einer Site mit 19 Dateien 30% kürzer als das Herunterladen einer Site mit einer Datei.

Die in der Tabelle dargestellten Daten enthalten viel Rauschen. Beispielsweise dauerte eine Sitzung zum Herunterladen einer Site mit 4G (Lauf 2 in der Tabelle) 646 ms, eine andere (Lauf 4) - 1116 ms, was 73% länger ist. Daher besteht das Gefühl, dass es etwas unehrlich ist, zu sagen, dass HTTP / 2 „30% schneller“ ist.

Ich habe diese Tabelle erstellt, um zu sehen, was die Verwendung von HTTP / 2 bietet. Tatsächlich kann hier jedoch nur gesagt werden, dass die Verwendung von HTTP / 2 das Laden von Seiten wahrscheinlich nicht besonders stark beeinflusst.

Die letzten beiden Zeilen in dieser Tabelle waren eine echte Überraschung. Hier sind die Ergebnisse für nicht die neueste Version von Windows mit IE11 und HTTP / 1.1. Wenn ich versuchen würde, die Testergebnisse im Voraus vorherzusagen, würde ich definitiv sagen, dass eine solche Konfiguration Materialien viel langsamer als andere laden würde. Zwar wurde hier eine sehr schnelle Netzwerkverbindung verwendet, und ich sollte für solche Tests wahrscheinlich etwas Langsameres verwenden.

Und jetzt erzähle ich Ihnen eine Geschichte. Um meine Website auf einem sehr alten System zu erkunden, habe ich die virtuelle Windows 7-Maschine von der Microsoft- Website heruntergeladen . Dort wurde IE8 installiert, und ich entschied mich für ein Upgrade auf IE9. Zu diesem Zweck habe ich die Microsoft-Seite aufgerufen, auf der IE 9 heruntergeladen werden soll. Dies konnte ich jedoch nicht tun.


Das Pech ...

Wenn wir über HTTP / 2 sprechen, möchte ich übrigens beachten, dass dieses Protokoll in Node.js integriert ist. Wenn Sie experimentieren möchten, können Sie den kleinen HTTP / 2-Server verwenden, den ich mit Unterstützung für den Antwortcache, gzip und brotli geschrieben habe.

Vielleicht habe ich alles gesagt, was ich über die Methode der Bündeltrennung wollte. Ich denke, dass das einzige Minus dieses Ansatzes, bei dem Benutzer viele Dateien hochladen müssen, tatsächlich kein solches „Minus“ ist.

Lassen Sie uns nun über die Codetrennung sprechen.

Codetrennung

Die Hauptidee der Code-Aufteilungstechnik lautet: „Laden Sie keinen unnötigen Code herunter.“ Mir wurde gesagt, dass die Verwendung dieses Ansatzes nur für einige Websites sinnvoll ist.

Wenn es um die Codetrennung geht, bevorzuge ich die 20/20-Regel, die ich gerade formuliert habe. Wenn ein Teil der Website nur von 20% der Benutzer besucht wird und die Funktionalität von mehr als 20% des JavaScript-Codes der Website bereitgestellt wird, muss dieser Code nur auf Anfrage heruntergeladen werden.

Dies sind natürlich keine absoluten Zahlen, sie können an eine bestimmte Situation angepasst werden, und in Wirklichkeit gibt es viel komplexere Szenarien als die oben beschriebenen. Das Wichtigste dabei ist das Gleichgewicht. Es ist völlig normal, überhaupt keine Codetrennung zu verwenden, wenn dies für Ihre Website keinen Sinn ergibt.

▍ Getrennt oder nicht?

Wie finde ich die Antwort auf die Frage, ob Sie eine Codetrennung benötigen oder nicht? Angenommen, Sie haben einen Online-Shop und überlegen, ob Sie den Code, mit dem Zahlungen von Kunden eingehen, vom Rest des Codes trennen sollen, da nur 30% der Besucher etwas von Ihnen kaufen.

Was kann ich sagen Zunächst sollten Sie daran arbeiten, den Laden zu füllen und etwas zu verkaufen, das für mehr Besucher der Website interessant wäre. Zweitens müssen Sie verstehen, wie viel Code für den Abschnitt der Website, in dem die Zahlung akzeptiert wird, vollständig eindeutig ist. Da Sie vor dem „Code-Splitting“ immer eine „Bundle-Aufteilung“ durchführen sollten und dies hoffentlich tun, wissen Sie wahrscheinlich bereits, welche Größen der Code hat, an dem wir interessiert sind.

Möglicherweise ist dieser Code kleiner als Sie denken. Bevor Sie sich also über die neue Möglichkeit zur Optimierung Ihrer Website freuen, sollten Sie alles sicher berechnen. Wenn Sie beispielsweise über eine React-Site verfügen, werden das Repository, die Reduzierungen, das Routing-System und die Aktionen von allen Teilen der Site gemeinsam genutzt. Einzigartig für verschiedene Teile des Site-Codes werden hauptsächlich Komponenten und Hilfsfunktionen für diese dargestellt.

Sie haben also herausgefunden, dass ein völlig eindeutiger Code des Site-Abschnitts, mit dem Einkäufe bezahlt werden, 7 KB benötigt. Die Größe des restlichen Site-Codes beträgt 300 KB. In einer solchen Situation würde ich aus mehreren Gründen keine Codetrennung durchführen:

• Wenn Sie diese 7 KB im Voraus herunterladen, wird die Website nicht langsamer. Denken Sie daran, dass Dateien parallel heruntergeladen werden, und versuchen Sie, den Unterschied zu messen, der zum Herunterladen von 300 KB und 307 KB Code erforderlich ist.
• Wenn Sie diesen Code später herunterladen, muss der Benutzer warten, nachdem er auf die Schaltfläche "Bezahlen" geklickt hat. Und genau in diesem Moment muss alles so reibungslos wie möglich verlaufen.
• Die Codetrennung erfordert Änderungen an der Anwendung. Im Code wird an Stellen, an denen zuvor alles synchron ausgeführt wurde, asynchrone Logik angezeigt. , , , , , .

, , , .

.

▍

, , , .

. , . :

 require('whatwg-fetch'); require('intl'); require('url-polyfill'); require('core-js/web/dom-collections'); require('core-js/es6/map'); require('core-js/es6/string'); require('core-js/es6/array'); require('core-js/es6/object'); 

index.js , :

 import './polyfills'; import React from 'react'; import ReactDOM from 'react-dom'; import App from './App/App'; import './index.css'; const render = () => { ReactDOM.render(<App />, document.getElementById('root')); } render(); // ,      

Webpack , , npm-. 25 , 90% , .

Webpack 4 import() ( import ), :

 import React from 'react'; import ReactDOM from 'react-dom'; import App from './App/App'; import './index.css'; const render = () => { ReactDOM.render(<App />, document.getElementById('root')); } if ( 'fetch' in window && 'Intl' in window && 'URL' in window && 'Map' in window && 'forEach' in NodeList.prototype && 'startsWith' in String.prototype && 'endsWith' in String.prototype && 'includes' in String.prototype && 'includes' in Array.prototype && 'assign' in Object && 'entries' in Object && 'keys' in Object ) { render(); } else { import('./polyfills').then(render); } 

, , , — . — render() . , Webpack npm-, , render() .

, import() Babel dynamic-import . , Webpack, import() , .

, . .

▍ React,

. , , , .

, npm- . , , 100 .

, , URL /admin , <AdminPage> . Webpack , import AdminPage from './AdminPage.js' .

. , , import('./AdminPage.js') , Webpack , .

, .

, , AdminPage , , URL /admin . , :

 import React from 'react'; class AdminPageLoader extends React.PureComponent { constructor(props) {   super(props);   this.state = {     AdminPage: null,   } } componentDidMount() {   import('./AdminPage').then(module => {     this.setState({ AdminPage: module.default });   }); } render() {   const { AdminPage } = this.state;   return AdminPage     ? <AdminPage {...this.props} />     : <div>Loading...</div>; } } export default AdminPageLoader; 

. (, URL /admin ), ./AdminPage.js , .

render() , <AdminPage> , <div>Loading...</div> , <AdminPage> , .

, react-loadable , React .

Zusammenfassung

, , (, , CSS). :

• — .
• , — .

Liebe Leser! ?