Wie beeinflusst JavaScript die Ladezeit? JavaScript Performance gezielt optimieren

JavaScript Performance beschreibt, wie viel Zeit der Browser mit dem Laden, Parsen und Ausführen Ihrer Skripte verbringt, bevor eine Seite fertig aussieht und auf Eingaben reagiert. Ich arbeite seit 2012 an Kundenwebsites. Bei den meisten langsamen Seiten, die ich prüfe, sind nicht die Bilder schuld, sondern JavaScript, das niemand mehr überblickt. In diesem Beitrag zeige ich, woher diese Kosten kommen und wie ich sie Schritt für Schritt senke.

Den allgemeinen Einfluss der Ladezeit auf Rankings erkläre ich im Beitrag wie die Ladezeit SEO beeinflusst. Das Testen mit Lighthouse beschreibe ich in meiner Anleitung zum Lighthouse Test. Hier geht es also nur um JavaScript: wie der Browser es verarbeitet, wo es hakt und was Sie ändern können.

Wie beeinflusst JavaScript die Ladezeit und die JavaScript Performance?

JavaScript ist Code, der im Hauptthread des Browsers läuft; solange er läuft, kann die Seite weder zeichnen noch flüssig scrollen noch auf Klicks reagieren. Je schwerer Ihre Skripte sind, desto später erscheint die Seite und desto träger reagiert sie. Gute JavaScript Performance heißt deshalb, diese Blockadezeit kurz zu halten.

Hier hilft ein Vergleich mit Bildern. Ein Bild mit 300 KB lädt der Browser nur herunter und dekodiert es. Ein Skript derselben Größe muss er dagegen laden, parsen, kompilieren und dann ausführen. Pro Byte kostet JavaScript also deutlich mehr. Zudem passiert diese Arbeit im selben Thread, der auch Ihre Eingaben verarbeitet.

In der Praxis sehe ich fast immer dasselbe Muster. Eine Website startet schnell. Dann kommt für jede Kampagne ein Pixel und für jeden Wunsch ein Plugin dazu. Ein Jahr später lädt die Seite Dutzende Skripte, die niemand vollständig auflisten kann. Kurz gesagt: JavaScript Probleme entstehen selten durch einen großen Fehler, sondern durch Anhäufung.

Was macht der Browser mit einer JavaScript Datei?

Sie können sich die Arbeit in vier Stufen vorstellen. Jede Stufe hat eigene Kosten, und jede Optimierung setzt an einer davon an:

1. Laden: Die Datei kommt über das Netz. Hier zählen Größe, Kompression und Cache.
2. Parsen und Kompilieren: Die Engine liest den Code und bereitet ihn vor. Auf Mittelklasse Smartphones dauert das spürbar.
3. Ausführen: Der Code läuft im Hauptthread, verändert das DOM und registriert Event Listener.
4. Folgearbeit: Danach kommen Stilberechnung, Layout und Zeichnen.

Entscheidend ist allerdings, dass der Hauptthread immer nur eine Sache erledigt. Der Leitfaden auf web.dev zum Optimieren langer Aufgaben nennt jede Aufgabe über 50 Millisekunden einen Long Task. Tippt jemand während eines Long Tasks auf einen Button, kann der Browser das erst danach verarbeiten. Deshalb sollten Sie nicht nur die Dateigröße, sondern auch die Ausführungszeit messen.

Was ist ein renderblockierendes Skript?

Ein renderblockierendes Skript ist ein klassisches Script Tag im head ohne async oder defer. Trifft der Browser darauf, hört er auf, das HTML zu lesen. Er lädt die Datei, führt sie aus und baut die Seite erst dann weiter auf.

Bei langsamer Verbindung sieht der Besucher daher sekundenlang einen leeren oder halbfertigen Bildschirm. Zudem hat das Skript oft gar nichts mit der ersten Ansicht zu tun. Ein Chat Widget, eine Analytics Bibliothek oder ein Slider Plugin landen zum Beispiel häufig synchron im head. Trotzdem braucht keines davon den ersten Bildschirm.

Lighthouse meldet das unter „Ressourcen beseitigen, die das Rendering blockieren“. Wenn ich eine Website zum ersten Mal ansehe, öffne ich den Quelltext und zähle die Script Tags im head. Dann stelle ich zu jedem eine Frage: Muss dieser Code laufen, bevor der Besucher den oberen Seitenbereich sieht? Die Antwort lautet fast immer nein.

Was ist der Unterschied zwischen defer und async?

Beide Attribute lassen den Browser ein Skript laden, ohne das Parsen des HTML anzuhalten. Der Unterschied liegt im Zeitpunkt der Ausführung. Die MDN Referenz zum script Element beschreibt die Details; die Kurzfassung steht in der Tabelle.

Hängen Ihre Skripte voneinander ab, nehmen Sie also defer, denn es hält die Reihenfolge ein. Für ein Messskript ohne Abhängigkeiten reicht async. In der Praxis lade ich den eigenen Code der Website mit defer. Skripte von Drittanbietern lade ich, wo möglich, mit async oder verzögert.

Wo fangen Sie mit der JavaScript Performance an?

Zunächst brauchen Sie eine Bestandsaufnahme. Ohne zu wissen, warum ein Skript lädt, ist jede Korrektur geraten. Ich gehe dabei so vor:

• Im Network Tab der Chrome DevTools filtere ich nach JS und liste jede Datei mit Größe und Herkunft auf.
• Im Coverage Panel prüfe ich, wie viel Code beim Laden ungenutzt bleibt.
• Im Performance Panel zeichne ich einen Ladevorgang auf und markiere, welche Datei welchen Long Task verursacht.
• Für jedes Drittanbieter Tag bestimme ich einen Verantwortlichen: Wer wollte es, und nutzt es noch jemand?

Diese Liste überrascht fast immer. So feuert zum Beispiel noch der Pixel einer Kampagne, die vor zwei Jahren endete. Oder derselbe Analytics Code läuft doppelt, einmal über das Theme und einmal über den Tag Manager. Folglich beginnt Arbeit an der JavaScript Performance oft mit Löschen, nicht mit Programmieren. Das ist der günstigste und schnellste Gewinn.

Wie finden und entfernen Sie ungenutztes JavaScript?

Ungenutztes JavaScript ist Code, den eine Seite lädt, aber nie ausführt. Ein typischer Fall: Eine Bibliothek zur Formularprüfung braucht nur die Kontaktseite, trotzdem lädt sie jede Seite. Das Coverage Panel zeigt diesen Anteil pro Datei mit roten und grünen Balken.

Ich räume auf drei Wegen auf. Erstens entferne ich Plugins und Bibliotheken, die niemand nutzt. Dann verschiebe ich seitenspezifischen Code auf die Seiten, die ihn brauchen. Schließlich importiere ich bei großen Bibliotheken nur den Teil, den die Website wirklich nutzt, oder ersetze ihn durch eine eingebaute Browserfunktion.

Eine Warnung allerdings: Coverage zeigt nur die Sitzung, die Sie aufgezeichnet haben. Haben Sie das Menü nie geöffnet, wirkt der Menücode ungenutzt. Deshalb sollten Sie vor dem Löschen alle Interaktionen durchklicken. Sonst haben Sie am Ende eine schnellere Website, deren Menü nicht mehr aufgeht.

Was ist Code Splitting und wann hilft es?

Code Splitting heißt, ein großes Bundle nach Seite oder Funktion in kleinere Teile zu zerlegen. So lädt der Besucher nur den Code, den er gerade braucht. Moderne Bundler erledigen das über dynamische Imports automatisch.

Am meisten bringt es bei Single Page Apps und bei Websites mit React oder Vue. Ein Besucher der Startseite sollte zum Beispiel nie den Adminbereich, eine Diagrammbibliothek oder die Checkout Logik erhalten. Splitting nach Routen löst das meiste davon.

Zu starkes Splitting schafft allerdings neue Probleme. Dutzende winzige Teile bedeuten mehr Anfragen und längere Abhängigkeitsketten. Ich starte daher meist mit Splitting nach Routen. Danach lagere ich nur wirklich schwere Komponenten aus, etwa Karten, Editoren oder Videoplayer. Die Architektursicht für große Teams beschreibe ich im Beitrag über Micro Frontends.

Wie stark bremsen Skripte von Drittanbietern eine Website?

Skripte von Drittanbietern kommen von fremden Servern: Werbepixel, Analytics, Chat Tools, Heatmaps, A/B Tests und eingebettete Videos. Das Kernproblem ist die Kontrolle. Größe und Verhalten bestimmen nicht Sie, und sobald der Anbieter die Datei ändert, ändern sich auch Ihre Kosten.

Eine feste Zahl für die Verlangsamung kann ich Ihnen nicht nennen, denn die Wirkung hängt stark von Tag und Lademethode ab. Trotzdem sehe ich immer wieder dasselbe Muster: Ein großer Teil der Long Tasks im Hauptthread stammt von Drittanbieter Tags und nicht vom eigenen Code. Das ist eine Beobachtung aus der Praxis, keine Garantie; messen Sie es daher auf jeder Website selbst.

Gruppieren Sie im Performance Panel die Aktivität nach Drittanbietern. Dann sehen Sie, wie viel Zeit im Hauptthread jede Domain verbraucht. Diese Liste ist das konkreteste Dokument für ein Gespräch mit dem Marketing. Statt „dieser Pixel bremst“ sagen Sie dann: „dieser Pixel kostet bei jedem Aufruf so viel Zeit“.

Wie steuern Sie Drittanbieter Tags, ohne die Ladezeit zu ruinieren?

Marketing Tags zu löschen ist nicht immer eine Option, denn ohne Conversion Tracking können Sie kein Werbebudget steuern. Das Ziel lautet also nicht Löschen, sondern Laden zur richtigen Zeit am richtigen Ort. Diese Regeln wende ich an:

• Jedes Tag läuft nur dort, wo es nötig ist, zum Beispiel der Kaufpixel nur auf der Dankeseite.
• Schwere Elemente wie Chat, Karten und Video zeigen bis zum Klick nur eine leichte Vorschau.
• Erledigen zwei Tools dieselbe Aufgabe, bleibt eines; zwei Heatmap Tools braucht kaum jemand.
• Jedes Tag im Tag Manager hat einen Verantwortlichen und ein Prüfdatum.
• Unkritische Tags feuern erst nach dem vollständigen Laden der Seite.

Achten Sie dabei auf einen Zielkonflikt. Verzögern Sie ein Conversion Tag zu stark, verpassen Sie womöglich Conversions von Besuchern, die schnell wieder gehen. Prüfen Sie deshalb beim Verzögern immer auch den Messverlust. In Konten, die ich im Rahmen der Google Ads Verwaltung betreue, beobachte ich Ladezeit und Conversion Daten nebeneinander.

Wie hängen JavaScript und INP zusammen?

INP (Interaction to Next Paint) misst, wie lange es nach einem Klick, Tippen oder Tastendruck dauert, bis sich der Bildschirm sichtbar aktualisiert. Laut dem INP Leitfaden auf web.dev gelten 200 Millisekunden oder weniger als gut. JavaScript bestimmt diesen Wert am direktesten.

Die Verzögerung einer Interaktion besteht aus drei Teilen: Eingabeverzögerung, Laufzeit des Event Handlers und Darstellungsverzögerung bis zum nächsten Frame. Die Eingabeverzögerung wächst, wenn der Hauptthread beim Tippen gerade mit einem anderen Long Task beschäftigt ist. Bei der Laufzeit des Handlers geht es schlicht um das Gewicht Ihres eigenen Codes. Anders gesagt: In beiden Fällen steckt meist JavaScript dahinter.

Deshalb kann eine Website mit gutem LCP trotzdem einen schlechten INP haben. Die Seite erscheint schnell. Dann tippen Sie auf „In den Warenkorb“, und eine halbe Sekunde passiert nichts. Der Nutzer glaubt, der Klick habe nicht funktioniert, und tippt erneut. Wie diese Reibung den Umsatz trifft, beschreibe ich im Beitrag zu SEO und UX.

Wie teilen Sie lange Aufgaben auf?

Einen Long Task aufzuteilen heißt, eine Aufgabe von 300 Millisekunden in kleine Stücke mit Pausen dazwischen zu zerlegen. Tippt der Nutzer in dieser Zeit, kann der Browser die Eingabe zwischen den Stücken verarbeiten.

web.dev empfiehlt dafür bewusste Yield Punkte im Code. In Chrome unterbricht scheduler.yield() Ihre Arbeit, gibt die Kontrolle an den Browser zurück und stellt den Rest mit Vorrang wieder an. Für Browser ohne Unterstützung schreiben Sie einen Fallback mit setTimeout. Wichtig ist, nicht nach jeder Zeile zu pausieren, sondern zwischen sichtbarer Arbeit und Hintergrundarbeit.

Ein Beispiel aus der Praxis: Ein Filterbutton aktualisiert die Produktliste, sendet ein Analytics Ereignis und schreibt die URL neu. Zunächst aktualisieren Sie die Liste. Dann geben Sie per yield ab. Danach erledigen Sie Analytics und URL. So sieht der Nutzer das Ergebnis sofort, und der Rest läuft in einem Moment, den er nicht bemerkt.

Wie beeinflusst die Wahl des Frameworks die JavaScript Performance?

Ihr Framework legt von Anfang an fest, wie viel JavaScript eine Seite ausliefert. Eine rein clientseitig gerenderte Single Page App muss Framework und Anwendungscode laden und ausführen, bevor sie Inhalte zeigt. Serverseitig gerenderte oder statisch erzeugte Seiten schicken dagegen fertiges HTML.

Das heißt nicht, dass React oder Vue schlecht wären. Braucht eine Unternehmenswebsite aber kaum mehr Interaktion als ein Taschenrechner, ist ein komplettes App Framework für jeden Besucher eine teure Entscheidung. Der inzwischen verbreitete Ansatz der „Islands“ macht nur die interaktiven Bereiche mit JavaScript lebendig und lässt den Rest als reines HTML.

Mein Rat daher: Wählen Sie das Framework nach dem tatsächlichen Interaktionsbedarf, nicht nach Gewohnheit des Teams. In Webdesign Projekten stelle ich diese Frage im ersten Termin, denn ein späterer Wechsel kostet weit mehr als eine gute Wahl zu Beginn.

Wie wirkt sich per JavaScript gerenderter Inhalt auf SEO aus?

In den Grundlagen zu JavaScript SEO erklärt Google, dass es Seiten mit einem aktuellen Chromium rendert. Zugleich beschreibt Google, dass das Rendering nach dem Crawling in einer eigenen Warteschlange stattfindet. Erscheint Inhalt also erst nach dem JavaScript, hängt seine Sichtbarkeit für Google an diesem zusätzlichen Schritt.

Diese Probleme sehe ich am häufigsten: Links arbeiten mit Klick Handlern statt mit echten a Tags, Titel und Beschreibungen entstehen nur im Client, und Fehlerseiten liefern Status 200. Keines davon ist direkt ein Ladezeitproblem. Trotzdem wachsen alle aus derselben Wurzel, nämlich zu starker Abhängigkeit von JavaScript.

Halten Sie deshalb wichtige Inhalte, Überschriften und interne Links im HTML, das der Server liefert. Die Crawling Seite behandle ich in technisches SEO: 10 Tipps und technisches SEO nach der KI Wende. Bedenken Sie zudem, dass viele KI Crawler überhaupt kein JavaScript ausführen.

Mit welchen Techniken verkleinern Sie Ihr Bundle?

Wenn Sie Code weder löschen noch aufteilen können, liefern Sie den Rest so klein wie möglich aus. Hier wird die Arbeit an der JavaScript Performance technischer. Diese Techniken nutze ich:

1. Minifizierung: Sie entfernt Leerzeichen, Kommentare und lange Variablennamen. Die meisten Build Tools erledigen das im Produktionsmodus.
2. Kompression: Liefert der Server Skripte mit Brotli oder gzip aus, sinkt die Übertragungsgröße deutlich.
3. Tree Shaking: Der Bundler lässt Exporte weg, die niemand importiert. Das setzt ES Module voraus.
4. Polyfills aufräumen: Halten Sie die Liste der Zielbrowser aktuell, damit moderne Browser keine Flicken für alte Browser erhalten.
5. Bibliotheken tauschen: Ersetzen Sie schwere Datums oder Animationsbibliotheken durch eingebaute Browser APIs oder kleinere Alternativen.

Eines sollten Sie dabei nicht vergessen: Kompression senkt die Übertragungsgröße, nicht die Ausführungskosten. Der Browser parst und führt den entpackten Code trotzdem vollständig aus. Sehen Sie Kompression daher als Grundhygiene, nicht als letzten Schritt.

Wie beschleunigen Cache und Resource Hints das Laden von Skripten?

Für wiederkehrende Besucher ist die schnellste Datei jene, die gar nicht erst lädt. Deshalb geben Sie Skriptdateien Namen mit Inhaltshash und lange Cache Laufzeiten. Ändert sich eine Datei, ändert sich auch ihr Name, und niemand bleibt auf einer alten Version hängen.

Resource Hints helfen beim ersten Besuch. Ein preconnect zu einer wichtigen Drittanbieter Domain baut die Verbindung zum Beispiel früher auf. Für ein Modul, das die Seite sofort braucht, das der Browser aber spät entdeckt, können Sie modulepreload einsetzen.

Hints überall einzusetzen wirkt allerdings kontraproduktiv. Jedes preload sagt dem Browser „lade das jetzt“ und konkurriert um Bandbreite. Ist alles Priorität, ist somit nichts Priorität. Ich beschränke die preload Liste meist auf zwei oder drei Einträge und messe jeden, bevor ich ihn behalte.

Warum ist JavaScript auf Smartphones ein größeres Problem?

Entwickler testen meist auf starken Laptops. Viele Besucher kommen aber mit Mittelklasse Smartphones. Dasselbe Skript zu parsen und auszuführen dauert auf einem schwächeren Prozessor deutlich länger.

Eine Interaktion, die am Desktop flüssig wirkt, kann auf dem Handy daher ruckeln. Die CPU Drosselung in den Chrome DevTools zeigt den Unterschied grob an. Ein echtes Gerät ersetzt sie trotzdem nicht; ich habe deshalb immer ein älteres Android Mittelklassegerät auf dem Tisch.

Zudem spielen mobile Netze mit. Dauert der Download länger, lässt jedes renderblockierende Skript den Besucher länger vor einem leeren Bildschirm sitzen. Für einen vollständigen Mobilcheck lesen Sie meine Anleitung zum Test der Mobilfreundlichkeit. Kurz gesagt ist JavaScript Performance für mobile Besucher kein Extra, sondern Grundvoraussetzung.

Für Smartphones nutze ich außerdem eine kurze Checkliste. Zunächst zähle ich die Skripte, die der erste Bildschirm auf dem Handy braucht. Dann teste ich Touch Menü, Filter und Warenkorb Button mit gedrosselter CPU. Schließlich prüfe ich, ob Code für Elemente lädt, die mobil nie erscheinen. Ein großes Desktop Menü liefert seinen Code zum Beispiel oft auch an Smartphones aus.

Mit welchen Tools messen Sie die JavaScript Performance?

Es gibt zwei Arten von Daten: Labordaten und Felddaten. Labordaten simulieren einen Ladevorgang unter kontrollierten Bedingungen, Felddaten stammen von echten Nutzern. Beide beantworten verschiedene Fragen, also brauchen Sie beide.

• Lighthouse liefert eine schnelle Diagnose zu Total Blocking Time, ungenutztem JavaScript und renderblockierenden Ressourcen.
• Chrome DevTools Performance zeigt die Laufzeit jeder Funktion auf die Millisekunde genau.
• PageSpeed Insights zeigt Laborwerte und, bei genug Traffic, echte Daten von Chrome Nutzern auf einer Seite.
• Search Console listet im Bericht zu Core Web Vitals Gruppen problematischer URLs.

Ein Detail ist wichtig: INP ist eine Feldmetrik, und ein Labortest wie Lighthouse, der nichts anklickt, misst ihn nicht direkt. Im Labor ist TBT ein guter Hinweis darauf, wie beschäftigt der Hauptthread ist. Für den echten INP brauchen Sie allerdings Felddaten. In meiner Search Console Anleitung erkläre ich, wie Sie diesen Bericht lesen.

Welche Fehler passieren bei der JavaScript Optimierung am häufigsten?

Über die Jahre habe ich auf vielen Websites dieselben Fehler gesehen. Diese kommen am häufigsten vor:

• Nur den Lighthouse Score jagen und nie echte Nutzerdaten ansehen.
• Ein Speed Plugin installieren, das jedes Skript blind verzögert; das kann Menüs, Formulare und den Checkout zerstören.
• Kritische Inhalte, die JavaScript im sichtbaren Bereich einfügt, per Lazy Loading verzögern.
• Den Tag Manager wie eine Schublade ohne Boden nutzen.
• Einmal optimieren und neuen Code danach nie mehr prüfen.

Gemeinsam ist all dem, dass Entscheidungen ohne Messung fallen. Deshalb messe ich vor und nach jeder Änderung unter gleichen Bedingungen. Zudem ändere ich immer nur eine Sache. Ändern Sie fünf Dinge auf einmal, wissen Sie nicht, was geholfen und was etwas kaputt gemacht hat.

Wie planen Sie die Arbeit an einer älteren Website?

Auf einer über Jahre gewachsenen Website funktioniert es selten, alles gleichzeitig zu reparieren. Ich sortiere die Arbeit daher zuerst nach Risiko. Änderungen an umsatzrelevanten Bereichen wie Checkout, Kontaktformular und Navigation kommen zuletzt. Unnötigen Code auf Inhaltsseiten räume ich dagegen in der ersten Woche auf.

Meine zweite Regel: Jede Änderung bleibt umkehrbar. Bevor ich ein Tag lösche, pausiere ich es zum Beispiel im Tag Manager und beobachte eine Woche lang die Conversion Daten. Bleibt alles stabil, entferne ich es endgültig. So gewinnen Sie Tempo, ohne das Tracking des Marketings zu gefährden.

Die dritte Regel betrifft die Sprache im Team. Entwickler sagen Hauptthread, Marketer sagen Pixel, die Geschäftsführung sagt Umsatz. Also notiere ich jeden Befund in drei Spalten: was bremst, wer verantwortlich ist und welche Messung sich ändert, wenn es wegfällt. Aus einem technischen Thema wird so eine entscheidbare Liste.

Planen Sie schließlich realistisch. Auf einer kleinen Unternehmenswebsite dauert die erste Bereinigung oft wenige Tage, in einem großen Onlineshop kann sie sich über Wochen ziehen. Diese Spannen beruhen auf Praxiserfahrung und sind ein Ausgangspunkt, keine Garantie.

Wie halten Sie die JavaScript Performance dauerhaft stabil?

Eine einmalige Bereinigung schmilzt innerhalb weniger Monate dahin. Für dauerhafte Ergebnisse brauchen Sie einen Prozess. Am wirksamsten ist ein Performance Budget: Sie legen zum Beispiel fest, wie viel JavaScript die Startseite beim ersten Laden höchstens ausliefern darf und wie viele Long Tasks erlaubt sind.

Dann koppeln Sie dieses Budget an Ihren Release Prozess. Das Build Tool warnt, sobald das Bundle die Grenze überschreitet. Bevor jemand ein neues Drittanbieter Tag einbaut, steht ein kurzer Freigabeschritt an. So ändert sich die Ladezeit nur durch bewusste Entscheidungen.

Schauen Sie sich schließlich einmal im Monat die Felddaten an. Der Verlauf in Search Console oder PageSpeed Insights zeigt die Wirkung eines neuen Plugins oder Kampagnen Tags meist schnell. Auf Websites, die ich im Rahmen der SEO Beratung betreue, gehört dieser Check zum Monatsbericht.

In welcher Reihenfolge gehen Sie die Optimierung an?

Fasse ich alles oben Genannte zu einer Abfolge zusammen, sieht mein Weg in der Praxis so aus:

1. Bestandsaufnahme: Herkunft, Größe und Verantwortlichen jedes Skripts erfassen.
2. Unnötiges löschen; hier liegt der größte und günstigste Gewinn.
3. Renderblockierende Skripte mit defer oder async laden.
4. Drittanbieter Tags nach Seite und Zeitpunkt begrenzen.
5. Code Splitting nach Routen einführen.
6. Long Tasks aufteilen und Event Handler verschlanken.
7. Minifizierung, Kompression und Cache richtig einstellen.
8. Ein Performance Budget festlegen und Felddaten monatlich prüfen.

Die Logik dahinter ist einfach. Zuerst kommen Schritte, die Kosten auf null senken, dann Schritte, die Kosten verringern, und zuletzt der Prozess, der die Gewinne sichert. Wenn Sie dabei Unterstützung möchten, schreiben Sie mir über die Kontaktseite. Wir messen zunächst den aktuellen Stand und entscheiden dann gemeinsam, welcher Schritt für Sie am meisten bringt.