Core/Dash Dimension: Eingabetyp (INP)

Dimension: Eingabetyp INP (inpit)

Die Dimension Eingabetyp (INP) zeichnet den DOM-Ereignistyp auf, der die einzelne schlechteste Interaktion während des Seitenbesuchs eines Nutzers ausgelöst hat. Der Wert ist der rohe Ereignisname aus der Event Timing API des Browsers: click, keydown, pointerdown, pointerup, keypress und eine Handvoll anderer.

INP ist eine Worst-Case-Metrik. Sie bildet keinen Durchschnitt der Interaktionen. Sie findet die eine Interaktion, die von der Eingabe bis zum nächsten Paint am längsten gedauert hat, und meldet diese Dauer. Die Eingabetyp-Dimension sagt Ihnen, was der Nutzer in genau diesem Moment getan hat. Das ist der Unterschied zwischen dem Wissen, dass "INP bei 450ms liegt" und dem Wissen, dass "INP bei 450ms liegt, weil der Nutzer in Ihr Suchfeld getippt hat".

Die Event Timing API gruppiert zusammengehörige Ereignisse in einer einzigen logischen Interaktion. Ein Tippen auf einen Touchscreen löst pointerdown, pointerup und click als eine Gruppe aus. Der einzelne längste Event-Handler innerhalb dieser Gruppe bestimmt die Interaktionslatenz. CoreDash zeichnet den Ereignistyp des längsten Handlers auf, der die Interaktion verlangsamt hat.

Warum der Eingabetyp für INP wichtig ist

Jeder Eingabetyp entspricht einem anderen Teil Ihrer JavaScript-Codebasis. Wenn Sie keydown als dominanten Eingabetyp auf einer Seite mit schlechtem INP sehen, wissen Sie sofort, dass das Problem bei Ihren Tastenanschlag-Handlern liegt: Autovervollständigung, Suche während der Eingabe, Formularvalidierung bei jedem Tastendruck. Wenn Sie click sehen, liegt das Problem in Ihren Button- und Link-Handlern: Navigationslogik, Statusaktualisierungen, modale Fenster, die sich öffnen, Analytics-Aufrufe, die synchron ausgelöst werden.

Ohne diese Dimension beginnt eine INP-Untersuchung mit Profiling-Sitzungen, Reproduktionsschritten und dem Raten, welche Interaktion der Nutzer im 75. Perzentil gerade ausführen wollte. Mit der Eingabetyp-Dimension springen Sie direkt zum relevanten Handler. Die Zeitersparnis ist real.

Der Eingabetyp deckt auch Plattformunterschiede auf. Eine Website mit starker Tastaturnavigation durch Power-User wird einen hohen Anteil an keydown-Ereignissen aufweisen, die zu einem schlechten INP führen. Ein Produkt, das primär auf Mobilgeräten genutzt wird, wird von pointerdown dominiert. Dieselbe Seite, derselbe INP-Wert, derselbe Fix, der auf verschiedene Handler angewendet wird, je nachdem, wer Ihre Nutzer tatsächlich sind.

Die Eingabetypen

click und pointerdown

Dies sind die häufigsten Eingabetypen in den CoreDash-Daten und machen etwa 75 % der Worst-Case INP-Ereignisse aus. Auf dem Desktop repräsentiert click das Loslassen der Maustaste. Auf Mobilgeräten löst ein Tippen die gesamte Kette aus: Zuerst feuert pointerdown, wenn der Finger den Bildschirm berührt, dann pointerup beim Anheben und schließlich click am Ende. CoreDash zeichnet das Ereignis aus dieser Kette auf, das den längsten Handler hatte.

Klick-Handler sind der primäre Ort für schwere synchrone JavaScript-Arbeit. Ein einzelner Klick auf ein Navigationselement kann Statusaktualisierungen, DOM-Mutationen, Analytics-Ereignisse und ein Re-Rendering auslösen – alles in derselben Aufgabe (Task). Jede Millisekunde an synchroner Arbeit in einem Klick-Handler ist eine Millisekunde, die zum INP addiert wird.

Die Lösung für langsame Klick-Handler ist die Zerlegung von Aufgaben (Task Decomposition). Verwenden Sie <code>scheduler.yield()</code>, um den Handler in kleinere Tasks aufzuteilen und den Browser zwischen ihnen rendern zu lassen. Verschieben Sie unkritische Arbeiten wie Analytics-Aufrufe in ein setTimeout mit einer Verzögerung von null oder verschieben Sie diese vollständig auf requestIdleCallback. Der Browser muss vor dem nächsten Paint nur die Arbeit abschließen, die die visuelle Antwort beeinflusst. Alles andere kann warten.

keydown

Tastatureingaben machen etwa 15 % der Worst-Case INP-Ereignisse in den CoreDash-Daten aus, erzeugen aber einige der schlimmsten Werte. Der Grund ist die Häufigkeit: Ein Nutzer, der in ein Suchfeld tippt, löst bei jedem einzelnen Tastendruck keydown aus. Wenn Ihr Handler 200ms benötigt, erfährt der Nutzer nach jedem getippten Zeichen eine Verzögerung von 200ms. Eine Suchanfrage mit 10 Zeichen wird so zu 2 Sekunden akkumulierter Blockierungszeit.

Die häufigsten Übeltäter sind Search-as-you-type-Implementierungen, die bei jedem Tastendruck synchrone API-Anfragen auslösen oder teures DOM-Diffing ausführen, sowie Formularvalidierungen, die das gesamte Formular bei jedem Tastendruck erneut überprüfen. Diese Muster funktionieren im kleinen Maßstab gut, brechen aber unter realen Nutzerbedingungen zusammen.

Die Standardlösungen sind Debouncing und Auslagerung (Offloading). Debouncen Sie Ihren Such-Handler so, dass er erst feuert, wenn der Nutzer aufhört zu tippen, typischerweise nach 200 bis 300 Millisekunden. Für komplexere Verarbeitungen wie die Fuzzy-Suche über einen großen lokalen Datensatz hinweg, lagern Sie die Berechnung in einen Web Worker aus, damit der Main-Thread frei bleibt, um den nächsten Frame nach jedem keydown-Ereignis zu rendern.

pointerup

Pointer-Up-Ereignisse machen etwa 8 % der Worst-Case INP-Fälle in den CoreDash-Daten aus. pointerup feuert am Ende einer Berührungs- oder Klicksequenz, nach pointerdown. Einige Frameworks und UI-Bibliotheken binden ihr primäres "Klick"-Verhalten an pointerup anstatt an click, was den Handler weiter nach vorne im Lebenszyklus der Interaktion verlagert.

Wenn pointerup als dominanter Eingabetyp auftritt, ist die Untersuchung dieselbe wie bei Klick-Handlern: Finden Sie heraus, welches JavaScript im Handler ausgeführt wird, und trennen Sie die Arbeit, die das nächste Paint blockieren muss, von der Arbeit, die verschoben werden kann. Die Unterscheidung von click ist in der Regel eine Entscheidung auf Framework-Ebene, nicht auf Anwendungs-Ebene, sodass die Lösung Anpassungen daran erfordern kann, wie die Komponentenbibliothek das Binden von Interaktionen handhabt.

Debugging-Workflow

1. Nach Eingabetyp in CoreDash filtern: Öffnen Sie die INP-Aufschlüsselung für eine fehlerhafte URL und prüfen Sie, welcher Eingabetyp die schlechtesten Interaktionen dominiert. Wenn ein Typ mehr als die Hälfte Ihrer schlechten INP-Ereignisse ausmacht, beginnen Sie dort. Die Verteilung sagt Ihnen, wo Sie Ihre Profiling-Zeit investieren sollten.
2. Mit der richtigen Interaktion reproduzieren: Öffnen Sie die Chrome DevTools, aktivieren Sie das Performance-Profiling und führen Sie genau den in CoreDash angezeigten Interaktionstyp aus. Eine von keydown dominierte Seite sollte durch Tippen getestet werden. Eine von click dominierte Seite sollte mit Mausklicks auf die Elemente getestet werden, mit denen Ihre Nutzer interagieren. Zeichnen Sie den Trace auf und identifizieren Sie die langen Tasks im Main-Thread, die unmittelbar nach dem Eingabeereignis ausgelöst werden.
3. Den typspezifischen Fix anwenden und verifizieren: Für keydown-Probleme fügen Sie Debouncing hinzu und profilieren Sie erneut. Für click-Probleme fügen Sie scheduler.yield()-Aufrufe an logischen Haltepunkten im Handler hinzu. Stellen Sie dies in einer Testumgebung bereit, verwenden Sie WebPageTest mit Interaction-Scripting oder das Chrome DevTools Performance-Panel, und bestätigen Sie, dass die Task-Dauer sinkt, bevor Sie es ausliefern.

Technische Faustregeln

• keydown dominiert Ihren schlechten INP: Fügen Sie allen Such- und Autovervollständigungs-Handlern Debouncing hinzu. Eine Verzögerung von 200ms ist der Standard-Startpunkt. Wenn die Berechnung selbst bei dieser Verzögerung teuer ist, verschieben Sie diese mit einem Web Worker aus dem Main-Thread.
• click oder pointerdown dominiert: Ihre Handler leisten zu viel synchrone Arbeit, bevor der Browser painten kann. Überprüfen Sie jeden Klick-Handler auf der fehlerhaften URL. Entfernen Sie synchrone Analytics-Aufrufe. Unterbrechen Sie mehrstufige Logik mit scheduler.yield() zwischen den Schritten.
• pointerup dominiert: Prüfen Sie, ob Ihr Framework Interaktionslogik an pointerup anstelle von click bindet. Der Fix ist normalerweise derselbe wie bei Klick-Handlern, aber der Einstiegspunkt in der Codebasis ist ein anderer.
• Gemischte Verteilung ohne klaren Gewinner: Das Problem ist nicht ein einzelner Interaktionstyp. Profilieren Sie die drei langsamsten individuellen Interaktionen über alle Typen hinweg und beheben Sie diese in der Reihenfolge ihrer Auswirkung. Optimieren Sie nicht abstrakt.

Der Eingabetyp ist ein Routing-Signal. Er sagt Ihnen nicht, was langsam ist. Er sagt Ihnen, wo Sie suchen müssen. Sobald Sie wissen, ob Ihre Nutzer klicken, tippen oder auf den Bildschirm tippen, wenn der INP einbricht, wird jeder nachfolgende Untersuchungsschritt schneller und zielgerichteter.