INP (Interaction to Next Paint): Definition & Optimierung (2026)

von

INP (Interaction to Next Paint) ist eine Core-Web-Vitals-Metrik, die misst, wie schnell eine Seite nach Klicks, Taps und Tastendrücken das nächste Bild zeigt.[1] Der Wert entspricht im Kern der langsamsten Interaktion eines Besuchs, gemessen von der Eingabe bis zum nächsten gezeichneten Frame (dem einzelnen Bild, das der Browser anzeigt).[1] Für Google-Rankings gilt INP als Signal innerhalb der Core Web Vitals, die Belege dazu stehen unter Definition und Einordnung.

Definition und Einordnung

Was bedeutet INP genau?

INP steht für Interaction to Next Paint und ersetzte im März 2024 First Input Delay (FID) als Core Web Vital.[2] FID erfasste nur die Verzögerung vor der Verarbeitung der ersten Interaktion einer Seite. INP betrachtet alle Interaktionen, von der Eingabeverzögerung über die Event-Handler (Code, der auf eine Eingabe reagiert) bis zum nächsten gezeichneten Frame.[1] Google ordnet INP der Responsiveness einer Seite zu, also der Frage, wie zügig sie auf Nutzereingaben antwortet.[1]

Als Interaktion zählen ein Mausklick, ein Tippen auf dem Touchscreen und ein Tastendruck auf einer physischen oder virtuellen Tastatur.[1] Hovern, Zoomen und Scrollen fließen nicht ein.[1]

Die Latenz einer Interaktion besteht aus drei Phasen: dem Input Delay (Zeit, bis der erste Event-Handler startet), der Processing Duration (Laufzeit der Event-Handler) und dem Presentation Delay (Zeit vom Ende der Handler bis der nächste Frame erscheint).[3] Bei den meisten Seiten gilt die Interaktion mit der schlechtesten Latenz als INP. Hat eine Seite sehr viele Interaktionen, bleibt pro 50 Interaktionen die höchste unberücksichtigt. Danach wird das 75. Perzentil aller Seitenaufrufe gebildet, also der Wert, den 75 Prozent der Aufrufe erreichen oder unterschreiten.[1]

Woher ist der Faktor bekannt und wie sicher ist die Evidenz?

Die Grundlage ist Googles eigene Dokumentation. Dort steht, dass die Rankingsysteme Core Web Vitals nutzen und Google gute Werte empfiehlt.[4] INP ist eine der drei Metriken.[5] Damit ist das Signal für die Core Web Vitals insgesamt von Google bestätigt. Eine eigene Gewichtung für INP oder einen Grenzwert, ab dem das Ranking betroffen wäre, nennt Google in diesen Dokumenten nicht. Wie stark INP im Vergleich zu anderen Signalen wirkt, ist damit offen.

Wie wichtig ist INP?

Gewichtung und Ausgangslage

Google zeigt nach eigener Aussage immer die relevanteste Seite, auch wenn ihre Page Experience schwach ist.[4] Gibt es zu einer Suchanfrage viele hilfreiche Ergebnisse, kann eine gute Page Experience zum Erfolg beitragen.[4] Ob INP für deine Seite der richtige Hebel ist, hängt deshalb davon ab, wie viele gleichwertige Ergebnisse es zur Anfrage gibt und wo deine Messwerte aktuell liegen. Die Bewertung erfolgt in der Regel pro Seite, einzelne Bewertungen gelten site-weit.[4]

Für welche Seitentypen ist INP besonders relevant?

Der Unterschied liegt in der Zahl der Interaktionen. Seiten aus überwiegend Text und Bildern bieten kaum etwas zum Anklicken, bei Texteditoren oder Spielen können Hunderte oder Tausende Interaktionen zusammenkommen.[3] Ein hoher INP gefährdet in beiden Fällen die Nutzererfahrung.[3]

Einen Sonderfall bilden Single-Page-Applications (SPAs), die Inhalte per JavaScript nachladen und Routen wechseln, ohne die Seite neu zu laden. Für Nutzer wirken diese Wechsel wie neue Seitenaufrufe, Chrome und die zugrunde liegenden Web-Schnittstellen rechnen die gesamte Erfahrung aber dem ersten Seitenaufruf zu.[6]

Typische Missverständnisse

  • „INP misst die Ladezeit.“ Die Metrik betrachtet die gesamte Besuchsdauer. Laut Chrome-Nutzungsdaten verbringen Nutzer 90 Prozent ihrer Zeit auf einer Seite, nachdem sie geladen ist.[1]
  • „Es gibt ein Page-Experience-Signal, in das INP einfließt.“ Google verneint ein einzelnes Signal. Die Rankingsysteme betrachten verschiedene Signale, die zur Page Experience passen.[4]
  • „Gute Werte im Bericht bringen Top-Platzierungen.“ Gute Ergebnisse in der Search Console oder in Drittanbieter-Tools garantieren laut Google keine Spitzenplätze. Einen perfekten Score allein für SEO anzustreben, ist womöglich nicht der beste Einsatz deiner Zeit.[4]
  • „Der Search-Console-Bericht zeigt den INP jeder URL.“ Der Bericht ist für die Gesamtsicht auf die Seite gedacht und zeigt eine Auswahl indexierter URLs in Gruppen. Den Status einer bestimmten URL findest du dort nur schwer.[7]

Messung und Diagnose

Selbstaudit: Wo steht deine Seite?

Prüfpunkt Grün Gelb Rot Beleg
INP im Feld (75. Perzentil, mobil und Desktop getrennt) bis 200 ms über 200 bis 500 ms über 500 ms [1] [7]
Long Tasks bei Interaktionen (Aufgaben auf dem Hauptthread, dem Thread, auf dem fast alles JavaScript läuft, die länger als 50 ms dauern) keine Long Tasks bei Interaktionen Long Tasks nur bei einzelnen, seltenen Interaktionen Long Tasks bei häufigen Kerninteraktionen [8]
DOM-Größe (Anzahl der Knoten im Seitenaufbau) bis 800 Knoten über 800 bis 1.400 Knoten über 1.400 Knoten [9]
Verteilung der Zeit auf die drei Phasen einer langsamen Interaktion keine Phase dominiert eine Phase dominiert bei einzelnen Interaktionen eine Phase dominiert bei den Interaktionen, die den INP bestimmen [10]
Input Delay bei Interaktionen während des Ladens kein auffälliger Input Delay Input Delay nur bei sehr früher Interaktion Feldwerte zeigen hohen Input Delay durch Skript-Auswertung (Invoker-Typ classic-script oder module-script) [11]
Drittanbieter-Skripte in langsamen Interaktionen Attributionsdaten zeigen keine Drittanbieter-Skripte vereinzelt Drittanbieter-Skripte im Input Delay oder in der Verarbeitung Drittanbieter-Skripte verlängern regelmäßig Input Delay oder Verarbeitung [11] [10]
Layout Thrashing (erzwungenes synchrones Layout) in Event-Handlern keine markierten Layout- oder Style-Aufgaben im Profiler vereinzelt markierte Aufgaben Forced Reflows in den Handlern der INP-Interaktion [3] [10]

Tools und Datenquellen

Tool Bericht oder Kennzahl Wofür
PageSpeed Insights Felddaten aus dem CrUX (Chrome User Experience Report, gesammelte Nutzerdaten aus Chrome) für Domain, teils auch für die einzelne URL prüfen, ob ein INP-Problem besteht, die Ursache zeigt der Bericht nicht[11] [1]
Search Console Core-Web-Vitals-Bericht mit Status je URL-Gruppe (schlecht, verbesserungswürdig, gut) und Group INP Probleme über viele ähnliche Seiten finden[7]
web-vitals-Bibliothek (onINP), Attribution-Build ab Version 4 INP-Wert mit Zielelement, Interaktionstyp, den drei Phasen und Daten der Long Animation Frames API (LoAF, Details zu langen Frames und den verursachenden Skripten) Ursachen im Feld bei echten Nutzern finden[11]
Chrome DevTools, Performance-Panel Live-Metriken und Interactions-Track mit Aufschlüsselung der drei Phasen langsame Interaktionen reproduzieren und im Code eingrenzen[10]
Lighthouse Audit „Avoid an excessive DOM size“ DOM-Größe prüfen[9]

PageSpeed Insights und der Search-Console-Bericht beziehen ihre Felddaten aus dem CrUX. Eine Seite oder Domain taucht dort nur auf, wenn sie öffentlich auffindbar ist (HTTP-Status 200, kein noindex) und genügend Besucher hat. Die Mindestzahl nennt Google nicht.[6] Erfasst werden Chrome-Nutzer auf Desktop und Android, die Nutzungsstatistiken melden und ihren Verlauf synchronisieren. Chrome auf iOS, Android-WebView und andere Chromium-Browser wie Edge liefern keine Daten.[6]

Im Lab liefern Tools einen INP-Wert nur, wenn dort Interaktionen stattfinden. Ohne Felddaten kann die im Lighthouse gemessene Total Blocking Time (TBT, Blockierzeit auf dem Hauptthread während des Ladens) ein Anhaltspunkt sein. Sie korreliert gut mit INP, ersetzt ihn aber nicht.[1] [10] Auswertungen, die FID über die CrUX- oder PageSpeed-Insights-API beziehen, mussten bis zum 09.09.2024 auf INP umgestellt werden.[2]

Optimierung

Die wichtigsten Hebel

  1. Event-Handler auf das Nötige kürzen (Quick Win). Google rät, in Event-Handlern so wenig Arbeit wie möglich zu erledigen. Läuft dort nur, was das nächste Bild braucht, und wird der Rest auf einen späteren Zeitpunkt verschoben, sinkt die Verarbeitungszeit.[3] In React helfen Memoization und Transitions, unnötige Render-Arbeit zu überspringen beziehungsweise aufzuteilen.[10]
  2. Long Tasks aufbrechen (Quick Win). Ein Long Task blockiert Interaktionen, bis er fertig ist, deshalb sollst du dem Browser zwischendurch die Kontrolle überlassen (Yielding).[8] Mit scheduler.yield() läuft die Fortsetzung priorisiert weiter, sodass Aufgaben anderer Quellen, etwa von Drittanbieter-Skripten, die Reihenfolge nicht unterbrechen.[8] Die Funktion wird in Chrome und Edge ab Version 129 und in Firefox ab Version 142 unterstützt, in Safari nicht. Als Fallback dient setTimeout, verpackt in ein Promise, geprüft wird auf globalThis.scheduler?.yield.[8] Von isInputPending() rät Google inzwischen ab und empfiehlt, unabhängig von wartenden Eingaben zu yielden.[8]
  3. Input Delay beim Laden senken (Langfristig). Nach dem Download müssen Skripte geparst, kompiliert und ausgeführt werden, was Long Tasks erzeugen kann, die Interaktionen während des Ladens verzögern.[3] Du kannst Skripte in kleinere Bundles aufteilen, zunächst ungenutzten Code später laden und ungenutzten Code entfernen.[11] Nach dem Laden entsteht Input Delay durch zeitgesteuerte Callbacks wie setInterval, noch laufende Event-Handler oder Promise-Arbeit.[11]
  4. Layout Thrashing beseitigen (Quick Win). Layout Thrashing entsteht, wenn du Styles in JavaScript änderst und im selben Task wieder ausliest.[3] Der Browser muss dann Layoutarbeit synchron erledigen, die er sonst erst nach den Event-Handlern ausgeführt hätte.[3]
  5. DOM verkleinern und Rendering begrenzen (Langfristig). Der wichtigste Ansatz ist eine geringere DOM-Tiefe: verschachtelte Wrapper-Elemente zusammenlegen, in Frameworks Fragments nutzen und Flexbox oder Grid statt zusätzlicher Container einsetzen.[9] Bei zunächst unsichtbaren Bereichen kannst du Inhalte erst bei einer Interaktion nachladen (additiver Ansatz). Dann brauchst du einen Ladeindikator, weil Netzwerkanfragen nicht in den INP einfließen, die gefühlte Latenz aber erhöhen.[9] Mit content-visibility rendert der Browser Elemente außerhalb des Sichtbereichs erst bei Bedarf, und einfachere CSS-Selektoren senken den Aufwand bei Style-Berechnungen.[9] Auch requestAnimationFrame-Callbacks verlängern den Presentation Delay, wenn sie Arbeit erledigen, die die Oberfläche nicht aktualisiert.[11]
  6. Clientseitiges Rendern großer HTML-Mengen reduzieren (Langfristig). Vom Server gestreamtes HTML parst der Browser stückweise und gibt dabei automatisch Kontrolle ab. Wird HTML per JavaScript erzeugt, entfällt das, der Browser gibt erst nach Parsing und Rendering frei.[3] Das fällt bei SPAs stärker ins Gewicht, betrifft aber jede Seite, die nach Interaktionen viel HTML per JavaScript rendert.[3]

Umsetzung in Schritten

  1. Prüfe den Feld-INP deiner wichtigsten Seitengruppen (Tools siehe Messung und Diagnose).
  2. Richte bei Bedarf eine Feldmessung mit Attribution ein, damit du die verursachende Interaktion und die dominante Phase kennst.[3]
  3. Reproduziere die langsamste Interaktion im Performance-Panel der DevTools. Gelingt das nicht, drossle die CPU oder debugge ein echtes Android-Gerät per Remote-Debugging. Interagiere bei gedrosseltem Netzwerk direkt nach dem ersten Paint, weil der Hauptthread beim Start oft am stärksten ausgelastet ist.[10]
  4. Bestimme die dominante Phase der Interaktion: Input Delay, Processing Duration oder Presentation Delay.
  5. Wähle den passenden Hebel: Input Delay entspricht Hebel 3, Processing Duration den Hebeln 1, 2 und 4, Presentation Delay den Hebeln 5 und 6.
  6. Miss nach jeder Änderung im Lab und im Feld und wiederhole den Ablauf. Wer eine langsame Interaktion behebt, findet oft die nächste.[3]
  7. Starte nach dem Fix die Validierung in der Search Console, Details stehen unter Häufige Fragen zu INP.

Fallstricke und Grenzen

Typische Fehler

  • Ohne Felddaten starten. Felddaten zeigen, welche Interaktionen du optimieren musst, und sparen laut Google viel Zeit bei der Suche.[10]
  • forEach mit await mischen. Iterationsmethoden wie forEach warten nicht auf jeden Callback, sodass ein eingefügtes await scheduler.yield() nicht wie geplant unterbricht.[8]
  • Nach jedem Job yielden. scheduler.yield() hat Overhead. Bei sehr kurzen Jobs kann mehr Zeit für Yielden und Fortsetzen draufgehen als für die eigentliche Arbeit, als gängiger Richtwert gelten 50 Millisekunden zwischen zwei Yields.[8]
  • Nur auf setTimeout setzen. Der verschobene Code landet am Ende der Warteschlange, wartende Aufgaben laufen vorher. Nach fünf verschachtelten setTimeout-Aufrufen erzwingt der Browser außerdem mindestens 5 Millisekunden Verzögerung je weiterem Aufruf.[8]

Wann stößt INP an Grenzen?

Von den drei Phasen ist der Presentation Delay nach Googles Einschätzung am schwersten zu analysieren und zu beheben.[10] Manche große DOMs lassen sich nicht wesentlich verkleinern, die Techniken aus dem Abschnitt Optimierung greifen dann nur begrenzt.[3]

Zusammenspiel mit anderen Faktoren

  • LCP und CLS: LCP misst die Ladeleistung, CLS die visuelle Stabilität einer Seite.[5] Der Status einer URL-Gruppe in der Search Console richtet sich nach der schwächsten Metrik: Hat eine Gruppe schlechtes CLS bei gutem INP, gilt sie als schlecht.[7]
  • Weitere Page-Experience-Aspekte: Sichere Auslieferung, Darstellung auf Mobilgeräten und der Verzicht auf aufdringliche Interstitials helfen laut Google nicht direkt beim Ranking, machen die Seite aber angenehmer in der Nutzung.[4]

Häufige Fragen zu INP

Warum zeigt PageSpeed Insights keinen INP-Wert für meine Seite?

Für eine Seite entsteht kein INP-Wert, wenn Besucher nie klicken, tippen oder eine Taste drücken. Auch Bots wie Suchmaschinen-Crawler oder Headless-Browser, die nicht für Interaktionen geskriptet sind, erzeugen keinen Wert.[1] Fehlt der Wert trotz Interaktionen, erfüllt die Seite womöglich die CrUX-Voraussetzungen nicht, siehe Messung und Diagnose.[6]

Wie lange dauert es, bis sich eine INP-Verbesserung in der Search Console zeigt?

Rechne mit rund vier Wochen. Der Wert einer URL-Gruppe beschreibt, was 75 Prozent der Seitenaufrufe in den letzten 28 Tagen erreichten oder unterboten.[7] Mit „Start Tracking“ startest du ein 28-tägiges Monitoring der CrUX-Daten. Ein Problem gilt nur als behoben, wenn es in diesem Zeitraum in keiner URL mehr auftaucht. Die Funktion löst keine Neuindexierung aus.[7]

Wird INP auch in Firefox und Safari gemessen?

Ja, in aktuellen Versionen lässt sich INP per JavaScript messen. Die web-vitals-Bibliothek nutzt dafür die interactionId der Event-Timing-Einträge, unterstützt wird sie in Chrome und Edge ab Version 96, in Firefox ab 144 und in Safari ab 26.2.[11] Für Googles eigene Felddaten gelten die Chrome-Einschränkungen aus Messung und Diagnose.

Zählen Interaktionen in iframes zum INP?

Ja. INP wird auf Seitenebene gemeldet und berücksichtigt langsame Interaktionen in iframes der Seite, etwa das Abspielen eines eingebetteten Videos.[1] Jeder iframe hat einen eigenen Hauptthread, deshalb musst du prüfen, in welchem Frame die Interaktion stattfindet.[3] Die JavaScript-Schnittstelle meldet solche Events nicht, weshalb Werte aus CrUX und eigener Messung voneinander abweichen können.[1]

Fazit

INP zeigt, wie zügig deine Seite auf Eingaben reagiert, und ist ein Teilsignal der Core Web Vitals. Felddaten sollten klären, welche Interaktion den Wert bestimmt und in welcher Phase die Zeit verloren geht, bevor du optimierst. Danach arbeitest du die Hebel Interaktion für Interaktion ab. Alle Rankingfaktoren im Überblick findest du auf der Pillarpage, LCP und CLS sind die beiden anderen Core Web Vitals.

Quellen

  1. Google (web.dev): Interaction to Next Paint (INP) (Stand: 02.09.2025). https://web.dev/articles/inp. Abgerufen am 19.09.2026.
  2. Google (web.dev Blog): Interaction to Next Paint is officially a Core Web Vital (Stand: 12.03.2024). https://web.dev/blog/inp-cwv-launch. Abgerufen am 19.09.2026.
  3. Google (web.dev): Optimize Interaction to Next Paint (Stand: 02.09.2025). https://web.dev/articles/optimize-inp. Abgerufen am 19.09.2026.
  4. Google Search Central: Understanding page experience in Google Search results (Stand: 10.12.2025). https://developers.google.com/search/docs/appearance/page-experience. Abgerufen am 19.09.2026.
  5. Google Search Central: Understanding Core Web Vitals and Google search results (Stand: 10.12.2025). https://developers.google.com/search/docs/appearance/core-web-vitals. Abgerufen am 19.09.2026.
  6. Google (Chrome for Developers): CrUX methodology (Stand: 20.06.2024). https://developer.chrome.com/docs/crux/methodology. Abgerufen am 19.09.2026.
  7. Google (Search Console-Hilfe): Core Web Vitals report. https://support.google.com/webmasters/answer/9205520. Abgerufen am 19.09.2026.
  8. Google (web.dev): Optimize long tasks (Stand: 19.12.2024). https://web.dev/articles/optimize-long-tasks. Abgerufen am 19.09.2026.
  9. Google (web.dev): How large DOM sizes affect interactivity, and what you can do about it (Stand: 09.05.2023). https://web.dev/articles/dom-size-and-interactivity. Abgerufen am 19.09.2026.
  10. Google (web.dev): Manually diagnose slow interactions in the lab (Stand: 17.10.2024). https://web.dev/articles/manually-diagnose-slow-interactions-in-the-lab. Abgerufen am 19.09.2026.
  11. Google (web.dev): Find slow interactions in the field (Stand: 07.06.2024). https://web.dev/articles/find-slow-interactions-in-the-field. Abgerufen am 19.09.2026.