Ein guter INP-Wert liegt bei 200 Millisekunden oder weniger, gemessen am 75. Perzentil echter Besuche. Zwischen 200 und 500 ms gilt die Seite als “verbesserungswürdig”, über 500 ms als schlecht. Google wendet diese Grenzwerte getrennt für Mobilgeräte und Desktop an, eine Seite kann also auf einem Gerätetyp bestehen und auf dem anderen durchfallen.
Interaction to Next Paint (INP) misst, wie schnell eine Seite sichtbar reagiert, nachdem jemand klickt, tippt oder eine Taste drückt. INP wurde am 12. März 2024 zu einem Core Web Vital und löste First Input Delay (FID) ab, das nur die Verzögerung bis zur Verarbeitung der ersten Interaktion gemessen hat. INP betrachtet die Interaktionen während des gesamten Besuchs und meldet eine der langsamsten.
In der Praxis bedeutet “gut” drei Dinge: Mindestens 75 % der echten Besuche erhalten innerhalb von 200 ms eine Reaktion, Sie messen mit Felddaten statt mit einem einzelnen Labortest, und Sie haben etwas Puffer unter der Grenze, damit ein neues Skript oder eine umsatzstarke Aktionswoche Sie nicht darüber drückt.
Dieser Leitfaden erklärt, wie der Wert berechnet wird, wo Sie Ihren finden, warum manche Tools nichts anzeigen und wie Sie einen langsamen INP diagnostizieren und beheben, ohne zu raten.
Welche Grenzwerte gelten für INP?
Google nutzt drei Bereiche, und die Grenzwerte sind entscheidend. Die Tabelle folgt der INP-Dokumentation von web.dev und dem Core-Web-Vitals-Bericht der Search Console.
| Bewertung | INP-Wert | Was es für Nutzer bedeutet |
|---|---|---|
| Gut | 200 ms oder weniger | Klicks und Tippen fühlen sich bei den meisten Besuchen sofort an |
| Verbesserungswürdig | Über 200 ms bis 500 ms | Spürbare Verzögerung bei Menüs, Filtern, Formularen oder “In den Warenkorb” |
| Schlecht | Über 500 ms | Nutzer klicken mehrfach, halten die Seite für defekt oder verlassen sie |
Sind genau 200 ms gut? Ja. web.dev definiert “gut” als “kleiner oder gleich” 200 ms, 200 besteht also, 201 nicht. Dieselbe Logik gilt bei 500 ms: Genau 500 gilt noch als verbesserungswürdig, alles darüber als schlecht.
Zum Vergleich: Die beiden anderen Core Web Vitals in der Search Console nutzen für LCP Grenzwerte von 2,5 s und 4 s und für CLS von 0,1 und 0,25. INP ist als einziger Wert in Millisekunden Reaktionszeit gemessen und nicht in Ladezeit oder visueller Stabilität.
Wie wird Ihr INP-Wert tatsächlich berechnet?
INP wird zuerst pro Besuch berechnet und dann über alle Besuche am 75. Perzentil zusammengefasst. Wer beide Schritte versteht, klärt die meisten Missverständnisse rund um diese Zahl.
Während eines Besuchs misst der Browser jeden Klick, jedes Tippen und jeden Tastendruck. Jede Interaktion besteht aus drei Teilen:
- Eingabeverzögerung: die Wartezeit, bevor Ihre Event-Handler starten, meist weil der Main Thread mit anderer Arbeit beschäftigt ist.
- Verarbeitungsdauer: die Zeit, die Ihre Event-Handler zur Ausführung brauchen.
- Darstellungsverzögerung: die Zeit vom Ende der Handler, bis der Browser den nächsten Frame zeichnet.
Der INP eines Besuchs ist die längste dieser Interaktionen, mit einer Ausnahme für interaktionsreiche Seiten: Laut web.dev wird pro 50 Interaktionen jeweils die höchste ignoriert, damit ein einzelner Ausreißer in einer langen Sitzung nicht den Wert bestimmt. Hovern, Scrollen und Zoomen zählen nicht als Interaktionen.
Anschließend werden die Werte aller Besuche zusammengeführt, und das 75. Perzentil wird gemeldet. Das ist die “75-%-Regel”: Ihre Seite ist gut, wenn mindestens drei von vier Besuchen einen INP von 200 ms oder weniger hatten. Das restliche Viertel darf langsamer sein, ohne dass die Seite durchfällt. Deshalb ist es wichtiger, Ihre typische langsamste Interaktion zu beheben, als einem seltenen Sonderfall nachzujagen.
Ein Besuch, bei dem der Nutzer nie klickt, tippt oder schreibt, erzeugt überhaupt keinen INP-Wert. Seiten, die vor allem gelesen werden, etwa lange Artikel, haben oft weniger INP-Daten als Seiten, die bedient werden, etwa Kategoriefilter oder der Checkout.
Ist ein guter INP-Wert auf Mobilgeräten und Desktop unterschiedlich?
Der Grenzwert ist derselbe, 200 ms, aber die Ergebnisse unterscheiden sich stark. Smartphones haben langsamere Prozessoren, daher braucht derselbe JavaScript-Code länger, und Google meldet Mobil und Desktop sowohl in PageSpeed Insights als auch in der Search Console getrennt.
Das Performance-Kapitel des Web Almanac 2024 von HTTP Archive ergab, dass 74 % der mobilen Websites und 97 % der Desktop-Websites einen guten INP hatten. INP ist also vor allem ein mobiles Problem. Ist Ihr Desktop-Bericht grün und Ihr mobiler Bericht gelb, ist das das übliche Muster und kein Messfehler.
Priorisieren Sie den Gerätetyp, der Ihnen Traffic und Umsatz bringt. Bei den meisten Consumer-Websites ist das Mobil, was auch bedeutet, auf einem Android-Smartphone der Mittelklasse oder mit CPU-Drosselung in den Chrome DevTools zu testen, nicht auf einem schnellen Laptop. Unser Leitfaden zu Mobile SEO behandelt das größere Bild.
Wo können Sie Ihren INP-Wert prüfen?
Nutzen Sie Felddaten, um zu wissen, ob Sie bestehen, und Labortools, um herauszufinden, warum nicht. Jedes Tool beantwortet eine andere Frage.
| Tool | Datentyp | Am besten geeignet für |
|---|---|---|
| Search Console, Bericht “Core Web Vitals” | Feld (CrUX), gruppierte URLs | Erkennen, welche Seitengruppen auf Mobil oder Desktop durchfallen, und Korrekturen validieren |
| PageSpeed Insights | Feld (CrUX, letzte 28 Tage) plus Lighthouse-Labortest | Schnelle Prüfung einer URL oder des gesamten Origins |
| CrUX API, BigQuery oder CrUX Vis | Feld (CrUX) | Entwicklung über die Zeit und Vergleiche mit Wettbewerbern |
| Real User Monitoring (RUM), zum Beispiel die JavaScript-Bibliothek web-vitals | Feld, Ihre eigenen Besucher | Herausfinden, welches Element und welche Interaktion einen langsamen INP verursacht hat |
| Performance-Panel der Chrome DevTools | Labor | Eine Interaktion aufzeichnen und sehen, welche Aufgabe sie blockiert hat |
| Lighthouse (Navigationsmodus) | Labor | Total Blocking Time als grobe Näherung; misst INP bei einem Seitenladetest nicht |
Googles eigene Dokumentation ist bei der Rangfolge eindeutig: Felddaten echter Nutzer sind der beste Weg, INP zu messen. Total Blocking Time kann auf Probleme hinweisen, wird von web.dev aber als brauchbare Näherung beschrieben, “kein Ersatz für INP”. Ein perfekter Lighthouse-Wert bedeutet nicht, dass Sie bei INP bestehen.
Warum zeigt PageSpeed Insights für manche Seiten keinen INP-Wert?
Meist, weil es für diese URL nicht genug Daten echter Nutzer gibt. PageSpeed Insights bezieht Felddaten aus dem Chrome UX Report (CrUX), der nur Seiten enthält, die öffentlich auffindbar sind und genug Besucher haben. Google veröffentlicht den genauen Traffic-Schwellenwert nicht.
Fehlen für eine einzelne URL Daten, greift PageSpeed Insights auf Daten auf Origin-Ebene zurück, also auf Ihre gesamte Domain. Fehlen auch dort Daten, zeigt der Feldbereich “Keine Daten”, und nur die Lighthouse-Laborergebnisse bleiben. Weitere häufige Gründe:
- Die Seite ist neu und hat noch keine 28 Tage an Besuchen gesammelt
- Die Seite liegt hinter einem Login oder ist von der Indexierung ausgeschlossen, daher nimmt CrUX sie nicht auf
- Besucher interagieren selten mit der Seite, daher gibt es trotz guten Traffics wenige INP-Messungen
Die praktische Lösung ist ein eigenes RUM. Die Funktion onINP der Bibliothek web-vitals meldet INP für jeden Besuch, und ihr Attribution-Build zeigt, welches Element beteiligt war und wie lange jede der drei Phasen gedauert hat. So erhalten Sie Daten für Seiten mit wenig Traffic und, noch wichtiger, den Kontext für das Debugging.
Wie finden Sie heraus, was INP langsam macht?
Diagnostizieren Sie zuerst die Phase, dann die Ursache. Jede Phase deutet auf eine andere Art von Lösung hin.
| Langsame Phase | Typische Ursache | Wo Sie suchen sollten |
|---|---|---|
| Eingabeverzögerung | Main Thread mit anderen Skripten beschäftigt: Tag Manager, Chat-Widgets, A/B-Tests, aufwändige Hydration beim Laden | Long Tasks in den DevTools rund um den Moment des Klicks |
| Verarbeitungsdauer | Event-Handler macht zu viel: Filtern einer großen Produktliste, Analytics-Aufrufe, synchroner Speicherzugriff, Neu-Rendern ganzer Komponenten | Der Click- oder Keydown-Handler im Performance-Panel |
| Darstellungsverzögerung | Großes DOM, aufwändige Neuberechnung von Styles und Layout, Rendern großer HTML-Blöcke per JavaScript | Einträge “Recalculate Style” und “Layout” nach dem Handler |
Ein einfacher Ablauf:
- Suchen Sie in der Search Console die URL-Gruppen mit “INP-Problem” auf Mobilgeräten.
- Öffnen Sie eine Beispiel-URL und identifizieren Sie die Interaktionen, die Nutzer tatsächlich ausführen: das Menü, einen Filter, die Größenauswahl, “In den Warenkorb”, ein Formularfeld.
- Aktivieren Sie in den Chrome DevTools die CPU-Drosselung, starten Sie eine Performance-Aufzeichnung, führen Sie die Interaktion aus und stoppen Sie.
- Suchen Sie nach Long Tasks, die web.dev als Aufgaben über 50 ms definiert, und notieren Sie, aus welchem Skript sie stammen.
- Wiederholen Sie die Interaktion, während die Seite noch lädt. Dann ist der Main Thread oft am stärksten ausgelastet, und genau dann klicken echte Nutzer.
Wie verbessern Sie einen schlechten INP-Wert?
Verrichten Sie im Moment der Interaktion weniger Arbeit auf dem Main Thread und geben Sie dem Browser die Chance, früher zu zeichnen. Die folgenden Maßnahmen sind grob vom einfachsten zum technischsten sortiert.
Prüfen Sie zuerst Skripte von Drittanbietern
Auf vielen Marketing-Websites verursacht nicht Ihr eigener Code die größten INP-Kosten. Chat-Widgets, Heatmaps, Consent-Tools, Bewertungs-Widgets und mehrere Analytics-Tags konkurrieren alle um den Main Thread. Listen Sie jedes Skript in Ihrem Tag Manager auf, entfernen Sie, was niemand nutzt, und verzögern Sie nicht notwendige Tags bis nach dem Laden der Seite oder bis nach der ersten Interaktion.
Erst Feedback zeigen, dann den Rest erledigen
Aktualisieren Sie die Oberfläche sofort (Menü öffnen, Ladeanzeige zeigen, Button als gedrückt markieren) und führen Sie die langsamere Arbeit dann in einer separaten Aufgabe aus. Das nennt man Yielding an den Main Thread. Ein kleiner Helfer wie der folgende nutzt scheduler.yield(), wo der Browser es unterstützt, und greift sonst auf setTimeout zurück:
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise(resolve => setTimeout(resolve, 0));
}
button.addEventListener('click', async () => {
showFilterResultsLoading(); // visible update first
await yieldToMain(); // let the browser paint
applyFilters(); // heavier work afterwards
sendAnalyticsEvent();
});Laut web.dev wird scheduler.yield() in Chrome und Edge ab Version 129 und in Firefox ab Version 142 unterstützt, nicht aber in Safari. Deshalb ist der Fallback wichtig.
Lange Aufgaben aufteilen
Jede Aufgabe über 50 ms blockiert Eingaben. Teilen Sie lange Schleifen, etwa die Verarbeitung Hunderter Produkte, in Abschnitte mit einem Yield dazwischen auf. Bitten Sie Ihren Entwickler, die Hydration in JavaScript-Frameworks zu prüfen, die beim Laden oft als eine große Aufgabe läuft.
Das DOM schlank halten
Jedes zusätzliche Element verlangsamt die Neuberechnung von Styles und Layout. Paginieren oder virtualisieren Sie lange Listen, entfernen Sie versteckte doppelte Menüs für Mobil und Desktop und nutzen Sie die CSS-Eigenschaft content-visibility, um das Rendern von Bereichen außerhalb des sichtbaren Bildschirms zu überspringen.
Layout Thrashing vermeiden
Wer direkt nach einer Style-Änderung einen Layout-Wert liest, etwa die Höhe eines Elements, zwingt den Browser, das Layout sofort zu berechnen. Bündeln Sie in Ihren Event-Handlern Lesezugriffe vor Schreibzugriffen.
Nach jeder Änderung erneut prüfen
Felddaten brauchen Zeit, um sich zu bewegen. CrUX in PageSpeed Insights umfasst die letzten 28 Tage, und die Validierung in der Search Console läuft über ein Beobachtungsfenster von 28 Tagen. Bestätigen Sie die Korrektur mit Ihrem eigenen RUM innerhalb weniger Tage und lassen Sie die Berichte von Google dann nachziehen.
Beeinflusst INP die SEO-Rankings?
INP ist Teil der Core Web Vitals, die laut Google mit dem übereinstimmen, was die zentralen Ranking-Systeme belohnen sollen, aber INP ist keine Abkürzung an die Spitze der Ergebnisse. Google “empfiehlt dringend” gute Core Web Vitals für den Erfolg in der Suche, während Relevanz und Qualität der Inhalte entscheidend bleiben.
Das stärkere Argument für die Optimierung von INP ist kommerziell. Langsame Filter, träge Warenkorb-Buttons und nicht reagierende Formulare kosten direkt Conversions, besonders auf Mobilgeräten. Betrachten Sie einen guten INP-Wert als Grundvoraussetzung für eine nutzbare Website und stecken Sie den Großteil Ihres SEO-Aufwands in Inhalte und Struktur. Unser Leitfaden zu E-Commerce-SEO zeigt, wo Performance unter den Prioritäten eines Shops steht.
Was sollten Sie anstreben?
Streben Sie auf Mobilgeräten einen INP am 75. Perzentil deutlich unter 200 ms an, nicht nur knapp darunter. Eine Seite mit 190 ms besteht heute, kann aber nach einem neuen Marketing-Tag oder einer Traffic-Spitze von langsameren Geräten durchfallen. Ein Puffer von einigen Dutzend Millisekunden gibt Ihrem Team Spielraum für neue Funktionen.
Legen Sie Ziele pro Template statt pro URL fest: Kategorieseiten, Produktseiten, Artikel, Formulare und Checkout. Beheben Sie zuerst das Template mit dem meisten Traffic und dem schlechtesten INP und machen Sie INP zum Teil der Release-Checkliste, damit neue Skripte geprüft werden, bevor sie live gehen.
Wo kommt Marketer Coffee ins Spiel?
Marketer Coffee ist eine Agentur für AI SEO und GEO; wir behandeln Performance als Teil von technischem SEO, neben Architektur, strukturierten Daten und Content. Ergebnisse aus anderen Branchen:
- Aldi.pl (Einzelhandel). Die organischen Klicks stiegen in 12 Monaten von 367.127 auf 852.724 pro Monat (+132 %), mit Produktinhalten, Product-Schema, einer schlankeren Architektur und einheitlichen Filialdaten. Zur Aldi-Fallstudie.
- IDG-Online (Videoüberwachung und Affiliate). Von 500 auf über 30.000 monatliche Klicks in 16 Monaten, im Wettbewerb mit Ceneo, MediaExpert und MediaMarkt, mit Ranking-Seiten, Q&A-Inhalten und Schema-Markup. Zur IDG-Online-Fallstudie.
Zu wem wir passen: Websites, bei denen Geschwindigkeit, Struktur und Content einen gemeinsamen Plan brauchen, oft Onlineshops oder internationale Websites. Zu wem wir nicht passen: Teams, die nur einen Performance-Engineer für eine einmalige Framework-Neuentwicklung brauchen; dafür sollten Sie einen spezialisierten Entwickler beauftragen. Um zu sehen, wie Ihre Website in der KI-Suche und bei Google abschneidet, starten Sie mit unserem kostenlosen KI-Sichtbarkeits-Audit.
Häufige Fragen zu INP-Werten
Was ist ein guter INP-Wert?
200 Millisekunden oder weniger am 75. Perzentil echter Seitenbesuche, getrennt gemessen für Mobilgeräte und Desktop. Über 200 ms bis 500 ms ist verbesserungswürdig, über 500 ms schlecht.
Wann hat INP FID abgelöst?
INP wurde am 12. März 2024 zu einem Core Web Vital und löste First Input Delay ab. Die Search Console hat FID an diesem Tag entfernt.
Warum ist mein INP auf dem Desktop gut, auf Mobilgeräten aber schlecht?
Smartphones haben langsamere Prozessoren, daher brauchen dieselben Skripte länger. Der Web Almanac 2024 fand einen guten INP bei 97 % der Desktop-Websites, aber nur bei 74 % der mobilen Websites.
Kann Lighthouse INP messen?
Ein normaler Lighthouse-Seitenladetest enthält keine Nutzerinteraktionen und kann daher keinen INP melden. Er zeigt Total Blocking Time, eine grobe Näherung. Nutzen Sie Felddaten aus CrUX oder Ihrem eigenen RUM, um INP zu beurteilen.
Wie lange dauert es, bis eine INP-Korrektur in der Search Console sichtbar wird?
Felddaten umfassen ein rollierendes Fenster von 28 Tagen, und die Validierung in der Search Console beobachtet 28 Tage lang. Rechnen Sie also mit etwa vier Wochen, bis die Berichte eine Korrektur vollständig zeigen. Ihr eigenes RUM kann sie früher bestätigen.
Was ist die Kurzfassung?
Ein guter INP liegt bei 200 ms oder weniger für mindestens 75 % der echten Besuche, je Gerätetyp. Finden Sie durchfallende Templates in der Search Console, zeichnen Sie die langsamen Interaktionen in den DevTools auf, bestimmen Sie die langsame Phase und beheben Sie die Ursache: weniger Drittanbieter-Skripte, schnelleres Feedback, kürzere Aufgaben und ein kleineres DOM. Und lassen Sie sich einen Puffer.
Wenn Sie eine zweite Meinung dazu möchten, wo Performance unter Ihren SEO-Prioritäten steht: Kostenlose Beratung buchen.
Quellen: web.dev, “Interaction to Next Paint (INP)” (Grenzwerte, 75. Perzentil, Interaktionsphasen, Ausreißerregel, TBT als Näherung); web.dev, Blogbeitrag von Jeremy Wagner und Rick Viscomi zur Einführung von INP als Core Web Vital am 12. März 2024; web.dev, “Optimize Interaction to Next Paint” und “Optimize long tasks” (Long Tasks ab 50 ms, Unterstützung für scheduler.yield); Google Search Console Hilfe, Bericht “Core Web Vitals” (Grenzwerte, 28-tägige Validierung); Google Search Central, “Core Web Vitals und Google-Suchergebnisse”; Chrome for Developers, CrUX-Methodik und CrUX in PageSpeed Insights (Berechtigung, 28-Tage-Fenster, Rückgriff auf Origin-Daten); HTTP Archive, Web Almanac 2024, Kapitel Performance; Marketer Coffee, Fallstudien zu Aldi und IDG-Online (andere Branchen).
