Niemand wartet gern. Über 50% der Nutzer verlassen eine Website, wenn der Ladevorgang länger als drei Sekunden dauert.
Das Senden großer JavaScript-Nutzlasten wirkt sich erheblich auf die Geschwindigkeit Ihrer Website aus. Anstatt das gesamte JavaScript an den Nutzer zu senden, sobald die erste Seite Ihrer Anwendung geladen wird, sollten Sie Ihr Bundle in mehrere Teile aufteilen und nur das senden, was am Anfang erforderlich ist.
Warum ist Code-Splitting sinnvoll?
Code-Splitting ist eine Technik, mit der die Startzeit minimiert werden soll. Wenn wir beim Start weniger JavaScript ausliefern, können wir Anwendungen schneller interaktiv machen, indem wir die Arbeit des Hauptthreads in dieser kritischen Phase minimieren.
Bei Core Web Vitals trägt die Reduzierung der beim Start heruntergeladenen JavaScript-Nutzlasten zu besseren Interaction to Next Paint (INP)-Zeiten bei. Der Grund dafür ist, dass die Anwendung durch die Freigabe des Haupt-Threads schneller auf Nutzereingaben reagieren kann, da die Startkosten für das Parsen, Kompilieren und Ausführen von JavaScript reduziert werden.
Je nach Architektur Ihrer Website, insbesondere wenn sie stark auf clientseitiges Rendering angewiesen ist, kann eine Verkleinerung der JavaScript-Nutzlasten, die für das Rendern von Markup verantwortlich sind, zu kürzeren LCP-Zeiten (Largest Contentful Paint) führen. Das kann passieren, wenn die LCP-Ressource erst nach Abschluss des clientseitigen Markups vom Browser erkannt wird oder wenn der Hauptthread zu beschäftigt ist, um das LCP-Element zu rendern. Beide Szenarien können die LCP-Zeit für die Seite verzögern.
Messen
Lighthouse gibt einen fehlgeschlagenen Audit aus, wenn die Ausführung des gesamten JavaScript auf einer Seite sehr lange dauert.
Teilen Sie das JavaScript-Bundle auf, damit nur der Code für die erste Route gesendet wird, wenn der Nutzer eine Anwendung lädt. Dadurch wird die Menge an Skripten minimiert, die geparst und kompiliert werden müssen, was zu schnelleren Seitenladezeiten führt.
Mit beliebten Module Bundlern wie webpack, Parcel und Rollup können Sie Ihre Bundles mit dynamischen Importen aufteilen.
Das folgende Code-Snippet zeigt ein Beispiel für eine someFunction-Methode, die ausgelöst wird, wenn ein Formular gesendet wird.
import moduleA from "library";
form.addEventListener("submit", e => {
e.preventDefault();
someFunction();
});
const someFunction = () => {
// uses moduleA
}
Hier verwendet someFunction ein Modul, das aus einer bestimmten Bibliothek importiert wurde. Wenn dieses Modul nicht an anderer Stelle verwendet wird, kann der Codeblock so geändert werden, dass er nur dann abgerufen wird, wenn das Formular vom Nutzer gesendet wird.
form.addEventListener("submit", e => {
e.preventDefault();
import('library.moduleA')
.then(module => module.default) // using the default export
.then(() => someFunction())
.catch(handleError());
});
const someFunction = () => {
// uses moduleA
}
Der Code, aus dem das Modul besteht, wird nicht in das ursprüngliche Bundle aufgenommen und wird jetzt verzögert geladen oder dem Nutzer erst nach dem Einreichen des Formulars zur Verfügung gestellt, wenn er benötigt wird. Um die Seitenleistung weiter zu verbessern, können Sie wichtige Chunks vorab laden, um sie zu priorisieren und schneller abzurufen.
Obwohl das vorherige Code-Snippet ein einfaches Beispiel ist, ist das Lazy Loading von Drittanbieterabhängigkeiten in größeren Anwendungen kein gängiges Muster. Normalerweise werden Drittanbieterabhängigkeiten in ein separates Anbieter-Bundle aufgeteilt, das im Cache gespeichert werden kann, da es nicht so oft aktualisiert wird. SplitChunksPlugin
Die Aufteilung auf Routen- oder Komponentenebene bei Verwendung eines clientseitigen Frameworks ist ein einfacherer Ansatz für das Lazy Loading verschiedener Teile Ihrer Anwendung. Viele beliebte Frameworks, die Webpack verwenden, bieten Abstraktionen, die das Lazy Loading vereinfachen, sodass Sie sich nicht selbst mit den Konfigurationen befassen müssen.