INP verbessern: Interaction to Next Paint unter 200 ms
Die Search Console meldet einen schlechten INP-Wert, Lighthouse ist aber grün? Wie Sie die Ursache einer trägen Interaktion finden, welche Skripte typischerweise dahinterstecken und was den Wert zuverlässig unter 200 Millisekunden bringt.
Was INP misst – und was nicht
INP, kurz für Interaction to Next Paint, misst, wie lange eine Seite braucht, bis sie nach einer Eingabe sichtbar reagiert. Gemessen wird die Zeit vom Klick, vom Tippen auf einen Touchscreen oder vom Tastendruck bis zu dem Moment, in dem der Browser das nächste Bild auf den Bildschirm bringt. Scrollen, Überfahren mit der Maus und Zoomen zählen nicht mit.
Anders als ein einzelner Messwert beim Laden beobachtet INP den gesamten Besuch. Am Ende steht im Kern die langsamste Interaktion, die ein Besucher erlebt hat. Damit ein einzelner Ausreißer auf sehr interaktiven Seiten nicht alles verzerrt, ignoriert die Berechnung laut Google je 50 Interaktionen die eine mit der höchsten Latenz.
Daraus folgt der wichtigste Unterschied zur Ladezeit: Eine Seite kann blitzschnell erscheinen und trotzdem einen schlechten INP-Wert haben. Wer das Menü öffnet, einen Filter setzt oder den Cookie-Banner wegklickt und eine halbe Sekunde auf eine Reaktion wartet, erlebt genau das Problem, das INP sichtbar macht.
Ab wann INP schlecht ist: die 200- und 500-Millisekunden-Grenze
Ein INP von 200 Millisekunden oder weniger gilt als gut, über 500 Millisekunden als schlecht, dazwischen liegt „Optimierung erforderlich". Maßgeblich ist nicht der Durchschnitt, sondern das 75. Perzentil der echten Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Drei von vier Besuchen müssen also unter der Grenze bleiben.
INP hat am 12. März 2024 den Vorgänger First Input Delay (FID) als Core Web Vital abgelöst. FID hat nur die erste Interaktion betrachtet und davon nur die Wartezeit, bevor der Browser überhaupt mit der Verarbeitung begann. INP misst alle Interaktionen und die komplette Strecke bis zur sichtbaren Reaktion – deshalb sind viele Seiten, die bei FID grün waren, mit INP plötzlich gelb oder rot.
Für die Praxis heißt das: Ein Zielwert von knapp unter 200 Millisekunden ist zu knapp. Weil das schwächste Viertel der Aufrufe den Ausschlag gibt, lohnt sich Luft nach unten – auf einem älteren Smartphone dauert dieselbe Arbeit spürbar länger als auf dem Entwicklungsrechner, an dem die Seite getestet wurde.
INP-Wert in der Search Console: warum er anders aussieht als im Labor
Der INP-Wert in der Search Console stammt aus echten Chrome-Nutzern und wird über 28 Tage gesammelt. Der Core-Web-Vitals-Bericht greift dafür auf den Chrome User Experience Report (CrUX) zurück und fasst ähnliche Seiten zu URL-Gruppen zusammen, weil Google annimmt, dass sie dasselbe Gerüst und damit dieselben Ursachen teilen. Hat eine Seite zu wenig Besucher, erscheint statt eines Wertes „Keine Daten verfügbar".
Ein gewöhnlicher Lighthouse-Lauf kann INP dagegen gar nicht messen: Er lädt die Seite, klickt aber nichts an. Ohne Interaktion gibt es keinen INP. Als Annäherung im Labor dient die Total Blocking Time, die zeigt, wie lange der Hauptthread beim Laden blockiert ist. Deshalb ist die häufigste Rückfrage – „Lighthouse ist grün, die Search Console rot" – kein Widerspruch, sondern der Unterschied zwischen Laborsimulation und echten Besuchern.
Auch die Verzögerung gehört zur Einordnung: Weil die Felddaten 28 Tage umfassen, zeigt der Bericht eine Verbesserung erst nach Wochen. Wer nach einer Änderung „Fehlerbehebung prüfen" startet, wartet ebenfalls 28 Tage, bis die Search Console das Ergebnis bestätigt. Für die eigene Kontrolle taugt deshalb eine eigene Messung im Browser mehr als das tägliche Nachsehen im Bericht.
INP-Ursachen finden: die drei Phasen einer Interaktion
Jede langsame Interaktion lässt sich in drei Phasen zerlegen, und die Ursache steckt fast immer in genau einer davon. Die Eingabeverzögerung ist die Zeit, bis der Browser überhaupt mit der Verarbeitung beginnt. Die Verarbeitungsdauer ist die Zeit, die die eigenen Event-Handler laufen. Die Darstellungsverzögerung ist die Zeit danach, bis das neue Bild berechnet und gezeichnet ist.
Welche Phase das Problem ist, zeigt die frei verfügbare JavaScript-Bibliothek web-vitals von Google in ihrem Attribution-Build. Er liefert zu jedem gemessenen INP-Wert das Element, mit dem interagiert wurde, die Dauer jeder der drei Phasen und das längste beteiligte Skript. Diese Daten lassen sich an das eigene Analysewerkzeug schicken – dann sieht man nicht nur, dass der Wert schlecht ist, sondern auf welcher Schaltfläche und warum.
Die Grundlage dafür ist die Long Animation Frames API, die Chrome seit Version 123 allgemein bereitstellt. Sie meldet jedes Bild, dessen Berechnung länger als 50 Millisekunden dauert, und nennt dazu das verursachende Skript samt Datei und Funktion. Im Labor ergänzt das Performance-Panel der Chrome-Entwicklerwerkzeuge: Interaktion aufzeichnen, die lange Aufgabe suchen, Verursacher ablesen.
Die typischen Ursachen für schlechte INP-Werte
Die häufigste Ursache für eine lange Eingabeverzögerung ist Fremdcode, der den Hauptthread belegt, während der Besucher klickt. Tag-Manager mit vielen Tags, Analyse- und Werbeskripte, Chat-Widgets und Consent-Werkzeuge laufen alle auf demselben Hauptthread wie die eigene Seite. Google nennt außerdem wiederkehrende Timer per setInterval ausdrücklich als Störquelle, weil sie mit hoher Wahrscheinlichkeit genau in eine Interaktion fallen.
Bei Single-Page-Anwendungen mit Vue, React oder ähnlichen Frameworks kommt die Startphase hinzu. Solange das Framework sein JavaScript auswertet und die serverseitig gelieferte Seite „hydriert", also mit Interaktivität versieht, ist der Hauptthread beschäftigt. Wer in diesen ersten Sekunden klickt, wartet. Je größer das Paket, desto länger dieses Fenster.
Die Darstellungsverzögerung wächst mit der Größe der Seite selbst. Ein sehr großer DOM-Baum, wie ihn viele Page-Builder erzeugen, macht jede Neuberechnung von Stil und Layout teurer. Dazu kommt Layout-Thrashing: Code, der abwechselnd Maße ausliest und Stile setzt, zwingt den Browser zu mehrfachen Layoutberechnungen in einem einzigen Durchlauf.
Was INP zuverlässig unter 200 ms bringt
Der wirksamste Hebel ist, lange Aufgaben zu zerteilen und dem Browser zwischendurch Gelegenheit zum Zeichnen zu geben. Dafür gibt es seit Chrome 129 und Firefox 142 die Funktion scheduler.yield(): Sie unterbricht eine Aufgabe und setzt sie danach bevorzugt fort, ohne hinter andere wartende Aufgaben zu rutschen. Für Browser ohne Unterstützung bleibt setTimeout als Ausweichweg, mit etwas schlechterer Priorität.
Event-Handler sollten nur das tun, was für die sichtbare Reaktion nötig ist. Alles andere – Speichern, Zählen, Tracking, Rechtschreibprüfung – gehört hinter das nächste Bild verschoben. Häufig ausgelöste Ereignisse wie Tastatureingaben in einem Suchfeld werden entprellt, überholte Netzwerkanfragen per AbortController abgebrochen, und Animationen laufen über CSS statt über JavaScript.
Für die Darstellungsverzögerung hilft vor allem weniger Seite: ein flacherer DOM-Baum, keine versteckten Riesenmenüs mit Hunderten Einträgen und die CSS-Eigenschaft content-visibility, mit der der Browser Bereiche außerhalb des sichtbaren Ausschnitts erst rendert, wenn sie gebraucht werden. Beim Fremdcode bleibt nur die Inventur: Jedes Skript braucht einen Zweck und einen Eigentümer, sonst fliegt es raus.
INP bei WordPress verbessern: wo es dort meistens hakt
Bei WordPress-Seiten liegt die Ursache eines schlechten INP-Werts selten im Kern, sondern in der Summe der Erweiterungen. Jedes Plugin darf eigene Skripte und Stile laden, oft auf jeder Seite, auch dort, wo es gar nicht gebraucht wird. Page-Builder erzeugen zusätzlich tief verschachtelte Strukturen, die den DOM-Baum aufblähen und jede Layoutberechnung verteuern.
Der Weg zu einem besseren Wert beginnt deshalb mit einer Bestandsaufnahme: Welche Plugins laden auf welcher Seite welche Skripte, und welche davon laufen beim Klick? Ein Slider, ein Kontaktformular und ein Chat-Widget, die auf jeder Unterseite geladen werden, obwohl sie nur auf einer stehen, sind ein typischer Befund. Ebenso Tag-Manager-Container, in denen sich über Jahre Tags angesammelt haben, deren Kampagnen längst beendet sind.
Optimierungs-Plugins, die Skripte verzögert laden, verschieben das Problem oft nur: Das Skript lädt später, läuft aber trotzdem – im ungünstigsten Fall genau dann, wenn der Besucher den ersten Klick macht. Wer dauerhaft gute Werte will, entfernt Code, statt ihn umzuplanen.
Was ein guter INP-Wert nicht leistet
Ein guter INP-Wert ist kein Rankinghebel, der schwache Inhalte nach oben bringt. Google schreibt in seiner Dokumentation zum Seitenerlebnis, die Suche zeige immer die relevantesten Inhalte, auch wenn das Seitenerlebnis unterdurchschnittlich sei. Gute Werte im Core-Web-Vitals-Bericht garantieren laut Google ausdrücklich keine Spitzenplätze.
Die Werte fließen in die Rankingsysteme ein; nach der verbreiteten Einordnung wirken sie aber am ehesten dort, wo mehrere Seiten inhaltlich gleichauf liegen. Wer eine Seite mit schlechtem INP und gutem Inhalt hat, verliert dadurch selten Sichtbarkeit; wer eine inhaltlich schwache Seite reaktionsschnell macht, hat danach eine schnelle schwache Seite.
Der eigentliche Grund, INP zu verbessern, liegt beim Besucher: Eine Schaltfläche, die eine halbe Sekunde nicht reagiert, wird ein zweites Mal geklickt, ein Formular doppelt abgeschickt, ein Kauf abgebrochen. Deshalb gehört die Reihenfolge so: zuerst die Interaktionen reparieren, die Geld oder Anfragen kosten – Menü, Formular, Warenkorb –, danach den Rest.