Im März 2024 hat Google First Input Delay (FID) leise aus den Core Web Vitals genommen und durch Interaction to Next Paint (INP) ersetzt. „Leise" ist das richtige Wort: keine Pressekonferenz, keine Migration-Tools, nur ein Eintrag im Google-Webmaster-Blog. Wer es verschlafen hat, sieht es heute — und zwar im Ranking.
Wir haben in den letzten zwölf Monaten über 60 Audits gemacht. Das Muster ist überraschend einheitlich: klassische serverseitig gerenderte Seiten haben den Wechsel kaum gemerkt. Single-Page-Apps, schwere Shop-Frontends und alles, was viel JavaScript im Hauptthread laufen lässt, sind spürbar abgerutscht. Das ist kein Theorie-Artikel. Das ist, was wir in den Search-Console-Reports unserer Kunden sehen.
01 · VorgeschichteWarum FID nicht mehr reichte
FID hat genau eine Sache gemessen: die Verzögerung zwischen der ersten Nutzer-Interaktion und dem Moment, in dem der Browser mit der Verarbeitung beginnt. Klingt sinnvoll — war aber praktisch ein Geschenk für jedes Frontend. Eine einzige schnelle erste Reaktion und der Score war grün, egal wie zäh die Seite danach lief.
Das Problem: Nutzer interagieren nicht einmal. Sie tippen, scrollen, öffnen Dropdowns, filtern Listen, klicken durch Wizards. Genau dort lagen die echten Performance-Probleme — und genau dort hat FID weggesehen. Google hat das selbst eingeräumt und INP als „field metric that better reflects responsiveness throughout the page lifecycle" eingeführt.
FID vs. INP in einem Satz
FID misst, wie schnell die erste Interaktion reagiert. INP misst, wie schnell die schlechteste Interaktion einer Session reagiert — und das ist das, was Nutzer tatsächlich erinnern. Eine flüssige Startseite ist nichts wert, wenn der Filter im Shop ruckelt.
02 · MechanikWas INP wirklich misst
INP steht für Interaction to Next Paint. Gemessen wird die Zeit zwischen einer Nutzer-Interaktion (Klick, Tap, Tastendruck) und dem nächsten visuellen Update im Viewport. Der wichtige Unterschied zu FID: Es geht nicht um den Beginn der Verarbeitung, sondern um das sichtbare Ergebnis. Nutzer wollen sehen, dass etwas passiert ist.
Pro Seitenbesuch sammelt der Browser alle Interaktionen und meldet den schlechtesten Wert (bei langen Sessions: das 98. Perzentil) als INP-Score. Drei Komponenten gehen ein:
- Input Delay: Wie lange wartet der Event, bis er verarbeitet wird? Das ist faktisch der alte FID-Anteil.
- Processing Time: Wie lange laufen die Event-Handler? Hier liegen die meisten Probleme — fette React-Re-Renders, synchrone Filter-Operationen, blockierende Third-Party-Scripts.
- Presentation Delay: Wie lange braucht der Browser, um das nächste Frame zu rendern? Style-Recalcs, Layout-Thrashing, viele DOM-Mutationen.
Die wichtige Erkenntnis: Der Bottleneck liegt fast immer im Processing. Wir haben in unseren Audits 47 Domains durchgemessen — bei 41 davon machte die Processing Time mehr als 60 % des INP-Werts aus. Das heißt: Wer INP verbessern will, optimiert nicht den Input und nicht das Rendering — er entrümpelt seinen JavaScript-Code.
03 · BewertungDie neuen Schwellenwerte
Google bewertet INP in drei Stufen — gemessen am 75. Perzentil der Field-Daten (CrUX). Heißt: 75 % aller realen Nutzer-Sessions müssen unter dem Wert liegen, damit Ihre Seite als „gut" gilt.
Die 200-ms-Grenze ist enger als viele denken. Bei FID lag die „gut"-Schwelle bei 100 ms — aber gemessen wurde nur der Input Delay. Bei INP kommt jetzt das gesamte Rendering dazu. Faustregel: Wer mit FID solide grün war, landet mit INP fast immer im Mittelfeld.
„INP ist die ehrlichste Performance-Metrik, die Google je hatte. Sie lügt nicht. Sie misst genau das, was Nutzer als 'langsam' empfinden — und sie misst es kontinuierlich."— Jörg Strömsdörfer · Gründer + Inhaber, DieWebAG© · Mai 2026
04 · PraxisWo SPAs jetzt abgestraft werden
Single-Page-Apps gewinnen FID fast immer. Der erste Klick passiert oft nach dem Hydration-Schritt, da läuft alles flüssig. Was danach passiert, war FID egal. INP sieht es sofort.
Drei Muster sehen wir in jedem zweiten React/Vue/Angular-Audit:
- Synchrone Filter und Sortierung auf großen Listen: Ein Klick triggert
setState, das löst ein Re-Render der gesamten Liste aus. Bei 200+ Items im DOM bist du sofort bei 400 ms+. - Unnötig große Event-Handler: Click-Handler, die zehn Dinge gleichzeitig machen — Analytics-Call, State-Update, Animation triggern, Modal öffnen. Jedes davon synchron, im Main Thread.
- Third-Party-Scripts im kritischen Pfad: Customer-Support-Widgets, A/B-Test-Tools, Tag Manager. Sie blockieren Interaktionen, ohne dass es jemand merkt — bis INP sie sichtbar macht.
Der unsichtbare Schuldige: Hydration
Bei Next.js, Nuxt und Co. läuft nach dem ersten HTML-Render eine Hydration-Phase, die den Seiten-State an React/Vue koppelt. Klickt ein Nutzer während dieser Phase, wird der Event verzögert, bis Hydration fertig ist. Bei großen Apps reden wir hier locker über 600–1.200 ms — eine sichere Rote-Zone-Buchung im INP-Report.
−63 % INP bei einem B2B-SaaS-Dashboard
Bei einem Kölner SaaS-Kunden lag der p75-INP der Anwendung bei 740 ms — tief im Poor-Bereich. Nach drei Maßnahmen (Web Worker für die Filter-Logik, useDeferredValue für teure Re-Renders, Removal eines schlafenden Heatmap-Tools) waren wir bei 270 ms. Der organische Traffic stieg innerhalb von acht Wochen um 31 %.
05 · ToolingMessmethodik & Tools
INP ist eine Field-Metric. Das heißt: Sie wird bei echten Nutzern gemessen, nicht im Lab. Das macht die Messung tückisch — Lighthouse-Reports zeigen INP nur als Schätzung über Total Blocking Time. Verlassen Sie sich nicht darauf.
Was wir in unseren Audits tatsächlich nutzen:
- Search Console → Core Web Vitals: Die Quelle der Wahrheit. CrUX-Daten direkt von Google. Granular bis auf URL-Cluster.
- PageSpeed Insights: Zeigt Field- und Lab-Daten parallel. Wenn beide auseinanderklaffen, liegt das Problem oft an Hydration oder dynamisch geladenen Skripten.
- Chrome DevTools → Performance Insights: Lokaler Trace, der einzelne Interaktionen filmt. Hier finden Sie den konkreten Handler, der bremst.
- web-vitals Library (von Google selbst): JavaScript-Snippet, das INP-Werte direkt aus dem Client schickt. Pflicht für jede produktive Messung — alles andere ist Stochern im Nebel.
- RUM-Tools wie SpeedCurve, Calibre oder Sentry Performance: Wenn Sie es ernst meinen, läuft hier ein kontinuierliches Monitoring statt Stichproben.
Ein wichtiger Hinweis: CrUX braucht Mindest-Traffic, um Daten zu liefern. Kleinere Seiten ohne stabiles Datenvolumen sehen in der Search Console „insufficient data". Das heißt nicht, dass alles gut ist — es heißt, Google misst nicht. Setzen Sie in dem Fall zwingend ein eigenes RUM-Tool ein.
06 · HebelFünf konkrete Hebel, die heute wirken
Aus über 60 Audits seit Anfang 2025 haben sich fünf Hebel als verlässlich erwiesen. Reihenfolge nach Wirkung, nicht nach Aufwand:
- Schwere Handler in
requestIdleCallbackoder Web Worker auslagern. Alles, was nicht synchron passieren muss — Analytics, Logging, Pre-Fetch — gehört aus dem Hauptthread heraus. Allein das bringt oft 100–200 ms. - Virtualisierung großer Listen.
react-virtual,vue-virtual-scrolleroder native CSS-Containment. Wer 500 Karten gleichzeitig rendert, hat ein DOM-Problem, kein JS-Problem. - Third-Party-Audit. Jedes Tag-Manager-Snippet, das Sie nicht aktiv brauchen, ist Risiko. Faustregel: Wenn ein Tool nicht direkt zu Conversion-Tracking oder Cookie-Consent gehört, raus damit. Mindestens auf
asyncoderdefer. - React 18 Concurrent Features konsequent nutzen.
useTransition,useDeferredValue,startTransition— alles vorhanden, alles ungenutzt. Diese drei Hooks lösen die Hälfte aller INP-Probleme in modernen React-Apps. - Layout-Thrashing eliminieren. Jede Reihenfolge aus „Layout lesen → DOM ändern → Layout lesen" zwingt den Browser zu mehrfachen Style-Recalcs.
requestAnimationFramefür DOM-Manipulationen, niemals in Loops.
Was nicht hilft
Ein häufiger Reflex: „Wir bauen die Seite auf Astro / Qwik / Solid um." Klingt logisch — diese Frameworks sind tatsächlich INP-freundlicher. Aber: Ein Framework-Wechsel ist ein 6-stelliges Projekt. In den allermeisten Fällen kommen Sie mit den fünf Hebeln oben deutlich günstiger ans gleiche Ergebnis. Den Framework-Wechsel rechtfertigt nicht INP, sondern eine strategische Architektur-Entscheidung.
Genauso wenig hilft eine pauschale „CDN-Optimierung". CDN beschleunigt das initiale Laden — INP misst das Verhalten nach dem Laden. Hier liegt der häufigste Verkaufstrick mancher Performance-Tools: schnellere Auslieferung verkaufen, INP-Problem unterschlagen.
„INP zu fixen ist keine Frontend-Cosmetic. Es ist die Disziplin, ehrlich auf das eigene JavaScript zu schauen — und Dinge wegzulassen, statt mehr draufzustapeln."
Wer 2026 nachhaltig Sichtbarkeit halten will, kommt an dieser Metrik nicht vorbei. Die gute Nachricht: INP ist messbar, debugbar und reparabel. Die schlechte: Es lässt sich nicht beschönigen. Was im Code zäh ist, ist im Score sichtbar — und damit auch im Ranking.
Jörg Strömsdörfer
Gründete DieWebAG© 2009 in Köln. Seit 17 Jahren begleitet er Marken und Mittelständler durch jede Algorithmus-Generation — von klassischem SEO über technische Performance bis zu GEO/AEO. Schreibt am liebsten über das, was Lighthouse nicht zeigt.