In diesem Codelab verbessern Sie die Leistung dieser einfachen Anwendung, mit der Nutzer zufällige Katzen bewerten können. Hier erfahren Sie, wie Sie das JavaScript-Bundle optimieren, indem Sie die Menge des transpilierten Codes minimieren.
In der Beispiel-App können Sie ein Wort oder Emoji auswählen, um auszudrücken, wie sehr Ihnen die einzelnen Katzen gefallen. Wenn Sie auf eine Schaltfläche klicken, wird in der App der Wert der Schaltfläche unter dem aktuellen Katzenbild angezeigt.
Messen
Es ist immer eine gute Idee, zuerst eine Website zu prüfen, bevor Sie Optimierungen vornehmen:
- Wenn Sie sich eine Vorschau der Website ansehen möchten, drücken Sie App ansehen und dann Vollbild
. - Drücken Sie „Strg + Umschalttaste + J“ (oder „Befehlstaste + Optionstaste + J“ auf einem Mac), um die Entwicklertools zu öffnen.
- Klicken Sie auf den Tab Netzwerk.
- Klicken Sie das Kästchen Cache deaktivieren an.
- Laden Sie die App neu.
Für diese Anwendung werden über 80 KB verwendet. Prüfen Sie, ob Teile des Pakets nicht verwendet werden:
Drücken Sie
Control+Shift+P(oderCommand+Shift+Pauf einem Mac), um das Menü Befehl zu öffnen.
Gib
Show Coverageein und drücke auf dieEnter, um den Tab Abdeckung aufzurufen.Klicke auf dem Tab Abdeckung auf Aktualisieren, um die Anwendung während der Erfassung der Abdeckung neu zu laden.
Sehen Sie sich an, wie viel Code für das Haupt-Bundle verwendet und wie viel geladen wurde:
Über die Hälfte des Bundles (44 KB) wird nicht einmal genutzt. Das liegt daran, dass ein Großteil des Codes aus polyfills besteht, die dafür sorgen, dass die Anwendung in älteren Browsern funktioniert.
@babel/preset-env verwenden
Die Syntax der JavaScript-Sprache entspricht dem Standard ECMAScript oder ECMA-262. Jährlich werden neue Versionen der Spezifikation veröffentlicht, die neue Funktionen enthalten, die den Vorschlagsprozess bestanden haben. Die Unterstützung dieser Funktionen ist bei den einzelnen Browsern immer unterschiedlich weit fortgeschritten.
In der Anwendung werden die folgenden ES2015-Funktionen verwendet:
Außerdem wird die folgende ES2017-Funktion verwendet:
Sehen Sie sich den Quellcode in src/index.js an, um zu sehen, wie all das verwendet wird.
Alle diese Funktionen werden in der neuesten Version von Chrome unterstützt. Was ist aber mit anderen Browsern, die sie nicht unterstützen? Babel, das in der Anwendung enthalten ist, ist die gängigste Bibliothek, mit der Code mit neuerer Syntax in Code kompiliert wird, der von älteren Browsern und Umgebungen verstanden werden kann. Dies geschieht auf zwei Arten:
- Polyfills werden verwendet, um neuere ES2015- und höher-Funktionen zu emulieren, damit ihre APIs auch dann verwendet werden können, wenn sie vom Browser nicht unterstützt werden. Hier ist ein Beispiel für einen Polyfill für die
Array.includes-Methode. - Mit Plug-ins wird ES2015-Code (oder höher) in die ältere ES5-Syntax umgewandelt. Da es sich um syntaxbezogene Änderungen handelt (z. B. Pfeilfunktionen), können sie nicht mit Polyfills emuliert werden.
In package.json sehen Sie, welche Babel-Bibliotheken enthalten sind:
"dependencies": {
"@babel/polyfill": "^7.0.0"
},
"devDependencies": {
//...
"babel-loader": "^8.0.2",
"@babel/core": "^7.1.0",
"@babel/preset-env": "^7.1.0",
//...
}
@babel/coreist der Babel-Kerncompiler. So werden alle Babel-Konfigurationen in einem.babelrcim Stammverzeichnis des Projekts definiert.babel-loadererfasst Babel in den Webpack-Buildprozess.
Sehen wir uns jetzt an, wie babel-loader in webpack.config.js als Regel enthalten ist:
module: {
rules: [
//...
{
test: /\.js$/,
exclude: /node_modules/,
loader: "babel-loader"
}
]
},
@babel/polyfillbietet alle erforderlichen Polyfills für neuere ECMAScript-Funktionen, damit sie auch in Umgebungen funktionieren, in denen sie nicht unterstützt werden. Es ist bereits ganz oben insrc/index.js.importiert.
import "./style.css";
import "@babel/polyfill";
@babel/preset-envgibt an, welche Transformationen und Polyfills für alle als Ziele ausgewählten Browser oder Umgebungen erforderlich sind.
In der Babel-Konfigurationsdatei .babelrc sehen Sie, wie das geht:
{
"presets": [
[
"@babel/preset-env",
{
"targets": "last 2 versions"
}
]
]
}
Dies ist eine Babel- und Webpack-Konfiguration. Informationen zum Einbinden von Babel in Ihre Anwendung, wenn Sie einen anderen Modul-Bundler als Webpack verwenden
Das targets-Attribut in .babelrc gibt an, auf welche Browser ausgerichtet wird. @babel/preset-env wird in browserslist eingebunden. Eine vollständige Liste der kompatiblen Abfragen, die in diesem Feld verwendet werden können, finden Sie in der Browserlist-Dokumentation.
Mit dem Wert "last 2 versions" wird der Code in der Anwendung für die zwei letzten Versionen jedes Browsers transpiliert.
Debugging
Wenn Sie alle Babel-Ziele des Browsers sowie alle enthaltenen Transformationen und Polyfills sehen möchten, fügen Sie .babelrc: ein debug-Feld hinzu.
{
"presets": [
[
"@babel/preset-env",
{
"targets": "last 2 versions",
"debug": true
}
]
]
}
- Klicken Sie auf Tools.
- Klicken Sie auf Logs.
Aktualisieren Sie die Anwendung und sehen Sie sich die Glitch-Statusprotokolle unten im Editor an.
Ausgerichtete Browser
Babel protokolliert eine Reihe von Details zum Kompilierungsprozess in der Konsole, einschließlich aller Zielumgebungen, für die der Code kompiliert wurde.
Beachten Sie, dass auch eingestellte Browser wie Internet Explorer in dieser Liste enthalten sind. Das ist ein Problem, da für nicht unterstützte Browser keine neuen Funktionen hinzugefügt werden und Babel weiterhin eine bestimmte Syntax für sie transpiliert. Dies erhöht die Größe Ihres Bundles unnötig, wenn Nutzer nicht mit diesem Browser auf Ihre Website zugreifen.
Babel protokolliert auch eine Liste der verwendeten Transformations-Plug-ins:
Das ist eine ziemlich lange Liste. Dies sind alle Plug-ins, die Babel benötigt, um jede ES2015-Syntax oder höher in eine ältere Syntax für alle Zielbrowser umzuwandeln.
Babel zeigt jedoch keine spezifischen polyfills an, die verwendet werden:
Das liegt daran, dass die gesamte @babel/polyfill direkt importiert wird.
Polyfills einzeln laden
Standardmäßig enthält Babel alle Polyfills, die für eine vollständige ES2015-Umgebung erforderlich sind, wenn @babel/polyfill in eine Datei importiert wird. Wenn Sie bestimmte Polyfills importieren möchten, die für die Zielbrowser erforderlich sind, fügen Sie der Konfiguration eine useBuiltIns: 'entry' hinzu.
{
"presets": [
[
"@babel/preset-env",
{
"targets": "last 2 versions",
"debug": true
"useBuiltIns": "entry"
}
]
]
}
Laden Sie die Anwendung neu. Sie sehen jetzt alle enthaltenen spezifischen polyfills:
Auch wenn jetzt nur noch die für "last 2 versions" erforderlichen polyfills enthalten sind, ist es immer noch eine sehr lange Liste. Das liegt daran, dass polyfills, die für die Zielbrowser für jede neuere Funktion erforderlich sind, weiterhin enthalten sind. Ändern Sie den Wert des Attributs in usage, um nur die zu berücksichtigen, die für Funktionen erforderlich sind, die im Code verwendet werden.
{
"presets": [
[
"@babel/preset-env",
{
"targets": "last 2 versions",
"debug": true,
"useBuiltIns": "entry"
"useBuiltIns": "usage"
}
]
]
}
Dadurch werden polyfills bei Bedarf automatisch eingefügt.
Das bedeutet, dass Sie den @babel/polyfill-Import in src/index.js. entfernen können.
import "./style.css";
import "@babel/polyfill";
Jetzt sind nur noch die für die Anwendung erforderlichen Polyfills enthalten.
Die Größe des App-Bundles wird deutlich reduziert.
Liste der unterstützten Browser eingrenzen
Die Anzahl der enthaltenen Browserziele ist immer noch recht hoch und nur wenige Nutzer verwenden eingestellte Browser wie den Internet Explorer. Aktualisieren Sie die Konfigurationen auf Folgendes:
{
"presets": [
[
"@babel/preset-env",
{
"targets": "last 2 versions",
"targets": [">0.25%", "not ie 11"],
"debug": true,
"useBuiltIns": "usage",
}
]
]
}
Sehen Sie sich die Details zum abgerufenen Bundle an.
Da die Anwendung so klein ist, machen diese Änderungen keinen großen Unterschied. Wir empfehlen jedoch, einen Prozentsatz des Browsermarktanteils (z. B. ">0.25%") zu verwenden und bestimmte Browser auszuschließen, die Ihre Nutzer mit Sicherheit nicht verwenden. Weitere Informationen finden Sie im Artikel „Last 2 versions“ als schädlich eingestuft von James Kyle.
<script type="module"> verwenden
Es gibt aber noch Verbesserungsmöglichkeiten. Obwohl einige nicht verwendete Polyfills entfernt wurden, gibt es viele, die für einige Browser nicht erforderlich sind. Mithilfe von Modulen kann neuere Syntax geschrieben und direkt an Browser gesendet werden, ohne dass unnötige Polyfills verwendet werden müssen.
JavaScript-Module sind eine relativ neue Funktion, die in allen gängigen Browsern unterstützt wird.
Mit einem type="module"-Attribut können Sie Scripts definieren, die Daten aus anderen Modulen importieren und exportieren. Beispiel:
// math.mjs
export const add = (x, y) => x + y;
<!-- index.html -->
<script type="module">
import { add } from './math.mjs';
add(5, 2); // 7
</script>
Viele neuere ECMAScript-Funktionen werden bereits in Umgebungen unterstützt, die JavaScript-Module unterstützen (ohne Babel). Das bedeutet, dass die Babel-Konfiguration so geändert werden kann, dass zwei unterschiedliche Versionen Ihrer Anwendung an den Browser gesendet werden:
- Eine Version, die in neueren Browsern funktioniert, die Module unterstützen, und ein Modul enthält, das weitgehend nicht transpiliert wurde, aber eine kleinere Dateigröße hat
- Eine Version mit einem größeren, transpilierten Script, das in jedem älteren Browser funktioniert
ES-Module mit Babel verwenden
Wenn Sie separate @babel/preset-env-Einstellungen für die beiden Versionen der Anwendung verwenden möchten, entfernen Sie die Datei .babelrc. Babel-Einstellungen können der webpack-Konfiguration hinzugefügt werden, indem für jede Version der Anwendung zwei verschiedene Kompilierungsformate angegeben werden.
Fügen Sie webpack.config.js zuerst eine Konfiguration für das alte Script hinzu:
const legacyConfig = {
entry,
output: {
path: path.resolve(__dirname, "public"),
filename: "[name].bundle.js"
},
module: {
rules: [
{
test: /\.js$/,
exclude: /node_modules/,
loader: "babel-loader",
options: {
presets: [
["@babel/preset-env", {
useBuiltIns: "usage",
targets: {
esmodules: false
}
}]
]
}
},
cssRule
]
},
plugins
}
Anstatt den Wert targets für "@babel/preset-env" wird stattdessen esmodules mit dem Wert false verwendet. Das bedeutet, dass Babel alle erforderlichen Transformationen und Polyfills enthält, um jeden Browser anzusprechen, der ES-Module noch nicht unterstützt.
Fügen Sie dem Anfang der webpack.config.js-Datei entry-, cssRule- und corePlugins-Objekte hinzu. Diese werden sowohl für das Modul als auch für ältere Scripts verwendet, die an den Browser gesendet werden.
const entry = {
main: "./src"
};
const cssRule = {
test: /\.css$/,
use: ExtractTextPlugin.extract({
fallback: "style-loader",
use: "css-loader"
})
};
const plugins = [
new ExtractTextPlugin({filename: "[name].css", allChunks: true}),
new HtmlWebpackPlugin({template: "./src/index.html"})
];
Erstellen Sie nun auf ähnliche Weise ein Konfigurationsobjekt für das Modulskript unten, in dem legacyConfig definiert ist:
const moduleConfig = {
entry,
output: {
path: path.resolve(__dirname, "public"),
filename: "[name].mjs"
},
module: {
rules: [
{
test: /\.js$/,
exclude: /node_modules/,
loader: "babel-loader",
options: {
presets: [
["@babel/preset-env", {
useBuiltIns: "usage",
targets: {
esmodules: true
}
}]
]
}
},
cssRule
]
},
plugins
}
Der Hauptunterschied besteht darin, dass für den Ausgabedateinamen die Dateiendung .mjs verwendet wird. Der Wert von esmodules ist hier auf „wahr“ gesetzt. Das bedeutet, dass der Code, der in dieses Modul ausgegeben wird, ein kleineres, weniger kompiliertes Script ist, das in diesem Beispiel keiner Transformation unterzogen wird, da alle verwendeten Funktionen bereits in Browsern unterstützt werden, die Module unterstützen.
Exportieren Sie beide Konfigurationen ganz am Ende der Datei in einem einzigen Array.
module.exports = [
legacyConfig, moduleConfig
];
Dadurch wird jetzt sowohl ein kleineres Modul für Browser erstellt, die es unterstützen, als auch ein größeres transpiliertes Script für ältere Browser.
In Browsern, die Module unterstützen, werden Scripts mit dem Attribut nomodule ignoriert.
Browser, die Module nicht unterstützen, ignorieren hingegen Scriptelemente mit type="module". Das bedeutet, dass Sie ein Modul sowie einen kompilierten Fallback einschließen können. Idealerweise sollten die beiden Versionen der Anwendung in index.html so aussehen:
<script type="module" src="main.mjs"></script>
<script nomodule src="main.bundle.js"></script>
In Browsern, die Module unterstützen, wird main.mjs abgerufen und ausgeführt und main.bundle.js. ignoriert. In Browsern, die Module nicht unterstützen, geschieht das Gegenteil.
Im Gegensatz zu regulären Scripts werden Modulscripts standardmäßig immer verschoben.
Wenn das entsprechende nomodule-Script ebenfalls verschoben und erst nach dem Parsen ausgeführt werden soll, müssen Sie das Attribut defer hinzufügen:
<script type="module" src="main.mjs"></script>
<script nomodule src="main.bundle.js" defer></script>
Als Nächstes fügen Sie dem Modul und dem alten Script die Attribute module und nomodule hinzu und importieren Sie das ScriptExtHtmlWebpackPlugin ganz oben in webpack.config.js:
const path = require("path");
const webpack = require("webpack");
const HtmlWebpackPlugin = require("html-webpack-plugin");
const ScriptExtHtmlWebpackPlugin = require("script-ext-html-webpack-plugin");
Aktualisieren Sie nun das plugins-Array in den Konfigurationen, um dieses Plug-in einzubeziehen:
const plugins = [
new ExtractTextPlugin({filename: "[name].css", allChunks: true}),
new HtmlWebpackPlugin({template: "./src/index.html"}),
new ScriptExtHtmlWebpackPlugin({
module: /\.mjs$/,
custom: [
{
test: /\.js$/,
attribute: 'nomodule',
value: ''
},
]
})
];
Mit diesen Plug-in-Einstellungen wird allen .mjs-Scriptelementen das Attribut type="module" und allen .js-Scriptmodulen das Attribut nomodule hinzugefügt.
Module im HTML-Dokument bereitstellen
Als Letztes müssen Sie sowohl die alten als auch die modernen Scriptelemente in die HTML-Datei ausgeben. Leider unterstützt das Plug-in, mit dem die finale HTML-Datei HTMLWebpackPlugin erstellt wird, derzeit nicht die Ausgabe sowohl der Modul- als auch der Nomodule-Scripts. Es gibt zwar Problemumgehungen und separate Plug-ins, die dieses Problem lösen, z. B. BabelMultiTargetPlugin und HTMLWebpackMultiBuildPlugin. Für diese Anleitung wird jedoch ein einfacherer Ansatz verwendet, bei dem das Modul-Script-Element manuell hinzugefügt wird.
Fügen Sie src/index.js am Ende der Datei Folgendes hinzu:
...
</form>
<script type="module" src="main.mjs"></script>
</body>
</html>
Laden Sie die Anwendung jetzt in einem Browser, der Module unterstützt, z. B. in der neuesten Version von Chrome.
Es wird nur das Modul abgerufen, das aufgrund der weitgehend fehlenden Transpilierung eine viel kleinere Bundle-Größe hat. Das andere Script-Element wird vom Browser vollständig ignoriert.
Wenn Sie die Anwendung in einem älteren Browser laden, wird nur das größere, transpilierte Script mit allen erforderlichen Polyfills und Transformationen abgerufen. Hier ist ein Screenshot aller Anfragen, die mit einer älteren Version von Chrome (Version 38) gesendet wurden.
Fazit
Sie wissen jetzt, wie Sie mit @babel/preset-env nur die für die anvisierten Browser erforderlichen Polyfills bereitstellen. Sie wissen auch, wie sich die Leistung mit JavaScript-Modulen weiter verbessern lässt, indem zwei verschiedene transpilierte Versionen einer Anwendung bereitgestellt werden. Wenn Sie ein gutes Verständnis dafür haben, wie Sie mit diesen beiden Techniken die Größe Ihres Bundles erheblich reduzieren können, können Sie mit der Optimierung beginnen.