JSLT-Metrik: Wenn Ihre Website das Atmen vergisst

Stellen Sie sich vor, Sie klicken auf einen Button und nichts passiert. Die Website friert einfach ein. Meistens ist ein „Long Task“ schuld – eine JavaScript-Aufgabe, die schlichtweg zu lange dauert. Ein Moment, in dem der Browser intensiv nachdenkt und alles andere ignoriert.

In diesem Artikel erklären wir, wie die Metrik JS Long Tasks solche digitalen Staus misst und was diese für Ihre Benutzer und Ihr Geschäft bedeuten könnten.

Wenn JavaScript Ihre Website blockiert: Mehr als 50 ms sind zu viel#

Die Programmiersprache des Webs, JavaScript, ist zwar ein Arbeitstier, aber sie hat eine entscheidende Eigenschaft: Sie läuft standardmäßig nur in einem einzigen Thread.

Der Browser ist wie ein Koch, der nur eine Sache gleichzeitig machen kann. Wenn er Zwiebeln für einen riesigen Eintopf schneidet, kann er nicht gleichzeitig das Telefon für seinen Chef abnehmen.

Eine Long Task (lange Aufgabe in JavaScript) ist jede Operation, die länger als 50 ms dauert. Diese Grenze basiert auf dem RAIL-Modell. Der Benutzer empfindet eine Reaktionszeit von bis zu 100 ms als sofortig. Die restlichen 50 ms sind eine Reserve für den Browser, um auf Ihre Eingaben zu reagieren.

So sieht es der Browser. Der zweite Klick des Benutzers fällt in eine lange Aufgabe. Der Browser ist jetzt der Koch, der Zwiebeln schneidet und das Telefon für seinen Chef nicht abnehmen kann.

Der Hauptthread des Browsers ist wie ein Drehbuch, nach dem der Browser Prozessor und Speicher beschäftigt. Wenn eine Long Task läuft, ist der Hauptthread blockiert. Der Benutzer kann in diesem Moment nicht klicken oder tippen.

Viele JS-Metriken, viel Verwirrung#

Wir alle wollen grüne Zahlen bei den Core Web Vitals. Die JS Long Tasks-Metrik gehört zwar nicht zu diesem grundlegenden Set, kann aber einiges verraten.

Kunden fragen die Experten von PageSpeed.ONE oft nach dem Unterschied zwischen Long Tasks und Metriken wie Interaction to Next Paint (INP) oder Total Blocking Time (TBT).

Konkret sind die Metriken TBT und JSLT ähnlich. Kurz gesagt: TBT ist ein strenger Test im Labor, Long Tasks in RUM sind Aufzeichnungen darüber, wie die Website in den Händen der Benutzer wirklich ins Stocken gerät. Total Blocking Time (TBT) wird jedoch synthetisch und nur beim Laden gemessen. JSLT wird bei echten Benutzern gemessen. Mehr über die Unterschiede zwischen synthetischer und RUM-Messung erfahren Sie im Artikel synth vs CrUX vs RUM.

Hier eine übersichtliche Vergleichstabelle:

Eigenschaft	Total Blocking Time (TBT)	JS Long Tasks (JSLT)
Datenquelle	Labor (simulierter Bot)	Echte Benutzer (RUM)
Zeitfenster	Nur beim Laden (FCP → TTI)	Gesamte Lebensdauer der Seite
Was wird gemessen	Nur Zeit über 50 ms	Gesamtdauer aller Aufgaben
Hauptziel	Schnelle technische Kontrolle	Geschäftsanalyse und echtes UX
Typisches Werkzeug	Lighthouse, PageSpeed.ONE Monitoring	SpeedCurve RUM

Und die INP-Metrik? Sowohl TBT als auch JSLT können eine direkte, aber oft auch indirekte Verbindung zu dieser Metrik aus dem Core Web Vitals-Set haben.

Praxisbeispiele: Innogy und ein E-Commerce-Kunde#

Wer nicht messen kann, kann nicht steuern. Wir messen, um die Geschwindigkeit von Websites zu steuern, da sie Geschäftsparameter beeinflusst.

Schauen wir uns an, wie das in der realen Welt bei unseren Kunden aussieht.

Innogy: Wie wir die Interaktivität gezähmt haben#

Bei unserem Kunden Innogy kämpften wir bei PageSpeed.ONE mit langsamen JS-Metriken auf mobilen Geräten. Die Analyse zeigte, dass das Hauptthread durch umfangreiche Skripte und komplexe Styles blockiert wurde.

Durch das Zerlegen langer Aufgaben in kleinere Teile reduzierten wir die INP-Metrik um 38 %.

Die Website ist jetzt auch auf günstigeren Telefonen flüssig. Details finden Sie in der Fallstudie.

Weniger JavaScript-Staus, mehr Bestellungen#

Bei einem anderen Kunden aus dem E-Commerce-Bereich fanden wir in unseren Analysen eine klare Verbindung. Je länger die JS Long Tasks und die INP-Metrik waren, desto niedriger waren die Konversionen.

Die blaue Linie ist die Konversionsrate, die orangefarbenen Balken der Wert der Metrik. Je mehr lange Aufgaben, desto niedriger die Konversionen.

Lange Aufgaben „froren“ die Website in entscheidenden Momenten ein. Daher konzentrieren wir uns bei diesem Kunden langfristig auf JS-Metriken, deren Optimierung hilft, Kunden im Kaufprozess zu halten.

Kurz gesagt: Eine flüssige Website ohne Long Tasks kann direkt Ihre Umsätze steigern. Ist das auch Ihr Fall? Das lässt sich mit unserer Geschäftsanalyse herausfinden.

Wie optimiert man die JS Long Tasks-Metrik?#

Diagnostik ist der Schlüssel. Ohne sie stochern Sie nur im Nebel. Sie benötigen Monitoring und Chrome DevTools. Für praktische Tipps zum Zerlegen langer Aufgaben schauen Sie sich unseren Artikel zur INP-Optimierung an.

Wie tiefer eintauchen? Sie haben im Wesentlichen zwei Wege.

1. Chrome DevTools: Öffnen Sie das Performance-Panel und zeichnen Sie eine Aktion auf der Website auf. Long Tasks sehen Sie als Blöcke mit rotem rechten Eck. Eine klare Warnung.
2. Long Tasks API: Wenn Sie Entwickler sind, können Sie Daten über diese Schnittstelle im Browser sammeln.

// Beispiel zur Überwachung von Long Tasks im Browser
const observer = new PerformanceObserver((list) => {
	for (const entry of list.getEntries()) {
		console.log(`Achtung, Long Task! Dauer: ${entry.duration}ms`);
	}
});
observer.observe({ entryTypes: ['longtask'] });

Ein Blick in die Konsole zeigt sofort, wer in der Küche nicht hinterherkommt.

Kochbuch für bessere JS Long Tasks#

Die Optimierung von JavaScript-Metriken ist anspruchsvoll, das ist wohl bekannt. Es ist immer notwendig, die Website im größeren Kontext zu betrachten und die effizienteste Lösung aus möglichen Ansätzen zu wählen. Dabei kann Ihnen das Beratungsteam von PageSpeed.ONE helfen.

Die Optimierung von Long Tasks ist keine Magie, sondern Disziplin. Hier sind die grundlegenden Vorgehensweisen:

• Yielding (Freigeben): Wenn Sie eine lange Berechnung haben, unterbrechen Sie sie. Verwenden Sie Techniken wie setTimeout(0) oder das moderne scheduler.yield(). Bei der Arbeit mit React werfen Sie einen Blick auf unsere Tipps im Artikel zur React-Optimierung. So kann der Browser „kurz ausspannen“ und Benutzereingaben verarbeiten.
• Code Splitting (Code-Aufteilung): Senden Sie nicht den gesamten Code auf einmal an den Browser. Teilen Sie ihn in kleinere Pakete auf, die nur bei Bedarf geladen werden.
• DOM-Optimierung: Je weniger Elemente Ihre Seite hat, desto schneller sind die Änderungen. Eine riesige DOM-Struktur verlangsamt jede Operation des Browsers.
• Web Workers: Ein Tipp für Technikbegeisterte. Schwere Berechnungen in ein „Nebenbüro“ (Neben-Thread) verlagern. Der Hauptthread bleibt so für Benutzerinteraktionen frei.

Monitoring PLUS: Ihr wachsames Auge#

Long Tasks auf Ihrem eigenen Computer zu überwachen ist nur der Anfang. Aber was ist mit Ihren Kunden? Unser Tool monitoring PLUS überwacht die Metriken für Sie. So erfahren Sie rechtzeitig, ob ein neues Marketing-Skript oder die Arbeit der Entwickler die Leistung Ihrer Website verschlechtert. Mehr über das Monitoring der Website-Geschwindigkeit erfahren Sie in unserem Monitoring-Leitfaden.

Wir helfen Ihnen mit dem Monitoring der Core Web Vitals und senden Ihnen Benachrichtigungen bei größeren Änderungen.

Erhalten Sie Benachrichtigungen über Änderungen der JavaScript-Metriken und der allgemeinen Geschwindigkeit Ihrer Website?

Fazit#

JS Long Tasks können ein unsichtbarer Killer der Benutzererfahrung sein. Ein schönes Design nützt wenig, wenn die Website nicht reagiert – die Konversionen sinken. Achten Sie darauf, dass Ihr Hauptthread immer Raum zum Atmen hat und überwachen Sie die Metriken INP, TBT und JSLT.

Was nun?

• Möchten Sie wissen, wie es um Ihre Website steht? Testen Sie.
• Müssen Sie Metriken optimieren? Werfen Sie einen Blick auf unsere SpeedSprint-Analyse.