INP verbessern: Wenn Ihre Website träge auf Klicks reagiert
Ihren INP-Wert verbessern Sie, indem Sie den Browser nach jedem Klick schneller zum Zeichnen kommen lassen: lange JavaScript-Aufgaben aufteilen, Drittanbieter-Skripte zähmen und nach einer Eingabe nur das neu darstellen, was sich wirklich ändert. Gut ist ein Wert bis 200 Millisekunden, gemessen an echten Besuchern.
Maßgeblich für INP sind die Daten echter Besucher, und dort zeigt der Wert die langsamste Reaktion eines Seitenaufrufs. Im Labor können Sie eine gemeldete Interaktion nachstellen und ihre Ursache suchen, die Bewertung durch Google kommt aber aus dem Feld. Für Shops, Buchungsstrecken und Formulare ist das die Kennzahl, die am direktesten mit Abbrüchen zusammenhängt: Wer nach einem Klick auf „Weiter“ eine halbe Sekunde lang keine Reaktion sieht, klickt ein zweites Mal oder geht.
Grundlagen
Was INP misst und warum es FID ersetzt hat
Interaction to Next Paint, kurz INP, misst die Zeit von einer Eingabe bis zum nächsten sichtbaren Bild auf dem Bildschirm. Gezählt werden Klicks, Tipp-Gesten und Tastatureingaben während des gesamten Besuchs, nicht nur die erste. Am Ende steht ein Wert pro Seitenaufruf, der ungefähr der langsamsten Interaktion entspricht; bei sehr vielen Interaktionen lässt Chrome einzelne Ausreißer weg.
Seit dem 12. März 2024 gehört INP zu den drei Core Web Vitals und hat First Input Delay (FID) abgelöst. FID hat nur die Wartezeit vor der ersten Eingabe gemessen. Was danach passierte, also wie lange das Skript rechnete und wann die Seite sich sichtbar änderte, blieb unsichtbar. Viele Websites hatten deshalb gute FID-Werte und fühlten sich trotzdem zäh an.
Die Schwellen von Google:
Gut: bis 200 Millisekunden
Verbesserungswürdig: über 200 bis 500 Millisekunden
Schlecht: über 500 Millisekunden
Bewertet wird das 75. Perzentil aller Seitenaufrufe. Drei von vier Besuchen müssen also unter 200 Millisekunden bleiben, damit eine Seite als gut gilt.
Jede Interaktion besteht aus drei Teilen, und jeder Teil hat andere Ursachen:
Eingabeverzögerung: Der Browser ist noch mit anderem beschäftigt und kann den Klick nicht annehmen.
Verarbeitung: Ihre Event-Handler laufen, zum Beispiel ein Filter, der eine Produktliste neu berechnet.
Darstellungsverzögerung: Der Browser berechnet Layout und zeichnet. Je größer und verschachtelter die Seite, desto länger dauert das.
Messen
Felddaten und Labordaten richtig lesen
Für INP zählen Felddaten, also Messungen bei echten Besuchern. Ein Lighthouse-Test im Standardmodus lädt nur die Seite und klickt nichts an. Er zeigt deshalb keinen INP-Wert, sondern die Total Blocking Time, die als Hinweis auf lange Aufgaben taugt. Erst im Zeitspannen-Modus von Lighthouse, in dem Sie selbst klicken, erscheint ein INP-Wert für genau diese Klicks.
Die wichtigsten Quellen für Felddaten:
Google Search Console, Bericht Core Web Vitals: gruppiert ähnliche URLs und zeigt, welche Seitengruppen schlecht abschneiden. Gut für den Überblick, schwach für die Ursachensuche.
PageSpeed Insights: zeigt oben die Felddaten aus dem Chrome UX Report (CrUX) für eine URL oder die ganze Domain, unten den Labortest. Beides wird oft verwechselt.
Eigene Messung mit der Bibliothek web-vitals: liefert pro Interaktion auch das Element, das angeklickt wurde, und die Aufteilung in die drei Phasen. Erst damit wissen Sie, welcher Button das Problem ist.
Zwei Eigenheiten führen regelmäßig zu Fehlschlüssen. Erstens sind die CrUX-Daten ein gleitender Durchschnitt über 28 Tage. Eine Verbesserung, die Sie am Montag ausliefern, ist erst nach rund vier Wochen vollständig sichtbar. Zweitens braucht CrUX genug Besucher mit Chrome. Kleinere Seiten haben oft gar keine URL-Daten, nur einen Wert für die gesamte Domain. In beiden Fällen hilft nur die eigene Messung weiter.
Für die Ursachensuche stellen Sie eine gemeldete Interaktion mit den Chrome DevTools nach. Der Bereich Performance zeigt jede Interaktion mit ihren drei Phasen. Diese Werte gelten für Ihren Rechner und Ihren Klick, nicht für das 75. Perzentil Ihrer Besucher. Drosseln Sie dabei die CPU um den Faktor 4 oder 6: Ein aktueller Entwicklerrechner ist deutlich schneller als das Mittelklasse-Smartphone, auf dem ein Großteil Ihrer Besucher unterwegs ist.
Ursachen
Typische Ursachen: lange Skripte und Drittanbieter
Fast jeder schlechte INP-Wert lässt sich auf lange Aufgaben im Hauptthread zurückführen. Der Browser führt JavaScript, Layout und Zeichnen in einem einzigen Thread aus. Jede Aufgabe über 50 Millisekunden gilt als lang, und solange sie läuft, wartet jeder Klick.
Häufige Verursacher:
Tag-Manager mit vielen Tags: Jedes Tracking-Pixel, jeder Remarketing-Tag hängt sich an Klicks. Ein Container mit 20 oder 30 Tags, von denen die Hälfte niemand mehr auswertet, ist keine Seltenheit.
Consent-Banner und Chat-Widgets: Sie laden oft große Skripte und reagieren selbst auf jeden Klick auf der Seite, auch wenn sie nicht sichtbar sind.
Filter und Sortierungen ohne Begrenzung: Ein Shop-Filter, der bei jedem Häkchen 1.500 Produktkarten verwirft und neu aufbaut, verursacht eine lange Verarbeitung und eine lange Darstellung zugleich.
Sehr große Seiten: Mega-Menüs, die auf jeder Seite tausende versteckte Elemente mitbringen, verlängern jede Layout-Berechnung.
Event-Handler, die alles synchron erledigen: Ein Klick auf „In den Warenkorb“ aktualisiert Zähler, schreibt Tracking, rechnet Versandkosten und animiert ein Symbol, alles in derselben Aufgabe.
So finden Sie den Verursacher
Der schnellste Weg führt über die Aufteilung in die drei Phasen. Ist die Eingabeverzögerung lang, blockiert etwas anderes den Hauptthread zum Zeitpunkt des Klicks, oft ein Skript, das gerade nachlädt. Ist die Verarbeitung lang, liegt das Problem im Handler des angeklickten Elements. Ist die Darstellungsverzögerung lang, ist die Seite zu groß oder der Klick ändert zu viel auf einmal.
Ein konstruiertes Beispiel zur Veranschaulichung: Ein Klick auf einen Akkordeon-Reiter dauert 380 Millisekunden, davon entfallen 300 auf ein Analyse-Skript, das sich an alle Klicks der Seite hängt und bei jedem Klick die gesamte Seite nach Formularfeldern durchsucht. Der eigene Code des Akkordeons braucht 15 Millisekunden. Ohne die Aufteilung hätte man das Akkordeon umgebaut und nichts gewonnen.
Prüfen Sie deshalb immer zuerst, welche Skripte im Flammendiagramm unter dem Klick stehen und von welcher Domain sie geladen wurden.
Maßnahmen
Was zuerst hilft, nach Aufwand sortiert
Fangen Sie bei den Maßnahmen an, die wenig kosten und an vielen Seiten zugleich wirken. Die Zeitangaben sind grobe Größenordnungen und hängen stark vom Zustand des Codes ab. Wenn Sie die Ursachen nicht selbst suchen wollen: Im Performance-Audit-Sprint messen wir INP gemeinsam mit Ladezeit und Backend, weil die Ursachen oft in allen drei Bereichen liegen.
Stunden: aufräumen
Tag-Manager durchgehen und Tags entfernen, die niemand mehr nutzt.
Chat-Widgets und ähnliche Dienste erst laden, wenn jemand sie öffnet, statt beim Seitenaufruf.
Doppelte Bibliotheken finden, etwa zwei Slider oder zwei Versionen von jQuery aus verschiedenen Plugins.
Tage: eigene Skripte entlasten
Lange Handler aufteilen: Zuerst das sichtbare Ergebnis zeigen (Button-Zustand, Zähler), dann Tracking und Nebenarbeiten in einer neuen Aufgabe nachziehen. Dafür gibt es scheduler.yield() in Chrome und Edge ab Version 129 und in Firefox ab Version 142, mit setTimeout als Rückfall für Safari.
Eingaben in Suchfeldern entprellen, damit nicht jeder Tastendruck eine Berechnung auslöst.
Unsichtbare Bereiche mit der CSS-Eigenschaft content-visibility vom Rendern ausnehmen.
Wochen: Struktur ändern
Lange Listen virtualisieren oder serverseitig filtern und paginieren.
Die Größe der Seite deutlich reduzieren, etwa durch ein Menü, das Unterebenen erst bei Bedarf lädt.
Rechenintensive Arbeit in einen Web Worker auslagern, der neben dem Hauptthread läuft.
Messen Sie nach jeder Stufe neu, bevor Sie die nächste angehen. Oft reicht die erste Stufe, um unter 200 Millisekunden zu kommen. Warum Messwerte allein noch keine Rankings machen, beschreiben wir im Beitrag SEO ohne Buzzword-Bingo.
Kurz beantwortet
Häufige Fragen
-
Bis 200 Millisekunden gilt INP als gut, über 500 Millisekunden als schlecht. Maßgeblich ist das 75. Perzentil der Seitenaufrufe echter Besucher, nicht ein einzelner Test. Ein guter Laborwert in Lighthouse sagt über INP wenig aus, weil dort niemand klickt.
-
Google nutzt die Core Web Vitals als einen Faktor unter vielen in den Systemen, die Seiten bewerten. Relevanz des Inhalts wiegt deutlich schwerer. Ein schlechter INP-Wert kostet also selten allein Positionen, er kostet aber Nutzer, die auf eine träge Seite nicht warten.
-
Die Werte stammen aus dem Chrome UX Report und erscheinen nur bei ausreichend vielen Chrome-Besuchern. Bei wenig Verkehr fehlen Werte für einzelne URLs oder ganz. Dann hilft eine eigene Messung mit der Bibliothek web-vitals.
Träge Klicks finden lassen
Im Performance-Audit-Sprint messen wir Core Web Vitals und Backend gemeinsam und liefern eine nach Aufwand sortierte Liste der Ursachen.
Nachweise
Quellen und Stand
Stand: 15.06.2026. Schwellenwerte, Messmethode und Ablösung von FID laut web.dev und Google Search Central, Browser-Unterstützung von scheduler.yield() laut MDN.
Artikel teilen