JavaScript-Ausführungszeit reduzieren

Der Lighthouse-Befund JavaScript-Ausführungszeit reduzieren misst, wie lange der Hauptthread des Browsers damit beschäftigt ist, die Skripte einer Seite zu parsen, zu kompilieren und auszuführen. Er ist die Laborsicht auf das Problem hinter einem langsamen Interaction to Next Paint: Solange der Hauptthread JavaScript ausführt, kann er weder auf ein Tippen reagieren noch ein Layout aktualisieren oder zeichnen. Anders als das Seitengewicht skaliert die Ausführungszeit mit der Gerätegeschwindigkeit. Ein Bundle, das sich auf dem Laptop des Entwicklers unauffällig verhält, kann ein Mittelklasse-Smartphone sekundenlang blockieren.

Aus den Messungen von PerfDelta: Im mobilen Labortest erreichen 24 % von 5.468 Startseiten bei Total Blocking Time einen guten Wert, 54 % liegen im schlechten Bereich. Der Median liegt bei 680 ms, die mittlere Hälfte zwischen 214 ms und 1531 ms. Mehr dazu im Datenblock unten.

Was der Befund misst

Lighthouse erfasst jedes Skript der Seite und ordnet ihm drei Arten von Hauptthread-Zeit zu: Parsen und Kompilieren der Quelle, Ausführen und die Zeit in den Funktionen, die das Skript aufruft. Der Befund erscheint, wenn die Summe im mobilen Lauf zwei Sekunden übersteigt; die schwersten Skripte stehen mit URL in der Liste. Der mobile Lauf simuliert eine gedrosselte CPU, deshalb sind die Werte um ein Mehrfaches höher als am Desktop. Diese Simulation ist näher an den Smartphones, die ein großer Teil der Besucher nutzt.

Der verwandte Befund Arbeit im Hauptthread minimieren schlüsselt dieselbe Zeit nach Kategorien auf: Skriptauswertung, Styling und Layout, Rendering, Parsen von HTML und CSS, Garbage Collection. Dominiert die Skriptauswertung, sind Sie hier richtig. Dominieren Styling und Layout, sehen Sie zuerst auf die DOM-Größe.

Warum die Ausführungszeit wichtiger ist als die Dateigröße

Bytes kosten einmal Zeit im Netz. Ausführung kostet Zeit auf dem Gerät, bei jedem Seitenaufruf und erneut bei jeder Interaktion, die denselben Code auslöst. Zwei gleich große Skripte können sich in der Ausführungszeit um den Faktor zehn unterscheiden: eine Bibliothek, die beim Start eine große Datenstruktur aufbaut, ein Framework, das die ganze Seite hydriert, oder ein Tag Manager, der beim Laden Dutzende Trigger auslöst, halten den Hauptthread lange nach dem Download beschäftigt. Deshalb hängt die Total Blocking Time viel enger mit der Ausführungszeit zusammen als mit der übertragenen Größe.

So senken Sie die JavaScript-Ausführungszeit

1. Erst die Aufschlüsselung lesen, dann Code anfassen

Öffnen Sie den Befund in Pagespeed Insights und sortieren Sie nach gesamter CPU-Zeit. Auf den meisten Seiten entfallen die größten Anteile auf zwei oder drei Skripte, und mindestens eines davon stammt von einem Drittanbieter. Die Detailsicht liefern die Chrome DevTools: Nehmen Sie ein Performance-Profil mit CPU-Drosselung auf und nutzen Sie die Bottom-up-Ansicht, gruppiert nach Skript-URL. Beheben Sie den größten Posten zuerst; die lange Liste kleiner Posten lohnt sich selten.

2. Weniger Code ausliefern

Code, der nicht geladen wird, kann nicht ausgeführt werden. Code-Splitting, Tree-Shaking und das Entfernen toter Abhängigkeiten behandelt der Ratgeber Nicht verwendetes JavaScript reduzieren. Achten Sie auf große Bibliotheken für eine einzige Funktion: eine Datumsbibliothek, ein komplettes Diagrammpaket für ein Diagramm oder eine Hilfssammlung, von der drei Funktionen genutzt werden.

3. Zurückstellen, was der erste Bildschirm nicht braucht

Skripte für ein Chat-Widget, die Analyseschicht eines Cookie-Banners, Karussells unterhalb des sichtbaren Bereichs oder eine Empfehlungsmaschine können laufen, nachdem die Seite interaktiv ist. Laden Sie sie mit defer, bei Nutzerabsicht (erstes Scrollen oder erste Interaktion) oder per requestIdleCallback:

// Ein schweres Widget erst laden, wenn der Browser nach dem Laden Leerlauf hat
window.addEventListener('load', () => {
  (window.requestIdleCallback || setTimeout)(() => {
    import('./chat-widget.js');
  });
});

Arbeit nach hinten zu verschieben senkt die Gesamtzeit nicht, holt sie aber aus dem Fenster heraus, das über den Largest Contentful Paint und die ersten Interaktionen entscheidet.

4. Lange Tasks aufteilen

Jeder einzelne Task über 50 Millisekunden blockiert Eingaben. Eine Startroutine, die zehn Komponenten in einem Rutsch initialisiert, sollte dazwischen abgeben, damit der Browser ein Tippen verarbeiten kann:

async function init(components) {
  for (const component of components) {
    component.init();
    // Dem Hauptthread die Chance geben, auf Eingaben zu reagieren
    await new Promise(resolve => setTimeout(resolve, 0));
  }
}

Wo verfügbar, erledigt scheduler.yield() dasselbe mit besserer Priorisierung. Für Seiten, die bereits schlank laden, ist das die wirksamste einzelne Änderung für den INP.

5. Hydrierungskosten in Frameworks senken

React, Vue und ähnliche Frameworks führen den Komponentencode im Browser erneut aus, um Event-Handler an das serverseitig gerenderte HTML zu hängen. Auf großen Seiten ist diese Hydrierung oft der größte einzelne Task. Server Components (React), Islands (Astro), partielle oder verzögerte Hydrierung und kleinere Client-Bundles senken sie direkt. Der Next.js-Ratgeber beschreibt die frameworkspezifischen Möglichkeiten.

6. Drittanbieter-Skripte zähmen

Tag Manager, A/B-Test-Werkzeuge, Session Replay und Werbeskripte stehen häufig ganz oben in der Liste. Prüfen Sie, welche Tags noch einen Zweck erfüllen, fassen Sie doppelte Tracker zusammen, laden Sie unwichtige Tags nach der ersten Interaktion und erwägen Sie serverseitiges Tagging für die Analyse. Der Ratgeber zu Drittanbieter-Code geht das im Einzelnen durch.

7. Teure Muster vermeiden

Mancher Code ist unabhängig von seiner Größe langsam: synchrone Layout-Abfragen in Schleifen (erzwungenes Reflow), große JSON-Daten, die beim Start geparst werden, Polyfills für alle statt nur für alte Browser und Animationsschleifen, die laufen, obwohl nichts sichtbar ist. Im Performance-Profil erscheinen sie als breite Blöcke mit demselben Funktionsnamen.

Fortschritt messen

Vergleichen Sie die Summe des Befunds vor und nach jeder Änderung und beobachten Sie die Total Blocking Time im Labor und den INP im Feld. Laborwerte reagieren sofort; der INP im Feld folgt über das 28-Tage-Fenster des CrUX, sobald echte Besucher die neue Version laden.

Häufige Fragen

Warum ist die Ausführungszeit mobil so viel höher als am Desktop?

Der mobile Lighthouse-Lauf drosselt die CPU, um ein Mittelklasse-Smartphone zu simulieren. Ein Skript, das am Laptop 300 ms braucht, kann dort über eine Sekunde dauern. Echte Besucher mit günstigen Geräten erleben ähnliche Werte.

Senkt Minimieren oder Komprimieren die Ausführungszeit?

Nur geringfügig. Beides verkleinert die Übertragung, nicht die Menge an Code, die die Engine parsen und ausführen muss. Code entfernen und zurückstellen hilft.

Welche Skripte sehe ich mir zuerst an?

Die zwei oder drei mit der höchsten CPU-Zeit im Befund. Eines davon ist meist ein Drittanbieter-Tag, ein anderes oft das Hauptbundle der Anwendung oder die Hydrierung des Frameworks.

Wie hängt die Ausführungszeit mit dem INP zusammen?

Lange Skripte blockieren den Hauptthread; ein Tippen, das währenddessen ankommt, wartet, bis sie fertig sind. Ausführungszeit senken und lange Tasks aufteilen sind die beiden Haupthebel für den INP.