Niemand mag es, zu warten. Mehr als 50% der Nutzer verlassen eine Website, wenn der Ladevorgang länger als drei Sekunden dauert.
Das Senden großer JavaScript-Nutzlast 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 ist, teilen Sie Ihr Bundle in mehrere Teile auf und senden Sie nur das, was am Anfang erforderlich ist.
Warum ist das Code-Splitting vorteilhaft?
Das Code-Splitting ist eine Methode, mit der die Startzeit minimiert werden soll. Wenn wir beim Start weniger JavaScript ausliefern, können Anwendungen schneller interaktiv werden, da die Arbeit im Hauptthread während dieser kritischen Phase minimiert wird.
Bei den Core Web Vitals trägt eine Verringerung der beim Start heruntergeladenen JavaScript-Nutzlast zu einer besseren Interaction to Next Paint (INP)-Zeit 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 Ihre Website stark auf clientseitiges Rendering angewiesen ist, kann die Verringerung der Größe der JavaScript-Nutzlast, die für das Rendern des Markups verantwortlich ist, zu einer Verbesserung der LCP-Zeit (Largest Contentful Paint) führen. Dies 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. In beiden Fällen kann sich die LCP-Zeit für die Seite verzögern.
Messen
Lighthouse zeigt eine fehlgeschlagene Prüfung an, wenn die Ausführung des gesamten JavaScripts auf einer Seite sehr lange dauert.
Teilen Sie das JavaScript-Bundle auf, damit nur der für die erste Route erforderliche Code gesendet wird, wenn der Nutzer eine Anwendung lädt. Dadurch wird die Menge an Script minimiert, die geparst und kompiliert werden muss, was zu kürzeren Seitenladezeiten führt.
Mit gängigen Module Bundlern wie Webpack, Parcel und Rollup können Sie Ihre Bundles mithilfe von dynamischen Importen aufteilen.
Das folgende Code-Snippet zeigt beispielsweise 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 es nur dann per dynamischem Import 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 lazy loaded (lazy-geladen) oder dem Nutzer nur dann zur Verfügung gestellt, wenn er nach der Formulareinreichung benötigt wird. Um die Seitenleistung weiter zu verbessern, laden Sie wichtige Chunks vorab, um sie zu priorisieren und früher abzurufen.
Das vorherige Code-Snippet ist zwar ein einfaches Beispiel, das Lazy-Laden von Drittanbieterabhängigkeiten ist jedoch kein gängiges Muster in größeren Anwendungen. In der Regel werden Abhängigkeiten von Drittanbietern in einem separaten Anbieter-Bundle unterteilt, das im Cache gespeichert werden kann, da sie nicht so oft aktualisiert werden. Weitere Informationen dazu, wie Sie das SplitChunksPlugin verwenden können, finden Sie hier.
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 einfacher machen, als sich selbst mit den Konfigurationen zu befassen.