Dimension Core/Dash: Ladezustand (INP)

Dimension: Ladezustand INP (inpls)

Die Dimension Ladezustand (INP) erfasst den document.readyState in genau dem Moment, in dem eine Benutzerinteraktion erfasst wurde. Jedes INP-Ereignis im Chrome User Experience Report trägt ein Tag für den Ladezustand: entweder loading, dom-interactive, dom-content-loaded oder complete. CoreDash stellt dieses Tag als filter- und gruppierbare Dimension dar, damit Sie die Frage beantworten können, die rohe INP-Werte nicht beantworten können: Wann im Lebenszyklus der Seite fand die schlechteste Interaktion statt?

Diese Frage ist die Trennlinie zwischen zwei völlig unterschiedlichen technischen Lösungsansätzen. Ein INP-Problem, das sich während loading häuft, erfordert eine JavaScript-Verzögerungsstrategie (Deferral). Ein INP-Problem, das sich während complete häuft, erfordert die Reduzierung der Arbeit von Event-Handlern, die Verringerung des Framework-Overheads oder das Aufteilen langer Aufgaben in Ihrem Laufzeitcode. Die Gruppierung nach Ladezustand liefert Ihnen diese Aufschlüsselung ohne jegliche manuelle Instrumentierung.

In den CoreDash-Daten über überwachte Websites hinweg ist die Verteilung der INP-Interaktionen nach Ladezustand in etwa wie folgt: loading 15 %, dom-interactive 20 %, dom-content-loaded 25 %, complete 40 %. Die Mehrheit der Interaktionen findet statt, nachdem die Seite vollständig geladen ist, aber die schlechtesten INP-Werte häufen sich überwältigend in den frühen Zuständen.

Screenshot

Warum der Ladezustand für den INP wichtig ist

Die Metrik Interaction to Next Paint misst die gesamte Latenz einer Benutzerinteraktion: Eingabeverzögerung (Input Delay), Verarbeitungszeit des Event-Handlers und Darstellungsverzögerung (Presentation Delay) bis zum nächsten gezeichneten Frame. Von diesen drei Komponenten wird die Eingabeverzögerung am direktesten davon gesteuert, was der Browser in dem Moment tut, in dem der Benutzer klickt oder tippt.

Während des frühen Ladens der Seite herrscht auf dem Haupt-Thread der größte Konkurrenzkampf. Der Browser parst HTML, führt synchrone Skripte aus, baut das CSSOM auf, lädt parser-blockierende Ressourcen und löst Render-Zyklen direkt nacheinander aus. Jede lange Aufgabe (Long Task) auf dem Haupt-Thread ist ein Zeitfenster, in dem eine Benutzerinteraktion in die Warteschlange gestellt wird und wartet. Dieses Warten ist die Eingabeverzögerung, und sie ist die Hauptursache für einen schlechten INP während des Ladens der Seite.

Interaktionen, die eintreffen, nachdem document.readyState den Zustand complete erreicht hat, stoßen auf einen ruhigeren Haupt-Thread. Der Browser ist mit dem Laden fertig. Wenn der INP in dieser Phase immer noch schlecht ist, liegt die Ursache nicht an der Konkurrenz beim Laden. Es ist das JavaScript, das Ihre Seite als Reaktion auf Benutzeraktionen ausführt: aufgeblähte Event-Handler, Framework-Re-Render-Zyklen, Layout-Thrashing, das durch Skripte ausgelöst wird, oder unoptimierter Drittanbieter-Code, der während der Interaktion synchron ausgeführt wird.

Der Ladezustand ist der mit Abstand schnellste Filter zur Trennung dieser beiden Hauptursachen.

Die Ladezustände

loading

Die Seite hat das Parsen des HTML-Dokuments noch nicht abgeschlossen. Der Haupt-Thread führt synchrone Skripte aus, ruft parser-blockierende Ressourcen ab und erstellt das initiale DOM. Dies ist die feindlichste Umgebung für Benutzerinteraktionen. Die Eingabeverzögerung ist am höchsten, da jede lange Aufgabe den Browser direkt daran hindert, den Klick oder das Tippen zu verarbeiten. Benutzer, die in diesem Zeitfenster interagieren, sind in der Regel die ungeduldigsten Besucher oder solche mit schnellen Verbindungen, die den sichtbaren Inhalt erreichen, bevor das Laden der Seite abgeschlossen ist. Ihre INP-Werte sind die schlechtesten, die Sie erfassen werden. Wenn ein bedeutender Anteil Ihrer schlechten INP-Ereignisse den Zustand loading trägt, verschieben Sie unkritische Skripte auf defer oder async und eliminieren Sie parser-blockierende Ressourcen oberhalb des Falzes (above the fold).

dom-interactive

document.readyState erreicht interactive, wenn das HTML vollständig geparst und das DOM aufgebaut ist, Subressourcen wie Bilder, Stylesheets und verzögerte Skripte (defer) jedoch noch geladen werden. Verzögerte Skripte beginnen an diesem Punkt mit der Ausführung, was bedeutet, dass der Haupt-Thread immer noch stark ausgelastet sein kann. Die Framework-Hydration (Hydration) beginnt oft hier. Dies ist ein gefährliches Zeitfenster, da die Seite für den Benutzer bereit aussieht, der Haupt-Thread aber noch beschäftigt ist. Die Eingabeverzögerung bleibt hoch. Wenn sich schlechte INP-Werte hier konzentrieren, ist die Lösung dieselbe wie bei loading: Reduzieren Sie das Volumen der synchronen Arbeit, die unmittelbar nach Abschluss des DOM-Parsings ausgeführt wird.

dom-content-loaded

Das DOMContentLoaded-Ereignis wurde ausgelöst. Das DOM ist vollständig und verzögerte Skripte wurden ausgeführt. Die meisten JavaScript-Frameworks haben zu diesem Zeitpunkt ihren ersten Hydration-Durchlauf beendet. Die Arbeitslast auf dem Haupt-Thread sinkt, und Interaktionen beginnen, schnellere Antworten zu erhalten. INP-Werte in diesem Zustand sind in der Regel besser als in den beiden früheren Zuständen, aber im Vergleich zu complete immer noch erhöht. Wenn Sie hier eine Häufung von schlechten Interaktionen sehen, untersuchen Sie, was Ihre Framework- oder Anwendungsskripte in den DOMContentLoaded-Handlern tun und ob Hydration-Arbeiten in Blöcke aufgeteilt oder pausiert (yielded) werden können, um die Eingabeverarbeitung zwischen den Aufgaben zu ermöglichen.

complete

document.readyState erreicht complete, wenn alle Ressourcen einschließlich Bilder, Schriftarten und Drittanbieter-Iframes geladen sind. Dies ist der stationäre Zustand, in dem die Seite für den Rest der Sitzung arbeitet. Ein schlechter INP in diesem Zustand ist ein reines Laufzeitproblem. Das Laden der Seite ist abgeschlossen. Wenn der Haupt-Thread Interaktionen immer noch blockiert, liegt die Ursache in Ihrer JavaScript-Ausführung während der Interaktion: Event-Handler, die zu viel synchrone Arbeit leisten, Framework-Updates, die teure Layout-Neuberechnungen auslösen, oder Drittanbieter-Skripte, die kontinuierlich lange Aufgaben ausführen. Bei der Behebung geht es nicht um eine Verzögerung. Es geht darum, die Kosten dessen zu senken, was passiert, wenn der Benutzer tatsächlich klickt.

Debugging-Workflow

Schritt 1: In CoreDash nach Ladezustand filtern. Öffnen Sie die INP-Aufschlüsselungstabelle und gruppieren Sie nach Ladezustand. Identifizieren Sie, welcher Zustand den höchsten Anteil an schlechten Interaktionen (über 200 ms) aufweist. Dies sagt Ihnen sofort, ob es sich um ein Ladeproblem oder ein Laufzeitproblem handelt.

Schritt 2: Kreuzreferenz mit URL und Gerät. Kombinieren Sie die Dimension Ladezustand mit der Dimension URL, um herauszufinden, welche spezifischen Seiten während der frühen Ladezustände schlechte Interaktionen erzeugen. Mobilgeräte sind während des Ladevorgangs überproportional betroffen, da langsamere CPUs jede lange Aufgabe verlängern.

Schritt 3: Passen Sie die Lösung an den Zustand an. Bei loading und dom-interactive prüfen Sie Ihre Strategie zum Laden von Skripten anhand des Leitfadens zur INP-Optimierung. Verschieben Sie Skripte auf defer, eliminieren Sie render-blockierende Ressourcen und verwenden Sie scheduler.yield(), um lange Initialisierungsaufgaben aufzubrechen. Bei complete profilieren Sie Ihre Event-Handler in den Chrome DevTools und reduzieren Sie die synchrone Arbeit, die sie pro Interaktion auslösen.

Faustregel für Ingenieure

Wenn mehr als 30 % Ihrer schlechten INP-Interaktionen mit loading oder dom-interactive markiert sind, ist Ihr INP-Problem ein Problem beim Laden der Seite, und eine JavaScript-Verzögerung wird die größte Verbesserung bringen. Wenn mehr als 60 % der schlechten Interaktionen mit complete markiert sind, ist Ihr INP-Problem ein Laufzeitproblem, und Sie müssen die Kosten für den Event-Handler optimieren, nicht die Reihenfolge, in der Skripte geladen werden. Die Dimension Ladezustand (INP) trifft diese Entscheidung in einer einzigen Tabellenansicht, ohne dass eine Laborsitzung oder eine benutzerdefinierte Instrumentierung erforderlich ist.