JS-Leistungstipps: So beschleunigen Sie die JavaScript-Ladezeit [2025]

Einführung

Während Entwickler Apps erstellen, stoßen sie möglicherweise irgendwann auf Probleme beim Laden von Inhalten. Sie können auch eine Codebasis erben, die nie auf Leistung überprüft wurde.

Zum Glück gibt es viele Möglichkeiten, es schneller zu machen, und sie sind nicht unbedingt zu zeitaufwändig.

Einfache Tricks wie das Entfernen unbenutzter, aber dennoch heruntergeladener Inhalte werden wir hier nicht behandeln, da dies offensichtlich ist.

Wie alles begann

Unser Team bei Brainhub wurde mit etwas beauftragt, das wie eine triviale Aufgabe aussah — wir sollten ein paar mäßig große React.js Komponenten erstellen, die in eine funktionierende Seite eingefügt werden sollten, die nach einem traditionellen Ansatz von PHP + jQuery betrieben wurde.

Als wir kurz davor waren, unsere erste große Iteration abzuschließen, stellten wir und unser Kunde fest, dass die Website mindestens 12s um interaktiv zu werden. React.js ist sehr schnell, also hätte es kein Problem damit geben sollen, aber wir haben es trotzdem überprüft. Das gesamte JS-Bundle wurde schnell heruntergeladen und analysiert. Wie wir vermuteten, muss das Problem also woanders liegen.

Als wir anfingen, uns eingehend mit dem vorhandenen Code zu befassen, entdeckten wir dabei viele Macken, Hacks und Optimierungen.

Am Ende dauerte unsere App weniger als 3s ab dem Moment, in dem das Dokument geladen wurde. Dieser Artikel ist das Ergebnis unserer Arbeit.

Moderne Build-Tools wie Webpack

Webpack bietet uns viele integrierte Funktionen wie die Beseitigung von totem Code. Es importiert nur den notwendigen Code und ignoriert den Rest. Je geringer die Codegröße, desto besser.

Serverseitiges Rendern und Hydratation

React.js, Angular, Vue usw. sind clientseitige Frameworks; das bedeutet, dass der gesamte Inhalt im Browser generiert wird, anstatt ein einfaches Dokumentobjekt vom Server zu erhalten. Das ist keine schlechte Sache, da die Engines moderner Browser sehr leistungsfähig sind, aber es verursacht in bestimmten Bereichen ein Problem:

• Regierungscomputer, die oft mit deaktiviertem JavaScript ausgestattet sind.
• Behinderte Menschen, die auf Screenreader angewiesen sind, sind mit statischen Inhalten viel besser dran.
• Suchmaschinen; obwohl wir wissen, dass Google JavaScript-Code analysiert, haben wir praktisch keine Ahnung, wie andere Suchmaschinen funktionieren.
• Leichte Geräte mit kurzer Akkulaufzeit.
• Personen, die Ihren HTML-Inhalt analysieren möchten. In Python würde es ein paar Zeilen dauern, wenn es um statisches HTML geht, aber mit essentiellem JavaScript wäre eine JavaScript-Engine mit einigen Megabyte erforderlich, um den zu analysierenden Inhalt zurückzugeben.
• Personen mit einer Internetverbindung, die irgendwann langsam werden kann (zum Beispiel ein Zug, der in einen Tunnel fährt).

Dies ist ein Ort, an dem serverseitiges Rendern zum Einsatz kommt. Es ist ein wunderbarer Kompromiss zwischen JavaScript-gerenderten Websites und statischen Webseiten. SSR ermöglicht es Ihnen rendern Sie Ihren JavaScript-Inhalt auf dem Server vor, sende es an einen Benutzer, damit er es sehen kann, und wenn JavaScript geladen ist, verwendet bereits generiertes Markup wieder da nicht alles erneut gerendert werden muss (dieser Vorgang wird „Hydratation“ genannt). Außerdem werden Ihre Nutzer den Inhalt schneller sehen.

SSR liefert manchmal unerwartete Ergebnisse, wenn Ihre Frontend-Algorithmen auf DOM-Manipulationen beruhen. Seien Sie also bereit, einige Ergebnisse nachzuahmen.

Wenn Ihr Backend Node.js verwendet, sind Sie startklar. Wenn nicht, ist es immer noch möglich, obwohl es manchmal schwierig sein kann.

Bilder werden langsam geladen

Wenn Sie viele Bilder auf die Seite laden, kann das Laden Ihres Skripts verschoben werden. Denken Sie an ein verzögertes Laden von Bildern, damit Ihr Skript schneller heruntergeladen werden kann. Alternativ können Sie Versionen derselben Bilder in niedriger Qualität einfügen, ähnlich wie bei Medium.

Verschiebe dein „Script“ -Tag im Dokument nach oben

Vielleicht ist das „Script“ -Tag mit deinem Bundle im DOM zu niedrig? Es kann manchmal entscheidend sein, es so hoch wie nötig zu verschieben.

Versand von reinem ES6+-Code an die Produktion

Moderne Browser unterstützen alle ES6-Spezifikationen (vielleicht mit Ausnahme der Modularität, die sowieso leicht abgedeckt werden kann). Wir können zwei Build-Konfigurationen für ES5- bzw. ES6-Builds erstellen. Der ES6-Build kann an ausgewählte Browser und ES5 an alle anderen ausgeliefert werden. Ihr Backend-Server kann je nach Benutzeragent das erste oder zweite Paket senden.

Wie wir alle wissen, ist unser ES6-Code babelifiziert, sodass ältere Browser ihn möglicherweise noch verstehen, aber er ist nicht kostenlos. Die Kosten für das Transpilieren auf ES5 sind mit einer Menge Polyfills verbunden, sodass eine einfache „async await“ -Funktion nach der Transpilation viermal so viel Code benötigt.

Doch oft nehmen Ihre node_modules den größten Teil Ihres Pakets ein (und Sie sollten und werden wahrscheinlich sowieso gezwungen sein, node_modules von der Transpilation auszuschließen), also ist es am Ende vielleicht nicht die Mühe wert, aber es ist definitiv etwas, das Sie in Ihrem Fall untersuchen sollten.

Codeaufteilung

Code-Splitting ist eines der leistungsstärksten Tools von Webpack. Es ermöglicht Ihnen, mehr als einen Einstiegspunkt für Ihre Anwendung zu definieren. Es gibt viele Fälle, in denen dies nützlich sein könnte. Beispielsweise benötigen Sie möglicherweise nur einen kleinen Teil des JavaScript-Codes für einige Seiten, die nur für nicht eingeloggte Benutzer verfügbar sind. Sie müssten nicht den gesamten Code herunterladen, da er überhaupt nicht verwendet würde.

Intelligente Code-Chunks, die von Webpack generiert werden

Wenn Sie sich auf Code-Splitting verlassen (und das sollten Sie oft tun) und Chunks generieren, erhalten Sie manchmal zu viele kB-Chunks, die nur zu Blockaden beim Herunterladen führen. Sie sollten in der Webpack-Konfiguration eine Mindestgröße für Chunks angeben.

Wenn Sie viele Chunks haben, haben Sie wahrscheinlich am Ende wiederholte Elemente in diesen Chunks erhalten. Um ein solches Verhalten zu deaktivieren, sollten Sie Ihrer Webpack-Konfiguration die folgende Option hinzufügen:

Optimierung: {
Teile Teile: {
Cache-Gruppen: {
Anbieter: falsch,
Standard: falsch,
}
}
}

Außerdem kannst du entscheiden, was in deinen Chunks landen soll. Alles was du tun musst, ist hinzufügen
`/* webpackChunkName: „chunkName“ */` in deinem dynamischen Import als hier vorgestellt.

Komprimieren Sie Ihre .js-Dateien, falls Sie dies noch nicht getan haben

„Gzip“ wird seit langem in allen Browsern unterstützt. Es ist ein großer Gewinn, so viel wie möglich an der Paketgröße zu sparen. Es ist eine sehr einfache Möglichkeit, die Größe Ihrer JS-Dateien zu reduzieren. Als hier erwähnt es kann alles zu der folgenden Konversation kompromittiert werden:

Browser: Hey, kann ich index.js BEKOMMEN? Ich nehme eine komprimierte Version, falls du sie hast.

Server: Lass mich die Datei finden... ja, sie ist hier. Und du nimmst eine komprimierte Version? Fantastisch.

Server: Ok, ich habe index.js gefunden (200 OK), zippe es und sende es rüber.

Browser: Großartig! Es sind nur 10 kB. Ich entpacke es und zeige es dem Benutzer.

Um sicherzustellen, dass Ihr Server „gzip“ -Dateien sendet, suchen Sie in den Dateien, die Ihr Client heruntergeladen hat, nach dem Header „content-encoding“.

Optimiere deine Bundles

Wir alle lieben JavaScript. Es ist jedoch die anspruchsvollste Ressource im Web. Oft verlassen wir uns auf Bibliotheken von Drittanbietern, um die Entwicklung zu beschleunigen und zu vermeiden, das Rad neu zu erfinden.
Manchmal übertreiben wir jedoch mit der Anzahl der Bibliotheken.

Installieren Sie Webpack Bundle Analyzer und verfolge die schwersten Teile deiner App. Um Ihnen ein Beispiel zu nennen: Moment.js wiegt in minimierter und komprimierter Form 65 KB. 75% seines Gewichts sind auf die große Anzahl von Locales zurückzuführen, die es bietet. Erwägen Sie, einige (oder die meisten) Gebietsschemas aus Ihrem Build zu entfernen oder verwenden Sie eine einfache Alternative wie „date-fns“ oder „dayjs“.

Fazit

Denken Sie daran, dass ein Nutzer, der Ihre Inhalte schnell sieht, wahrscheinlich auf Ihrer Website bleibt. Am Ende des Tages ist es immer gut, ein Tool wie Lighthouse zu verwenden, um andere Probleme zu finden, unter denen Ihre Web-App leiden könnte.