Core/Dash-Dimension: Load State (INP)

Dimension: Load State INP (inpls)

Die Dimension Load State (INP) erfasst den Ready-State des Dokuments im exakten Moment der Benutzerinteraktion. Jedes INP-Ereignis im Chrome User Experience Report trägt ein Load-State-Tag: entweder loading, dom-interactive, dom-content-loaded oder complete. CoreDash zeigt dieses Tag als filterbare, gruppierbare Dimension. So beantwortest du die Frage, die reine INP-Werte nicht beantworten können: Wann im Page-Lifecycle fand die schlechteste Interaktion statt?

Diese Frage zieht die Trennlinie zwischen zwei völlig unterschiedlichen Optimierungen. Häufen sich INP-Probleme während loading, hilft eine JavaScript-Deferral-Strategie. Liegt der Schwerpunkt bei complete, musst du die Arbeit im Event-Handler reduzieren, Framework-Overhead minimieren oder long tasks im Laufzeit-Code aufteilen. Die Gruppierung nach Load State liefert diese Aufteilung ohne manuelle Instrumentierung.

In den CoreDash-Daten der überwachten Websites ist die Verteilung der INP-Interaktionen nach Load State in etwa: loading 15 %, dom-interactive 20 %, dom-content-loaded 25 %, complete 40 %. Die meisten Interaktionen finden statt, wenn die Seite vollständig geladen ist. Die schlechtesten INP-Werte häufen sich jedoch massiv in den frühen Zuständen.

Screenshot

Warum der Load State für den INP wichtig ist

Die Metrik Interaction to Next Paint misst die gesamte Latenz einer Benutzerinteraktion: input delay, Verarbeitungszeit des Event-Handlers und presentation delay bis zum nächsten Frame-Paint. Von diesen drei Komponenten wird das input delay am direktesten davon beeinflusst, was der Browser im Moment des Klicks oder Tippens tut.

Während der frühen Ladephase der Seite ist der main thread maximal ausgelastet. Der Browser parst HTML, führt synchrone Skripte aus, baut das CSSOM auf, verarbeitet parser-blocking Ressourcen und triggert Render-Zyklen direkt nacheinander. Jede long task auf dem main thread blockiert den Browser; die Benutzerinteraktion wird eingereiht und wartet. Diese Wartezeit ist das input delay. Es ist der Haupttreiber für schlechten INP beim Laden der Seite.

Interaktionen, die erst stattfinden, wenn document.readyState den Zustand complete erreicht hat, treffen auf einen ruhigeren main thread. Der Browser hat das Laden abgeschlossen. Wenn der INP in dieser Phase immer noch schlecht ist, liegt das nicht an der Auslastung durch den Ladevorgang. Die Ursache ist die JavaScript-Ausführung während der Interaktion: Event-Handler erledigen zu viel synchrone Arbeit, Framework-Updates triggern teure Layout-Neuberechnungen oder Drittanbieter-Skripte führen dauerhaft long tasks aus. Die Lösung ist hier nicht Deferral. Du musst die Kosten dessen reduzieren, was beim Klick des Nutzers tatsächlich passiert.

Der Load State ist der schnellste Filter, um diese beiden Hauptursachen voneinander zu trennen.

Die Load States

loading

Die Seite hat das Parsen des HTML-Dokuments noch nicht abgeschlossen. Der main thread führt synchrone Skripte aus, lädt parser-blocking Ressourcen und baut das initiale DOM auf. Dies ist die unvorteilhafteste Umgebung für Benutzerinteraktionen. Das input delay ist am höchsten, da jede long task den Browser direkt beim Verarbeiten des Klicks oder Fingertipps blockiert. Nutzer, die in diesem Zeitfenster interagieren, sind meist besonders ungeduldige Besucher oder solche mit schnellen Verbindungen, die sichtbare Inhalte sehen, bevor die Seite fertig geladen ist. Ihre INP-Werte sind die schlechtesten, die du erfassen wirst. Trägt ein nennenswerter Teil deiner schlechten INP-Ereignisse das Label loading, verschiebe nicht-kritische Skripte mittels defer oder async und eliminiere parser-blocking Ressourcen above the fold.

dom-interactive

document.readyState erreicht interactive, wenn das HTML vollständig geparst und das DOM aufgebaut ist, aber Subressourcen wie Bilder, Stylesheets und verzögerte Skripte noch geladen werden. Verzögerte Skripte beginnen jetzt mit der Ausführung, was den main thread stark belasten kann. Oft startet hier die Framework-Hydration. Dieses Zeitfenster ist gefährlich: Die Seite sieht für den Nutzer fertig aus, aber der main thread is noch beschäftigt. Das input delay bleibt erhöht. Wenn sich schlechte INP-Werte hier konzentrieren, ist die Lösung dieselbe wie bei loading: Reduziere die Menge an synchroner Arbeit, die direkt nach dem DOM-Parsing läuft.

dom-content-loaded

Das DOMContentLoaded-Event wurde ausgelöst. Das DOM ist vollständig und verzögerte Skripte sind ausgeführt. Die meisten JavaScript-Frameworks haben zu diesem Zeitpunkt ihren initialen Hydration-Durchlauf abgeschlossen. Die Last auf dem main thread sinkt, und Interaktionen erhalten schnellere Antworten. Die INP-Werte in diesem Zustand sind typischerweise besser als in den beiden früheren Zuständen, im Vergleich zu complete aber immer noch erhöht. Siehst du hier eine Häufung schlechter Interaktionen, analysiere, was dein Framework oder deine Anwendungs-Skripte in DOMContentLoaded-Handlern tun und ob die Hydration-Arbeit aufgeteilt oder yielded werden kann, um die Eingabeverarbeitung zwischen Tasks zu ermöglichen.

complete

document.readyState erreicht complete, wenn alle Ressourcen wie Bilder, Schriftarten und Drittanbieter-Iframes geladen sind. Dies ist der stabile Zustand der Seite für den Rest der Sitzung. Ein schlechter INP in diesem Zustand ist ein reines Laufzeitproblem. Die Seite ist fertig geladen. Blockiert der main thread weiterhin Interaktionen, liegt das an der JavaScript-Ausführung während der Interaktion: Event-Handler erledigen zu viel synchrone Arbeit, Framework-Updates triggern teure Layout-Neuberechnungen oder Drittanbieter-Skripte führen dauerhaft long tasks aus. Die Lösung ist hier nicht Deferral. Du musst die Kosten dessen reduzieren, was beim Klick des Nutzers tatsächlich passiert.

Debugging Workflow

Schritt 1: Nach Load State in CoreDash filtern. Öffne die INP-Aufschlüsselungstabelle und gruppiere nach Load State. Identifiziere, welcher Zustand den höchsten Anteil an schlechten Interaktionen (über 200 ms) hat. Das zeigt dir sofort, ob du ein Lade- oder ein Laufzeitproblem vor dir hast.

Schritt 2: Mit URL und Gerät abgleichen. Kombiniere die Load-State-Dimension mit der URL-Dimension. So findest du heraus, welche spezifischen Seiten schlechte Interaktionen in frühen Ladephasen erzeugen. Mobilgeräte sind beim Laden überproportional betroffen, da langsamere CPUs jede long task verlängern.

Schritt 3: Passe die Lösung an den Zustand an. Analysiere für loading und dom-interactive deine Strategie zum Laden von Skripten mit dem Optimize INP Guide. Verschiebe Skripte auf defer, eliminiere render-blocking Ressourcen und nutze scheduler.yield(), um lange Initialisierungs-Tasks aufzuteilen. Profile für complete deine Event-Handler in den Chrome DevTools und reduziere die synchrone Arbeit, die sie pro Interaktion auslösen.

Technische Faustregel

Wenn mehr als 30 % deiner schlechten INP-Interaktionen mit loading oder dom-interactive markiert sind, ist dein INP-Problem ein Ladezeit-Problem. In diesem Fall bringt JavaScript-Deferral die größte Verbesserung. Wenn mehr als 60 % der schlechten Interaktionen mit complete markiert sind, hast du ein Laufzeitproblem. Du musst die Kosten der Event-Handler optimieren, nicht die Ladereihenfolge der Skripte. Load State (INP) liefert diese Entscheidung in einer einzigen Tabellenansicht – ganz ohne Lab-Messung oder eigene Instrumentierung.