CoreDash-Dimension: LOAF

Finden Sie die exakten Script-URLs, die Ihren main thread blockieren und den INP verschlechtern, indem Sie Long Animation Frames ihrer Quelle zuordnen.

Kostenlose Testversion

Trusted by market leaders · Client results

whowhatwearebayhappyhorizonaleteiafotocasamonarchsnvdpg mediaworkivaerasmusmccomparekpnnina carenestleloopearplugsmarktplaatsadevintavpnmy work featured on web.devsaturnharvardperion

Dimension: Long Animation Frames (lurl)

Die LOAF-Dimension zeigt die URLs von Scripten an, die während der Sitzungen Ihrer Benutzer Long Animation Frames verursacht haben. Jeder Wert ist eine Script-URL: ein First-Party-Bundle, ein Drittanbieter-Analyse-Tag, ein Chat-Widget, ein Consent-Manager oder was auch immer lange genug lief, um das Rendering zu blockieren. Dies ist eine Zuordnung auf Quellenebene, nicht nur ein Stack-Trace, den Sie in den DevTools mühsam rekonstruieren müssen.

CoreDash sammelt diese Daten mithilfe der Long Animation Frames API (LoAF), die Chrome als Ersatz für die ältere Long Tasks API eingeführt hat. Während Long Tasks Ihnen mitteilte, dass ein Frame zu lange dauerte, sagt Ihnen LoAF, welche Scripte innerhalb dieses Frames liefen und wie deren URLs lauteten. Das ist der entscheidende Unterschied, der diese Dimension in der Produktion so nützlich macht.

coredash loaf scripts

Warum Long Tasks nicht ausreichten

Die Long Tasks API (verfügbar seit 2017) markierte jede Aufgabe im main thread, die 50 ms überschritt, lieferte Ihnen jedoch fast keine Informationen zur Zuordnung. Sie konnten sehen, dass eine Blockierung auftrat, aber nicht, was sie verursacht hatte. Entwickler verbrachten Stunden damit, Zeitstempel von Aufgaben mit Netzwerk-Waterfalls zu korrelieren und zu raten, welches Script verantwortlich war.

Die LoAF API ändert dies. Sie meldet PerformanceLongAnimationFrameEntry-Objekte, die jeweils ein scripts-Array enthalten. Jeder Eintrag in diesem Array hat einen invokerType, eine sourceURL und eine duration. CoreDash liest die sourceURL für jedes Script aus, das während eines langen Frames lief, und speichert sie als Wert der LOAF-Dimension. Das Ergebnis ist eine Rangliste von Script-URLs, sortiert danach, wie oft sie in den langen Frames Ihrer Benutzer auftauchen.

Wie CoreDash LoAF-Daten nutzt

Jedes Mal, wenn eine Benutzerinteraktion einen langen Animations-Frame auslöst, zeichnet CoreDash die beteiligten Script-URLs zusammen mit der INP-Beobachtung auf. Das bedeutet, dass Sie Ihre INP-Daten nach der LOAF-URL filtern können, um zu sehen, welches Script für Ihre schlechtesten Interaktionen verantwortlich ist. Die Dimension gruppiert nach URL, sodass Sie sehen, in wie vielen Sitzungen dieses Script einen langen Frame verursacht hat.

Typische Einträge, die Sie in der LOAF-Dimension sehen werden:

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

In den CoreDash-Daten verursachen Drittanbieter-Scripte auf etwa 60-70 % der Websites Long Animation Frames. Allein Tag Manager tragen auf ca. 45 % der überwachten Seiten zu langen Frames bei. Den Rest dominieren First-Party-Bundles, meist aufgrund von React Re-renders oder nicht optimierten Event-Handlern.

INP-Zuordnung via LoAF

INP misst die Zeit von der Benutzerinteraktion bis zum nächsten Frame-Paint. Wenn diese Lücke 200 ms überschreitet, stuft Google das Erlebnis als „verbesserungswürdig“ ein. Die LoAF-Daten verraten Ihnen, welches Script während dieser Lücke lief. Ein INP von 280 ms, bei dem 210 ms auf das Script eines Consent-Managers zurückzuführen sind, ist ein völlig anderes Problem als ein INP von 280 ms, bei dem 190 ms auf Ihren eigenen Checkout-Handler entfallen. Die Lösung ist eine andere. Das verantwortliche Team ist ein anderes. Die Dringlichkeit ist eine andere.

Ohne LoAF-Attribution sähen beide in Ihrem INP-Histogramm identisch aus. Mit ihr können Sie das Problem sofort an die richtige Person weiterleiten.

Debugging-Workflow

  1. Öffnen Sie die LOAF-Dimension in CoreDash: Sortieren Sie nach Häufigkeit (wie viele Sitzungen diese URL in einem langen Frame gesehen haben). Der oberste Eintrag ist Ihr Ziel mit der höchsten Priorität.
  2. Cross-Filter mit INP: Wenden Sie den LOAF-Filter auf Ihre INP-Metrik-Ansicht an. Prüfen Sie, ob sich der INP p75 ändert, wenn Sie Sitzungen isolieren, in denen dieses Script lief. Ein Anstieg von mehr als 30 ms bestätigt, dass das Script zur INP-Verschlechterung in der Produktion beiträgt.
  3. Klassifizierung als First-Party oder Drittanbieter: Ihre eigene Domain in der URL bedeutet, dass Sie die Korrektur kontrollieren. Eine Drittanbieter-CDN-URL bedeutet, dass Sie das Script des Anbieters entweder entfernen, verzögern oder ersetzen müssen.
  4. Wenden Sie die Korrektur an und verifizieren Sie: Verzögern Sie bei Drittanbieter-Scripten das Laden bis nach der ersten Benutzerinteraktion mithilfe einer Fassade oder eines verzögerten Init. Bei First-Party-Code profilieren Sie die spezifische Funktion in den Chrome DevTools mit einer CPU-Drosselung auf das 4-fache. Veröffentlichen Sie die Änderung und beobachten Sie, wie sich die LOAF-Dimension innerhalb von 24-48 Stunden echten Benutzer-Traffics aktualisiert.

Engineering-Faustregel

  • Jede einzelne Script-URL, die in mehr als 5 % der Sitzungen in langen Frames erscheint, ist eine Untersuchung wert. Bei dieser Rate beeinträchtigt sie einen messbaren Teil der echten Benutzer über den Monat hinweg.
  • Drittanbieter-Scripte sollten nicht während Interaktions-Handlern laufen. Wenn ein Tag Manager synchron bei einem Klick-Ereignis ausgelöst wird, ist das ein Konfigurationsproblem, keine Browser-Beschränkung.
  • Eine lange Frame-Dauer über 200 ms für ein einzelnes Script ist ein klares Signal. Die LoAF API meldet die Dauer pro Script innerhalb des Frames. Jedes Script, das 200 ms oder mehr eines Frames beansprucht, ist die Hauptursache für den darauffolgenden INP.
  • First-Party-Scripte in der LOAF-Liste deuten oft auf Framework-Overhead hin. React, Vue und Angular können alle bei Status-Updates lange Frames erzeugen. Die LOAF-URL wird dann Ihr eigenes Bundle sein. Profilieren Sie den Komponentenbaum, nicht nur das Netzwerk.

Die LOAF-Dimension liefert Ihnen etwas, das kein synthetischer Test kann: den Beweis, welche Scripte echte Benutzer in der Produktion blockieren, sortiert nach ihrer Häufigkeit in der realen Welt. Filtern Sie danach, setzen Sie es in Beziehung zu Ihren INP-Daten, und Sie haben eine prioritätsgesteuerte Liste dessen, was genau und in welcher Reihenfolge zu beheben ist.