Core Web Vitals Update: INP ersetzt FID

Wie du beim Ranking in den Suchmaschinen abschneidest, hängt von vielen Faktoren ab – auch von der Reaktionszeit deiner Website. Content und Backlinks sorgen zwar für Sichtbarkeit, doch ob die Nutzer bleiben, entscheiden unter anderem schnelle, spürbare Interaktionen.

Seit März 2024 bewertet Google daher die Reaktionsfähigkeit mit der Metrik Interaction to Next Paint (INP). Die Kennzahl löst FID (First Input Delay) ab und rückt damit eine einfache Frage in den Mittelpunkt: Wie schnell reagiert deine Seite sichtbar, wenn jemand klickt oder tippt?

Für Marketer und CMOs ist das ein klarer Auftrag, da Conversion und Umsatz direkt betroffen sind. In Zukunft ist es ein Wettbewerbsvorteil, zu wissen, wie die INP-Metrik zustande kommt, welche Werte erstrebenswert sind und mit welchen Maßnahmen du diese verbessern kannst.

Was ist INP?

INP (Interaction to Next Paint) ist eine Core-Web-Vitals-Kennzahl für Reaktionsfähigkeit. Sie misst, wie schnell deine Website nach einer Nutzeraktion reagiert. Genau genommen zeigt dieser Wert, wie schnell deine Seite nach einer Interaktion (z. B. Klicken) etwas Sichtbares rendert (visuelles Feedback).

Ziel von Google war es, die Responsiveness realistischer zu messen als mit dem Vorgänger FID. Technisch basiert INP auf der Event-Timing-API (W3C), die Latenzen echter Nutzeraktionen im Browser bereitstellt.

Google stellte INP 2022 zunächst als experimentelle Kennzahl vor, kündigte 2023 den Wechsel von FID zu INP an und machte INP am 12. März 2024 zum offiziellen Core Web Vital. Seitdem gilt INP als wichtigste Kennzahl zur Reaktionsfähigkeit und taucht in CrUX, PageSpeed Insights und der Google Search Console als Feldmetrik auf. Interaction to Next Paint ist damit die präziseste Kennzahl für wahrgenommene Reaktionsfähigkeit.

Wie wird die Kennzahl INP gemessen?

INP beobachtet alle qualifizierten Interaktionen während des gesamten Seitenbesuchs und nimmt die schlechteste repräsentative Interaktion als Wert. Dabei misst er die Zeit von der Nutzeraktion bis zum nächsten sichtbaren Frame.

Der INP betrachtet nur bestimmte Interaktionen. Zoomen oder Scrollen entfallen, stattdessen berücksichtigt der INP nur Mausklicks, Taps auf dem Touchscreen oder Betätigungen der Tastatur (Screen und physisch).

Der INP selbst setzt sich aus drei Teilen (bzw. Zeitabschnitten) zusammen:

1. Input Delay: Zeit vom Eingang der Nutzeraktion bis der zugehörige Event-Handler startet.
2. Processing Time: In diesem Zeitabschnitt läuft der Event-Handler und die von ihm ausgelösten Arbeiten (z. B. Berechnungen, DOM-Änderungen).
3. Presentation Delay: Nach Erledigung der Handler-Arbeit dauert es, die Änderung auf dem Bildschirm sichtbar zu machen (der Browser rendert Layout und Pixel). Dies ist die Presentation Delay.

Diese drei Komponenten ergeben zusammen den INP, wodurch du folgende Formel ableiten kannst:

INP = Input Delay + Processing Time + Presentation Delay

Und was ist mit Ausreißern? Es kann durchaus vorkommen, dass ein und dieselbe Interaktion einmal schnell abläuft, ein anderes Mal jedoch weitaus länger benötigt.

Dafür hat Google eine Lösung: Über die vielen Besuche hinweg fassen sie die Besuchswerte im Chrome User Experience Report zu einem rollierenden 28-Tage-Fenster zusammen und bewerten das 75. Perzentil (P75). Die mobile und die Desktop-Performance werden zudem separat betrachtet.

Was sind INP-Schwellenwerte?

Der INP lässt sich in drei Kategorien einordnen, denen Schwellenwerte zugeordnet sind. Diese bilden eine Art Bewertungs- und Ampelsystem, dem Felddaten und reale Nutzererfahrung zugrunde liegen.

Farbe	Schwellenwert	Beschreibung
Grün	≤ 200 ms	Dies ist ein guter INP-Wert, die Nutzer spüren eine sofortige Reaktion.
Gelb	> 200 ms bis ≤ 500 ms	Der Wert ist optimierungsbedürftig. Du solltest Maßnahmen ergreifen.
Rot	> 500 ms	Die Reaktion ist träge und es ist sofortiges Handeln gefragt.

Ist INP besser als FID?

Ja, denn der INP bildet die wahrgenommene Reaktionsfähigkeit besser ab als FID. Denn der FID misst nur die erste Interaktion und nur den Input Delay. Das bedeutet, alles, was nach dem Start des Handlers passiert, erfasst er nicht. Der INP nimmt hingegen den repräsentativ schlechtesten Wert aller relevanten Interaktionen und misst dafür neben dem Input Delay auch die Processing Time und die Presentation Delay.

Es gibt also gute Gründe, warum INP den Vorgänger in den Core-Web-Vitals-Metriken ersetzt:

• Die erste Interaktion allein hat zu wenig Aussagekraft über die komplette Sitzung.
• Seiten mit JavaScript, die Long Tasks erzeugen und Render-Arbeiten anstoßen, erfasst der FID nicht.
• INP kann die Wahrnehmung der Besucher besser spiegeln, da er misst, wie schnell es visuelles Feedback gibt.

Warum ist INP Chefsache?

Weil Reaktionszeit Umsatz steuert. INP zeigt, wie schnell eure Seite sichtbar antwortet. Langsame Interaktionen kosten nämlich Leads, erhöhen die Kosten pro Akquise (CPA) und schwächen Rankings. Dem kannst du jedoch nicht allein über die Technik begegnen, stattdessen spielen die Steuerung über Ziele, das Budget und die Prioritätenvergabe eine entscheidende Rolle. CMOs sitzen am richtigen Hebel, um die Maßnahmen ins Rollen zu bringen.

Was bedeutet das INP Core Web Vitals Update für Webseitenbetreiber?

INP ist nun der Maßstab für wahrgenommene Reaktionsfähigkeit – und Unternehmen werden daran anhand echter Nutzerdaten gemessen. Das wirkt sich daher aufs Ranking, die Conversion und sogar auf die Roadmap aus.

Reaktionszeit spielte schon immer eine Rolle, wie Auswertungen von Google zeigten. So verlassen etwa 53 % der Nutzer eine mobile Seite, wenn sie nach 3 Sekunden noch nicht geladen hat. INP geht noch einen Schritt weiter, indem er relevante Interaktionen bewertet, die für Leads relevant sind.

Der INP kann neue Anforderungen an die Website, aber auch wertvolle Hinweise zur Verbesserung liefern. Je nach Ausgangslage kommen mögliche Vor- und Nachteile auf dich zu:

Aspekt	Möglicher Vorteil	Möglicher Nachteil
INP als Core Web Vital	Klarer Qualitäts-KPI für Produkt und Marketing	Ressourcenbedarf für Umsetzung
Messung mit Felddaten (CrUX/RUM)	Realitätsnahe Steuerung, weniger Blindflug	Verbesserungen kommen zeitversetzt (28 Tage)
Fokus auf Interaktionen	Besseres UX in kritischen Journeys (Formular, Filter) und niedrigeres Bounce-Risiko	Umbauten an UI/Flows nötig
Third-Party-Governance	Weniger Abhängigkeit von Vendor-Lag weniger Main-Thread-Blockaden	Widerstand im Tracking-Stack
Priorisierung nach Impact	Höherer ROI pro Sprint und ggf. bessere Ranking-Stabilität	Aufwand für Analyse und Alignment
Framework-Optimierungen (SPA)	Schnellere App-Erfahrung und bessere Core-Signals	Technische Komplexität

Wie baust du eine INP-Datenbasis auf?

Um INP als Ranking- und Conversion-Hebel zu steuern, solltest du ein RUM-Setup aufsetzen. RUM steht für Real User Monitoring und bedeutet die Erhebung echter Nutzerdaten. Du misst, was auf realen Geräten, Netzen und Browsern passiert, und ordnest jede Messung einer Journey, einem Element oder einer Script-Quelle zu.

Lab-Tests helfen zwar beim Debuggen, ein RUM-Setup hilft dir jedoch, gezielt zu fixen und die Web-Performance zu verbessern.

So setzt du ein RUM-Setup auf

Zum RUM-Setup gehören folgende Kriterien:

• Zielbild: Welchen Wert setzt du dir als Ziel/Was möchtest du verbessern?
• Messinstrument: Du benötigst ein Mess-Snippet im Frontend.
• Sampling: Um die Kosten zu reduzieren, reicht es, eine Sampling-Probe zu messen. Diese sollte jedoch nicht zu klein sein, um repräsentativ zu bleiben.
• Attribution: Durch Kontextfelder kannst du genau zuordnen, was, wann, wo und durch wen verursacht wird. Damit kannst du Fragen beantworten, welche User Interactions stattfanden, welche Skripte für Verzögerungen sorgten, welches Element betroffen war usw. Es ist also entscheidend, um Ursachen fix ausfindig zu machen.
• Segmentierung: Eine sinnvolle Unterteilung in verschiedene Segmente hilft bei der Ursachenbehebung. So erfordern Maßnahmen für den Mobile-INP oder den Desktop-INP oft verschiedene Herangehensweisen.
• Datenschutz: Speichere keine personenbezogenen Daten, gehe datenschutzkonform vor und bestimme Nutzungs- und Zugriffsrechte.
• Event-Schema: Für eine einheitliche, vergleichbare und auswertbare Messung ist ein Event-Schema erforderlich. Mit diesem legst du fest, welche Felder du je gemessener Interaktion speicherst.
• Reporting: Es empfiehlt sich ein monatlicher C-Level Report für die INP-P75 je Top-Journey, getrennt nach Mobil und Desktop, plus 28-Tage-Trend. Das operative Team sollte hingegen wöchentlich die langsamsten Interaktionen erhalten. Setze Alerts und kläre die Ownership

Die 3 Varianten aus der Praxis

In der Praxis gibt es drei Varianten, wie du mit der Messung starten kannst:

1. Schnellstart: Du bindest ein leichtes Snippet ein, setzt ein Sampling und sendest Events per sendBeacon an dein Analytics/RUM. Nach wenigen Tagen hast du eine erste Baseline mit slow interactions, betroffenen Elementen und Skript-Quellen vorliegen, mit denen du direkt starten kannst.
2. Tool-gestützt: Kombiniere die Google Search Console und PageSpeed Insights/CrUX für Trends mit einem RUM-Tool (self-hosted oder SaaS) für Ursachenlisten und Alerts. Der Vorteil? Es liegen bereits fertige Dashboards, Segmentierung und Regression-Warnungen vor, mit denen du auch leicht skalieren kannst.
3. Enterprise oder Custom: Hierbei kannst du ein eigenes RUM-Backend betreiben und es mit Events, Releases, Feature-Flags oder Error Monitoring verknüpfen. Mit der Attribution baust du C-Level sowie Ops-Reports nach Maß und erhältst das Maximum an Kontrolle. Diese Methode ist zwar die aufwändigste, für komplexe Set-ups jedoch perfekt geeignet.

Worin liegen mögliche Ursachen für einen schlechten INP?

Der INP wird davon beeinflusst, wie schnell der Event-Handler startet, wie lange er arbeitet und wie schnell der nächste sichtbare Frame erscheint. Ein schlechter INP-Wert entsteht daher meist dann, wenn der Browser zu viel auf einmal tun muss und dadurch ausgebremst wird.

Konkret können folgende Aspekte dafür verantwortlich sein:

• Blockade im Main-Thread durch große Bundles oder Polyfills im JavaScript
• Interaktionsstau durch Long Tasks > 50 ms
• Schwere Event-Handler und synchrone Bearbeitung
• Kritische Aktionen mischen sich durch fehlende Priorisierung mit Nebentätigkeiten
• Fehlendes Offloading
• Viele oder unnötige DOM-Änderungen
• Fehlendes sofortiges Feedback
• komplexe Effekte, große Bilder/Icons oder späte Webfonts
• Blockade durch Third-Party-Skripte
• Render-blocking Patterns
• Schwache Geräte/Browser (insbesondere mobil)
• Release-Regressionen
• SPA-Hydration/Routing zu schwer oder unglücklich getimt

Wie kannst du den INP verbessern?

Verbessere den INP, indem du den Main-Thread entlastest, schlanke Event-Handler einsetzt und sofort sichtbares Feedback renderst. In der Praxis kommen dafür verschiedene Maßnahmen infrage, wie das Abbauen von Long Tasks, das Reduzieren von Rendering-Arbeit sowie das Splitten von JavaScript.

Lasse dich jedoch nicht von gängigen Missverständnissen täuschen. Eine gute Lighthouse-Note bedeutet nämlich keinen guten INP. Lighthouse hilft dir beim Debuggen, aber Google bewertet Felddaten (RUM/CrUX/GSC). Außerdem reicht es nicht aus, die Kennzahl einmalig zu fixen, da neue Releases und Tags das Ergebnis verändern können.

Implementiere daher ein Dashboard und überprüfe die Maßnahmen regelmäßig auf deren Erfolg, um sie anzupassen. Weißt du, ob die Ursache im Input Delay, in der Processing Time oder im Presentation Delay liegt? Dann kannst du zu passenden Maßnahmen greifen.

Verringere den Input Delay

Damit der Handler schneller startet, solltest du den Main-Thread entlasten. Breche Long Tasks auf, splitte oder reduziere Skripte, minimiere sowie tree-shake dein JavaScript und überdenke die Ladeart. Priorisiere interaktionskritische Vorgänge, und sichtbares Feedback. Lazy Loading kommt beispielsweise für Below-the-Fold-Komponenten infrage.

Definiere zudem das Tag-Budget und halte kritische Pfade frei. Falls Chats, Heatmaps oder andere Elemente den Main-Thread belasten, solltest du diese nicht im Above-the-Fold initialisieren. Prüfe zudem, welche Third-Party-Skripte bereits laufen, und stelle sie, wenn möglich, hinten an.

Verkürze die Processing Time

Für eine schnellere Processing Time solltest du den Event-Handler verschlanken. Erledige im Klick selbst nur das Nötigste. Alles Weitere kann später ablaufen. Große Schleifen, komplexe Validierungen und synchrones JSON-Parsing sind hier fehl am Platz. Verschiebe rechenintensive Arbeit stattdessen in den Web Worker.

Verarbeite Daten asynchron und in kleinen Häppchen statt am Stück. Nutze Debounce/Throttle, wenn viele Events schnell nacheinander feuern, und cache Ergebnisse, die du wiederverwendest (z. B. bereits geladene Daten). Lade außerdem nur Daten, die der Nutzer jetzt wirklich benötigt.

Reduziere die Presentation Delay

Die Presentation Delay sinkt, je schneller der Nutzer ein visuelles Feedback erhält. Dies erreichst du, indem du Button-States änderst, Skeletons einblendest, oder leichtgewichtige Animationen einsetzt. DOM-Updates solltest du hingegen kleinhalten. Fasse Änderungen zusammen, vermeide Layout-Thrashing und plane UI-Arbeit mit requestAnimationFrame.

Nutze CSS-Containment, damit der Browser weniger neu berechnen muss. Bevorzuge GPU-freundliche Properties wie transform und opacity statt teurer Reflows. Effekte (z.B. große Schatten, Filter) und zu große Bilder solltest du hingegen vermeiden. Komprimiere Bilder stattdessen und liefere statische Ressourcen über ein CDN mit aktivem Browser-Caching. Lade Webfonts mit font-display, setze Lazy Loading für Medien ein und vermeide unnötige Repaints.

Fazit

Der INP zeigt dir, wie schnell deine Seite nach einem Klick sichtbar reagiert. Dieser Faktor wirkt sich nicht nur auf dein Ranking im World Wide Web aus, sondern liefert dir auch wichtige Hinweise und Optimierungsbedarf.

Auch wenn zunächst Investitionen in Analysen und Maßnahmen erforderlich sind, können die Maßnahmen langfristig betrachtet positiven Impact fürs Ranking, für die Conversion und auf die Akquisekosten haben.

Bau dir dazu einfach eine belastbare Datenbasis mit RUM auf und priorisiere Top-Journeys entlang der gemessenen Zeitspannen. Wähle passende Maßnahmen, um das Input Delay, die Processing Time sowie die Presentation Delay positiv zu beeinflussen und dir einen Wettbewerbsvorteil auszubauen.

Beachte jedoch, dass dies ein laufender Prozess ist, denn Releases und Kampagnen verändern die Werte und erfordern ggf. neue Anpassungen, damit du weiterhin im Top-Ranking mitspielen kannst.

FAQ – die wichtigsten Fragen rund um INP

Was ist der INP und was steckt dahinter?

INP (Interaction to Next Paint) misst, wie schnell deine Website sichtbar auf eine Nutzeraktion reagiert. Erfasst werden Klicks, Taps und Tastatureingaben über den gesamten Besuch. Aus diesen Interaktionen geht der repräsentativ langsamste Wert als INP hervor. Der Messwert setzt sich aus drei Teilen zusammen: Input Delay (bis der Handler startet), Processing Time (wie lange der Handler arbeitet) und Presentation Delay (bis der nächste sichtbare Frame erscheint).

Ist der INP Teil der Core Web Vitals Metrics?

Ja, seit dem 12. März 2024 ist INP ein fester Bestandteil der Core Web Vitals und hat den Vorgänger FID abgelöst. Google verwendet für die Berechnung Felddaten nach dem 75. Perzentil, wobei sie Mobile INP und Desktop INP separat betrachten.

Was ist der Unterschied zwischen INP und FID?

FID misst nur bei der ersten Interaktion auf der Seite den Input Delay. Der INP hingegen berücksichtigt alle relevanten Interaktionen eines Besuchs und erhebt Input Delay, Processing Time sowie Presentation Delay. Dadurch ist der INP in der Lage, die wahrgenommene Reaktionsfähigkeit noch besser abzubilden und zu beurteilen.

Was ist ein guter INP-Wert?

Ein guter INP-Wert liegt bei ≤ 200 ms, gemessen am 75. Perzentil (P75) deiner Felddaten. Werte zwischen > 200 und ≤ 500 ms gelten als optimierbar, > 500 ms als schlecht mit akutem Handlungsbedarf.

Wie kannst du mit Third-Party-Skripten umgehen, ohne das Tracking zu verlieren?

Nutze Tag-Budget und Consent-Gates. Lade Drittanbieter asynchron und möglichst erst nach dem ersten sichtbaren Feedback oder nach Interaktion. Halte kritische Journeys frei und reduziere Last ggf. mit Sampling oder Batching.

Welche Fehler wirken sich negativ auf den INP aus?

Der INP leidet vor allem dann, wenn der Main-Thread überlastet ist. Dies können zu viele synchrone JavaScripts, Long Tasks (> 50 ms) oder schwere Event-Handler verursachen. Ebenfalls kritisch sind viele DOM-Änderungen ohne Batching, fehlendes sofortiges Feedback sowie Third-Party-Skripte im Above-the-Fold.

Mit welchen Maßnahmen kannst du den INP verbessern?

Verbessere den INP-Wert, indem du die drei Zeitabschnitte, die gemessen werden, mithilfe von Maßnahmen verkürzt. Es hat sich bewährt, den Main-Thread zu entlasten (Long Tasks reduzieren, JavaScript splitten) und Third-Party-Skripte zu mindern. Halte Event-Handler schlank, verlagere Rechenarbeit in Web Worker und verarbeite Daten asynchron.

Referenzen

Splitt, M. (2023, May 10). INP in den Core Web Vitals. Google Search Central Blog. URL: https://developers.google.com/search/blog/2023/05/introducing-inp?hl=de

Wagner, J., & Pollard, B. (2025, September 2). Interaction to Next Paint (INP). web.dev (Chrome for Developers). URL: https://web.dev/articles/inp?hl=de

Shellhammer, A., & Neel, J. (2016, September 8). The need for mobile speed. Google Ad Manager Blog. URL: https://blog.google/products/admanager/the-need-for-mobile-speed/

European Parliament & Council of the European Union. (2016, April 27). Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data… (General Data Protection Regulation, GDPR). Official Journal of the European Union, L 119, 1–88 (published May 4, 2016). URL: https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng

Google Chrome Developers. (o. J.). Chrome UX Report (CrUX) API – Dokumentation. Chrome for Developers. URL: https://developer.chrome.com/docs/crux/api?hl=de

World Wide Web Consortium (W3C). (o. J.). Event Timing. W3C Working Draft. URL: https://www.w3.org/TR/event-timing/