Core/Dash-Dimension: LOAF

Finde die genauen Skript-URLs, die deinen main thread blockieren und den INP verschlechtern, indem du Long Animation Frames ihrer Quelle zuordnest.

Kostenlos testen

Trusted by market leaders · Client results

saturnmarktplaatsaleteiaworkivaloopearplugsadevintaerasmusmcmonarchnestledpg mediafotocasawhowhatwearsnvmy work featured on web.devkpnperionnina careharvardvpnhappyhorizoncompareebay

Dimension: Long Animation Frames (lurl)

Die LOAF-Dimension zeigt die URLs von Skripten, die Long Animation Frames während der Sitzungen deiner Nutzer verursacht haben. Jeder Wert ist eine Skript-URL: ein Erstanbieter-Bundle, ein Analyse-Tag eines Drittanbieters, ein Chat-Widget, ein Consent-Manager oder was auch immer lang genug lief, um das Rendering zu blockieren. Das ist Zuordnung auf Quellebene, nicht nur ein Stacktrace, den du in den DevTools rekonstruieren musst.

CoreDash erfasst diese Daten über die Long Animation Frames API (LoAF), die Chrome als Ersatz für die ältere Long Tasks API ausliefert. Während Long Tasks dir mitteilte, dass ein Frame zu lange dauerte, verrät dir LoAF, welche Skripte in diesem Frame liefen und was deren URLs waren. Das ist der Unterschied, der diese Dimension in der Produktion nützlich macht.

coredash loaf scripts

Warum Long Tasks nicht ausreichten

Die Long Tasks API (verfügbar seit 2017) markierte jeden main thread-Task, der 50 ms überschritt, bot aber fast keine Zuordnung. Du konntest sehen, dass eine Blockierung auftrat; du konntest nicht sehen, was sie verursacht hat. Entwickler verbrachten Stunden damit, Zeitstempel von Tasks mit Netzwerk-Wasserfällen zu korrelieren und zu raten, welches Skript verantwortlich war.

Die LoAF API ändert das. Sie liefert PerformanceLongAnimationFrameEntry-Objekte, von denen jedes ein scripts-Array enthält. Jeder Eintrag in diesem Array besitzt einen invokerType, eine sourceURL und eine duration. CoreDash liest die sourceURL für jedes Skript, das während eines langen Frames lief, und speichert sie als Wert der LOAF-Dimension. Das Ergebnis ist eine Rangliste von Skript-URLs, sortiert danach, wie oft sie in den langen Frames deiner Nutzer vorkommen.

Wie CoreDash LoAF-Daten nutzt

Jedes Mal, wenn eine Nutzerinteraktion einen langen Animationsframe auslöst, zeichnet CoreDash die beteiligten Skript-URLs zusammen mit der INP-Messung auf. Das bedeutet, dass du deine INP-Daten nach LOAF-URLs filtern und sehen kannst, welches Skript für deine schlechtesten Interaktionen verantwortlich ist. Die Dimension gruppiert nach URL, sodass du die Anzahl der Sitzungen siehst, in denen dieses Skript einen langen Frame verursacht hat.

Typische Einträge, die du in der LOAF-Dimension sehen wirst:

  • https://www.googletagmanager.com/gtm.js (Google Tag Manager-Container)
  • https://cdn.cookielaw.org/consent/... (OneTrust oder ähnliche Consent-Plattform)
  • https://js.intercomcdn.com/... (Chat-Widget)
  • /static/js/app.bundle.js (dein eigener Anwendungscode)
  • https://connect.facebook.net/en_US/fbevents.js (Meta-Pixel)

In den Daten von CoreDash verursachen Drittanbieter-Skripte etwa 60–70 % der langen Animationsframes auf Websites. Tag-Manager allein tragen auf rund 45 % der überwachten Websites zu langen Frames bei. Erstanbieter-Bundles dominieren den Rest, meist aufgrund von React-Re-Renders oder nicht optimierten Event-Handlern.

INP-Zuordnung via LoAF

Der INP misst die Zeit von der Nutzerinteraktion bis zum nächsten Frame-Paint. Überschreitet diese Spanne 200 ms, stuft Google das Nutzererlebnis als „optimierungsbedürftig“ ein. Die LoAF-Daten verraten dir, welches Skript in dieser Zeit lief. Ein INP von 280 ms, bei dem 210 ms auf ein Consent-Manager-Skript zurückzuführen sind, ist ein völlig anderes Problem als ein INP von 280 ms, bei dem 190 ms an deinem eigenen Checkout-Handler liegen. Die Lösung ist eine andere. Das zuständige Team ist ein anderes. Die Dringlichkeit ist eine andere.

Ohne die LoAF-Zuordnung sehen beide Fälle in deinem INP-Histogramm identisch aus. Mit ihr kannst du das Problem sofort der richtigen Person zuweisen.

Debugging-Workflow

  1. Öffne die LOAF-Dimension in CoreDash: Sortiere nach Häufigkeit (wie viele Sitzungen diese URL in einem langen Frame hatten). Der oberste Eintrag ist dein wichtigstes Ziel.
  2. Kreuzfilter mit dem INP: Wende den LOAF-Filter auf deine INP-Metrikansicht an. Prüfe, ob sich der p75-Wert des INP verändert, wenn du die Sitzungen isolierst, in denen dieses Skript lief. Ein Anstieg von über 30 ms bestätigt, dass das Skript zur INP-Verschlechterung in der Produktion beiträgt.
  3. Klassifiziere nach Erst- oder Drittanbieter: Deine eigene Domain in der URL bedeutet, dass du die Behebung selbst in der Hand hast. Eine Drittanbieter-CDN-URL bedeutet, dass du das Skript des Anbieters entweder entfernen, verzögern oder ersetzen musst.
  4. Behebe das Problem und verifiziere: Verzögere bei Drittanbieter-Skripten das Laden bis nach der ersten Nutzerinteraktion mithilfe einer Facade oder einer verzögerten Initialisierung. Analysiere bei Erstanbieter-Code die spezifische Funktion in den Chrome DevTools mit 4-facher CPU-Drosselung. Deploye die Änderung und beobachte, wie sich die LOAF-Dimension innerhalb von 24–48 Stunden durch echten Nutzertraffic aktualisiert.

Faustregeln für Entwickler

  • Jede einzelne Skript-URL, die in mehr als 5 % der Sitzungen in langen Frames auftaucht, ist eine Untersuchung wert. Bei dieser Quote betrifft sie im Laufe des Monats einen messbaren Teil der echten Nutzer.
  • Drittanbieter-Skripte sollten nicht in Interaktions-Handlern ausgeführt werden. Wenn ein Tag-Manager synchron bei einem Klick-Event feuert, ist das ein Konfigurationsproblem, keine Einschränkung des Browsers.
  • Eine lange Frame-Dauer von über 200 ms für ein einzelnes Skript ist ein klares Signal. Die LoAF API meldet die Dauer pro Skript innerhalb des Frames. Jedes Skript, das 200 ms oder mehr eines Frames beansprucht, ist die Hauptursache für jeden darauf folgenden INP-Wert.
  • Erstanbieter-Skripte in der LOAF-Liste weisen oft auf Framework-Overhead hin. React, Vue und Angular können bei State-Updates lange Frames verursachen. Die LoAF-URL zeigt dann auf dein eigenes Bundle. Analysiere den Komponentenbaum, nicht nur das Netzwerk.

Die LOAF-Dimension liefert dir etwas, das kein synthetischer Test bieten kann: den Beleg dafür, welche Skripte echte Nutzer in der Produktion blockieren, sortiert nach ihrer Häufigkeit in der Praxis. Filtere danach, gleiche sie mit deinen INP-Daten ab und du erhältst eine priorisierte Liste, was genau in welcher Reihenfolge zu beheben ist.