Wie Sie wahrscheinlich wissen, ist ein einzelner monolithischer JavaScript-Bundle – einst eine bewährte Praxis – für moderne Webanwendungen nicht mehr der richtige Weg. Forschungen haben gezeigt, dass größere Bundles den Speicherverbrauch und die CPU-Kosten erhöhen, insbesondere auf mittel- und niedrigpreisigen Mobilgeräten.
webpack bietet viele Funktionen, die Ihnen helfen, kleinere Bundles zu erstellen und die Lade Priorität von Ressourcen zu steuern. Die überzeugendste davon ist Code-Splitting, das eine Möglichkeit bietet, Ihren Code in verschiedene Bundles aufzuteilen, die dann bei Bedarf oder parallel geladen werden können. Eine weitere ist Performance-Hinweise, die anzeigen, wenn die Größe von generierten Bundles während des Builds einen bestimmten Schwellenwert überschreitet, damit Sie Optimierungen vornehmen oder unnötigen Code entfernen können.
Das Standardverhalten für Produktions-Builds in webpack ist, eine Warnung anzuzeigen, wenn die Größe einer Asset-Datei oder eines Einstiegspunkts 250 KB (244 KiB) überschreitet. Sie können jedoch konfigurieren, wie Performance-Hinweise angezeigt werden und welche Größenschwellenwerte gelten, indem Sie das performance-Objekt in Ihrer webpack.config.js-Datei verwenden.
Wir werden diese Funktion durchgehen und zeigen, wie Sie sie als erste Verteidigungslinie gegen Performance-Regressionen nutzen können.
Zuerst müssen wir ein benutzerdefiniertes Budget festlegen
Der Standard-Größenschwellenwert für Assets und Einstiegspunkte (wo webpack mit dem Erstellen des Bundles beginnt) passt möglicherweise nicht immer zu Ihren Anforderungen, aber sie können konfiguriert werden.
Zum Beispiel ist mein Blog ziemlich minimalistisch und meine Budgetgröße beträgt bescheidene 50 KB (48,8 KiB) für Assets und Einstiegspunkte. Hier ist die entsprechende Einstellung in meiner webpack.config.js
module.exports = {
performance: {
maxAssetSize: 50000,
maxEntrypointSize: 50000,
}
};Die Eigenschaften maxAssetSize und maxEntrypointSize steuern die Schwellenwerte für Assets und Einstiegspunkte, und beide sind in Bytes angegeben. Letzteres stellt sicher, dass Bundles, die aus den in das entry-Objekt aufgelisteten Dateien erstellt werden (normalerweise JavaScript- oder Sass-Dateien), den angegebenen Schwellenwert nicht überschreiten, während ersteres die gleichen Beschränkungen für andere von webpack ausgegebene Assets (z. B. Bilder, Schriftarten usw.) durchsetzt.
Lassen Sie uns einen Fehler anzeigen, wenn die Schwellenwerte überschritten werden
Der Standard-Warnhinweis von webpack wird ausgelöst, wenn die Budget-Schwellenwerte überschritten werden. Das ist für Entwicklungsumgebungen gut genug, aber für Produktions-Builds unzureichend. Wir können stattdessen einen Fehler auslösen, indem wir die Eigenschaft hints zum performance-Objekt hinzufügen und sie auf 'error' setzen.
module.exports = {
performance: {
maxAssetSize: 50000,
maxEntrypointSize: 50000,
hints: 'error',
}
};
Es gibt auch andere gültige Werte für die Eigenschaft hints, einschließlich 'warning' und false, wobei false Warnungen vollständig deaktiviert, selbst wenn die angegebenen Grenzwerte überschritten werden. Ich würde die Verwendung von false im Produktionsmodus nicht empfehlen.
Wir können bestimmte Assets vom Budget ausschließen
webpack erzwingt Größenschwellenwerte für jeden Asset-Typ, den es ausgibt. Das ist nicht immer gut, da ein Fehler ausgelöst wird, wenn *irgendeines* der ausgegebenen Assets über dem angegebenen Limit liegt. Wenn wir zum Beispiel webpack so einstellen, dass es Bilder verarbeitet, erhalten wir einen Fehler, wenn nur eines davon den Schwellenwert überschreitet.
Die Eigenschaft assetFilter kann verwendet werden, um die Dateien zu steuern, die zur Berechnung von Performance-Hinweisen verwendet werden
module.exports = {
performance: {
maxAssetSize: 50000,
maxEntrypointSize: 50000,
hints: 'error',
assetFilter: function(assetFilename) {
return !assetFilename.endsWith('.jpg');
},
}
};Dies weist webpack an, jede Datei auszuschließen, die mit der Erweiterung .jpg endet, wenn es die Berechnungen für Performance-Hinweise durchführt. Es ist in der Lage, komplexere Logik anzuwenden, um alle Arten von Bedingungen für Umgebungen, Dateitypen und andere Ressourcen zu erfüllen.
Einschränkungen
Während dies für mich eine gute funktionierende Lösung war, ist eine Einschränkung, auf die ich gestoßen bin, dass die gleichen Budget-Schwellenwerte für alle Assets und Einstiegspunkte gelten. Mit anderen Worten, es ist noch nicht möglich, mehrere Budgets nach Bedarf festzulegen, wie z. B. unterschiedliche Limits für JavaScript-, CSS- und Bilddateien.
Dennoch gibt es eine offene Pull-Anfrage, die diese Einschränkung aufheben sollte, aber sie ist noch nicht zusammengeführt. Definitiv etwas, das man im Auge behalten sollte.
Fazit
Es ist sehr nützlich, ein Performance-Budget festzulegen, und die Durchsetzung eines solchen mit webpack ist etwas, das zu Beginn jedes Projekts in Betracht gezogen werden sollte. Es wird die Aufmerksamkeit auf die Größe Ihrer Abhängigkeiten lenken und Sie ermutigen, nach leichteren Alternativen zu suchen, wo immer möglich, um die Budgetüberschreitung zu vermeiden.
Performance-Budgetierung endet damit jedoch nicht! Die Asset-Größe ist nur eine von vielen Dingen, die die Performance beeinflussen, daher ist noch mehr Arbeit zu tun, um sicherzustellen, dass Sie eine optimale Erfahrung liefern. Das Ausführen eines Lighthouse-Tests ist ein großartiger erster Schritt, um andere Metriken kennenzulernen, die Sie verwenden können, sowie Vorschläge für Verbesserungen.
Vielen Dank fürs Lesen und viel Spaß beim Codieren!