Niemand wartet gern. Mehr als 50% der Nutzer verlassen eine Website, wenn das Laden länger als drei Sekunden dauert.
Das Senden großer JavaScript-Nutzlasten beeinträchtigt die Geschwindigkeit deiner Website erheblich. Anstatt den gesamten JavaScript-Code sofort an Ihren Nutzer zu senden, wenn die erste Seite Ihrer Anwendung geladen ist, teilen Sie Ihr Bundle in und senden nur das Nötigste von Anfang an.
Warum ist die Codeaufteilung von Vorteil?
Codeaufteilung ist eine Technik, mit der die Startzeit minimiert werden soll. Wenn wir beim Start weniger JavaScript bereitstellen, können Anwendungen schneller interaktiv werden, da der Aufwand für den Hauptthread in dieser kritischen Phase minimiert wird.
Bei Core Web Vitals trägt die Reduzierung der beim Start heruntergeladenen JavaScript-Nutzlasten zu einer besseren Interaction to Next Paint (INP)-Zeit bei. Der Grund dafür ist, dass die Anwendung durch die Freigabe des Hauptthreads schneller auf Nutzereingaben reagieren kann, indem die Kosten für das Parsen, Kompilieren und Ausführen von JavaScript mit JavaScript reduziert werden.
Abhängig von der Architektur Ihrer Website, insbesondere wenn Ihre Website stark auf clientseitiges Rendering angewiesen ist, kann die Reduzierung der Größe der JavaScript-Nutzlasten, die für das Rendering von Markup verantwortlich sind, zu kürzeren Zeiten für Largest Contentful Paint (LCP) führen. Das kann passieren, wenn die Erkennung der LCP-Ressource verzögert wird, bis das clientseitige Markup abgeschlossen ist, oder wenn der Hauptthread zu beschäftigt ist, um dieses 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 viel Zeit erforderlich ist, den gesamten JavaScript-Code auf einer Seite auszuführen.
Teilen Sie das JavaScript-Bundle auf, sodass nur der Code gesendet wird, der für die ursprüngliche Route erforderlich ist, wenn das Ereignis der Nutzer eine Anwendung lädt. Dadurch wird die Anzahl der Skripts, die geparst und kompiliert, was zu kürzeren Seitenladezeiten führt.
Beliebte Modul-Bundler wie webpack,
Parcel und
Mit Rollup können Sie Ihre
Sets mit dynamischen Importen.
Sehen Sie sich als Beispiel das folgende Code-Snippet an, das 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 nirgendwo verwendet wird, kann der Codeblock geändert werden, um ein
Dynamic Import verwenden, um sie nur abzurufen, 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 des Moduls ist nicht im ersten Bundle enthalten Es wird jetzt lazy Loading geladen oder wird dem Nutzer nur zur Verfügung gestellt, wenn es nach dem der Formulareinreichung. Zur weiteren Verbesserung der Seitenleistung laden Sie kritische Blöcke vorab, um sie zu priorisieren und schneller abzurufen.
Das vorherige Code-Snippet ist ein einfaches Beispiel. Lazy Loading von Drittanbieter-Cookies ist in größeren Anwendungen kein gängiges Muster. Normalerweise Drittanbieterabhängigkeiten werden in ein separates Anbieterpaket aufgeteilt, das im Cache gespeichert werden kann. da sie nicht so oft aktualisiert werden. Weitere Informationen dazu, wie die SplitChunksPlugin kann die Ihnen dabei helfen.
Die Aufteilung auf Routen- oder Komponentenebene bei Verwendung eines clientseitigen Frameworks ist ein einfacherer Ansatz für das Lazy Loading verschiedener Teile einer Anwendung. Viele Gängige Frameworks, die Webpack verwenden, bieten Abstraktionen für Lazy Loading. als sich die Konfigurationen selbst genauer anzusehen.