Seit Maerz 2024 gehoert Interaction to Next Paint, kurz INP, zu den drei Core-Web-Vitals-Metriken von Google und hat den langjaehrigen First Input Delay (FID) abgeloest. Waehrend FID nur den ersten Klick einer Nutzerin oder eines Nutzers bewertete, misst INP die Reaktionsfaehigkeit einer Website ueber den gesamten Seitenbesuch hinweg. Das klingt zunaechst wie ein technisches Detail fuer Entwicklerteams, hat aber direkte Auswirkungen auf Rankings, Absprungraten und Umsatz. In diesem Ratgeber erklaeren wir, was INP genau misst, warum die Metrik so anders tickt als ihre Vorgaenger und mit welchen konkreten Massnahmen sich schlechte Werte in den Griff bekommen lassen.
Was ist INP genau?
INP steht fuer Interaction to Next Paint und misst die Zeitspanne zwischen einer Nutzerinteraktion, etwa einem Klick, einem Tap auf ein mobiles Element oder einer Tastatureingabe, und dem Moment, in dem der Browser den naechsten visuellen Frame darstellt. Anders gesagt: INP beantwortet die Frage, wie lange eine Seite braucht, um auf eine Aktion sichtbar zu reagieren. Ein Button, der nach dem Klick spuerbar haengt, bevor sich etwas auf dem Bildschirm veraendert, erzeugt einen hohen INP-Wert und damit ein schlechtes Nutzungsgefuehl.
Der entscheidende Unterschied zu FID liegt im Messzeitraum. FID betrachtete ausschliesslich die allererste Interaktion einer Sitzung, meist bevor die Seite ueberhaupt vollstaendig geladen war. Viele Probleme entstehen jedoch erst spaeter, etwa wenn Nutzerinnen und Nutzer durch einen Warenkorb klicken, ein Formular ausfuellen oder ein Dropdown-Menue oeffnen, waehrend im Hintergrund noch Skripte laufen. INP erfasst nahezu alle Interaktionen waehrend des Seitenbesuchs und bewertet am Ende meist die naechstschlechteste Interaktion, was ein deutlich realistischeres Bild der tatsaechlichen Nutzererfahrung liefert.
Warum Google FID durch INP ersetzt hat
Google begruendete den Wechsel damit, dass FID zu viele reale Performance-Probleme unentdeckt liess. Eine Seite konnte beim ersten Klick blitzschnell reagieren und trotzdem bei jeder weiteren Interaktion spuerbar ruckeln, etwa weil nachgeladene Werbe- oder Tracking-Skripte den Haupt-Thread blockierten. Solche Seiten schnitten bei FID hervorragend ab, fuehlten sich fuer echte Nutzerinnen und Nutzer aber langsam und unangenehm an. Mit INP bekommt Google ein Werkzeug, das die gesamte Interaktionsqualitaet einer Seite abbildet, nicht nur einen einzelnen, oft unrepraesentativen Moment.
Fuer den Suchmaschinen-Auftritt bedeutet das: Wer bislang allein auf Ladezeit und visuelle Stabilitaet optimiert hat, deckt nur zwei von drei Bausteinen der Core Web Vitals ab. Ohne eine gezielte INP-Betrachtung bleibt ein blinder Fleck, der sich in schlechteren Rankings, aber vor allem in schlechteren Conversion-Raten niederschlagen kann. Studien von Google selbst zeigen seit Jahren einen klaren Zusammenhang zwischen Reaktionsgeschwindigkeit und Kaufabschluessen, besonders im E-Commerce.
Die INP-Schwellenwerte im Ueberblick
Google bewertet INP in drei Kategorien. Die Grenzwerte gelten fuer das 75. Perzentil aller Interaktionen echter Nutzerinnen und Nutzer, nicht fuer Laborwerte einzelner Testklicks:
| Bewertung | INP-Wert | Bedeutung fuer Nutzer |
|---|---|---|
| Gut | bis 200 ms | Interaktionen wirken unmittelbar, kein spuerbares Ruckeln |
| Verbesserungswuerdig | 200 bis 500 ms | leichte Verzoegerung, teilweise als traege wahrgenommen |
| Schlecht | ueber 500 ms | deutlich wahrnehmbare Verzoegerung, Nutzer brechen eher ab |
Wichtig ist der Hinweis auf das 75. Perzentil: Es reicht nicht, dass die Mehrheit der Interaktionen schnell ist. Google schaut auf einen Wert, der von 75 Prozent aller Nutzerinnen und Nutzer unterschritten wird. Einzelne sehr langsame Geraete oder Netzwerkverbindungen koennen diesen Wert also durchaus in die Hoehe ziehen, was Optimierungen fuer Low-End-Smartphones besonders wichtig macht.
Wie wird INP gemessen?
Bei INP wird strikt zwischen Feld- und Labordaten unterschieden, und dieser Unterschied ist fuer die praktische Arbeit entscheidend.
Felddaten (Real User Monitoring)
Feld- oder Real-User-Daten stammen aus dem Chrome User Experience Report (CrUX), also aus den tatsaechlichen Besuchen echter Chrome-Nutzerinnen und -Nutzer. Diese Daten sind massgeblich fuer das Google-Ranking und lassen sich in der Google Search Console unter dem Bericht Core Web Vitals sowie im PageSpeed-Insights-Report einsehen. Der Nachteil: CrUX-Daten liegen nur fuer Seiten mit ausreichendem Traffic vor und aktualisieren sich rollierend ueber 28 Tage, sodass Verbesserungen erst mit zeitlicher Verzoegerung sichtbar werden.
Labordaten
Labordaten entstehen bei simulierten Tests, etwa in den Chrome DevTools unter dem Reiter Performance, in Lighthouse oder mit der kostenlosen JavaScript-Bibliothek web-vitals von Google. Sie eignen sich hervorragend, um konkrete Ursachen zu identifizieren, bilden aber nie exakt das Verhalten echter Endgeraete ab. Ein professionelles Website-Audit kombiniert deshalb beide Datenquellen: Felddaten zeigen das Ausmass des Problems, Labordaten zeigen die konkrete Ursache im Code.
Praktischer Tipp fuer den Einstieg: Oeffnen Sie die Chrome DevTools, wechseln Sie in den Performance-Tab, aktivieren Sie die Aufzeichnung, klicken Sie mehrfach durch typische Nutzerpfade wie Menue, Warenkorb oder Suchfeld, und stoppen Sie die Aufzeichnung. Lange, rot markierte Balken im Bereich Main zeigen exakt, welche Skripte den Haupt-Thread blockieren.
Die haeufigsten Ursachen fuer schlechte INP-Werte
In der Praxis lassen sich die meisten INP-Probleme auf eine Handvoll wiederkehrender Ursachen zurueckfuehren.
- Lange JavaScript-Aufgaben (Long Tasks): Aufgaben, die den Haupt-Thread laenger als 50 Millisekunden blockieren, verhindern, dass der Browser auf Eingaben reagieren kann. Je grösser ein JavaScript-Bundle, desto wahrscheinlicher solche Blockaden.
- Ueberladene Event-Handler: Klick- oder Eingabehandler, die synchron aufwendige Berechnungen, DOM-Manipulationen oder API-Aufrufe ausloesen, verzoegern die visuelle Rueckmeldung.
- Grosse DOM-Baeume: Je mehr Elemente eine Seite enthaelt, desto laenger dauert jede Style- und Layout-Berechnung nach einer Interaktion, insbesondere bei tief verschachtelten Strukturen.
- Third-Party-Skripte: Tracking-Pixel, Chat-Widgets, A/B-Testing-Tools und Werbenetzwerke laufen oft ausserhalb der eigenen Kontrolle und blockieren den Haupt-Thread genau dann, wenn Nutzerinnen und Nutzer interagieren.
- Layout-Thrashing: Wiederholtes, unnoetiges Lesen und Schreiben von Layout-Eigenschaften im selben Interaktionszyklus zwingt den Browser zu mehrfachen Neuberechnungen.
- Fehlendes Debouncing: Suchfelder oder Filter, die bei jedem Tastendruck sofort eine neue Berechnung oder Anfrage ausloesen, summieren sich schnell zu spuerbaren Verzoegerungen.
INP optimieren: die wichtigsten Stellschrauben
Die gute Nachricht: INP laesst sich mit gezielten, oft ueberschaubaren Massnahmen deutlich verbessern. Die folgenden Ansaetze haben sich in der Praxis bewaehrt.
Lange Aufgaben aufbrechen
Grosse JavaScript-Aufgaben lassen sich in kleinere Haeppchen zerlegen, sodass der Browser zwischen den Haeppchen Zeit fuer Rendering und Nutzereingaben findet. Techniken wie scheduler.yield() oder das klassische Aufsplitten mit setTimeout geben dem Haupt-Thread bewusst Luft. Moderne Frameworks bieten dafuer eigene Scheduling-Mechanismen an, die genau dieses Verhalten automatisieren.
Code-Splitting und Lazy Loading
Nicht jede Funktion muss beim ersten Seitenaufruf geladen werden. Wer JavaScript nach Route oder Komponente aufteilt und nicht sofort benoetigten Code erst bei Bedarf nachlaedt, reduziert die Menge an Skript, die der Browser initial parsen und ausfuehren muss. Das wirkt sich nicht nur auf INP, sondern auch auf die Ladezeit insgesamt positiv aus.
Third-Party-Skripte verzoegern und priorisieren
Nicht jedes Tracking-Skript muss sofort beim Seitenaufbau laufen. Ein pragmatischer Ansatz ist, Skripte nach Prioritaet zu ordnen und alles, was nicht fuer die erste Interaktion notwendig ist, verzoegert oder erst nach einer Nutzerinteraktion zu laden. Chat-Widgets, Bewertungs-Plugins und Marketing-Pixel gehoeren fast immer in diese Kategorie.
Web Worker fuer rechenintensive Aufgaben
Aufwendige Berechnungen, etwa Formatierungen grosser Datenmengen oder komplexe Validierungslogik, lassen sich in einen Web Worker auslagern. Da Web Worker in einem eigenen Thread laufen, blockieren sie den Haupt-Thread nicht und die Seite bleibt waehrend der Berechnung reaktionsfaehig.
Event-Handler entschlacken
Innerhalb eines Klick- oder Eingabehandlers sollte nur das Noetigste synchron passieren, alles Weitere kann asynchron nachgelagert werden. Debouncing bei Sucheingaben, das Zwischenspeichern von Berechnungsergebnissen und der Verzicht auf unnoetige Re-Renders reduzieren die Reaktionszeit spuerbar.
DOM-Groesse im Blick behalten
Eine schlanke, flache DOM-Struktur beschleunigt jede Interaktion. Virtualisierte Listen, bei denen nur sichtbare Elemente tatsaechlich gerendert werden, sind gerade bei langen Produktlisten oder Tabellen ein wirksames Mittel gegen aufgeblaehte DOM-Baeume.
INP im E-Commerce: besonders sensibel bei Shops
Online-Shops sind fuer schlechte INP-Werte besonders anfaellig, weil hier viele Interaktionen unmittelbar mit Umsatz verknuepft sind: Warenkorb-Buttons, Variantenauswahl, Mengenanpassung, Filterfunktionen und Checkout-Formulare. Jede spuerbare Verzoegerung an diesen Stellen erhoeht das Risiko eines Kaufabbruchs. Gerade bei Themes und Apps auf Plattformen wie Shopify sammeln sich ueber die Zeit zahlreiche Drittanbieter-Skripte an, von Bewertungs-Apps ueber Upselling-Tools bis zu Retargeting-Pixeln, die in Summe den Haupt-Thread stark belasten koennen. Wer einen Shop betreibt oder plant, sollte Performance von Anfang an mitdenken. Als Shopify-Agentur pruefen wir bei jedem Projekt, welche Apps tatsaechlich noetig sind und wie sich Drittanbieter-Skripte so einbinden lassen, dass sie die Reaktionsfaehigkeit nicht ausbremsen.
Das Zusammenspiel von INP, LCP und CLS
INP ist eine von drei Core-Web-Vitals-Metriken und sollte nie isoliert betrachtet werden. Largest Contentful Paint (LCP) misst, wie schnell der groesste sichtbare Inhalt laedt, Cumulative Layout Shift (CLS) misst unerwuenschte visuelle Spruenge waehrend des Ladens, und INP misst die Reaktionsfaehigkeit auf Interaktionen. Alle drei Metriken haengen technisch eng zusammen, denn dieselben Ursachen, etwa ueberladenes JavaScript oder schlecht priorisierte Ressourcen, wirken sich haeufig auf mehrere Metriken gleichzeitig aus. Eine umfassende Betrachtung der Core Web Vitals insgesamt ist deshalb sinnvoller als eine isolierte INP-Jagd, denn Massnahmen wie Code-Splitting oder das Auslagern von Drittanbieter-Skripten verbessern in der Regel gleich mehrere Metriken parallel.
Praktisches Vorgehen: Schritt fuer Schritt
Fuer Unternehmen, die INP strukturiert angehen wollen, hat sich folgendes Vorgehen bewaehrt:
- Aktuellen Zustand in der Google Search Console unter Core Web Vitals pruefen und betroffene URL-Gruppen identifizieren.
- Mit PageSpeed Insights oder Chrome DevTools konkrete Interaktionen nachstellen und Long Tasks im Performance-Tab sichten.
- Alle eingebundenen Drittanbieter-Skripte auflisten und pruefen, welche wirklich sofort geladen werden muessen.
- Grosse JavaScript-Bundles per Code-Splitting aufteilen und nicht kritischen Code verzoegert laden.
- Event-Handler auf unnoetige synchrone Arbeit pruefen und wo sinnvoll asynchron auslagern.
- Nach jeder Aenderung erneut messen, sowohl im Labor als auch nach einigen Wochen in den Felddaten.
- INP-Monitoring dauerhaft etablieren, statt einmalig zu optimieren und danach nicht mehr hinzuschauen.
Dieses Vorgehen ist letztlich ein Kernbestandteil eines soliden Webdesigns: Performance ist kein nachtraeglicher Feinschliff, sondern sollte von der ersten Konzeptionsphase an mitgeplant werden, von der Wahl des Frameworks bis zur Entscheidung, welche Drittanbieter-Tools tatsaechlich noetig sind.
Wann lohnt sich externe Unterstuetzung?
Kleinere INP-Probleme lassen sich oft mit den oben genannten Massnahmen selbst angehen, insbesondere wenn technisches Know-how im Team vorhanden ist. Bei komplexeren Websites mit vielen Drittanbieter-Integrationen, gewachsenen Legacy-Systemen oder grossen Produktkatalogen lohnt sich hingegen ein strukturiertes Audit durch Fachleute, die Ursache und Wirkung sauber trennen koennen, statt an Symptomen herumzudoktern. Eine neue Website mit sauberer technischer Basis kostet bei uns ab 1.990 Euro, ein performanter Shopify-Shop ab 1.490 Euro, und fuer wachsende B2B- und B2C-Marken mit hohem Traffic ab 3.990 Euro auf Shopify Plus. In allen drei Fallgruppen ist Performance von Anfang an Teil des Konzepts, nicht ein nachtraeglich aufgesetztes Reparaturprojekt.
Haeufige Fragen
Was bedeutet ein guter INP-Wert konkret fuer meine Website?
Ein INP-Wert bis 200 Millisekunden gilt als gut und bedeutet, dass Klicks, Taps und Eingaben nahezu ohne spuerbare Verzoegerung sichtbar reagieren. Das verbessert nicht nur das Nutzungsgefuehl, sondern wirkt sich auch positiv auf Absprungrate und Conversion aus.
Ist INP ein direkter Google-Rankingfaktor?
Ja, INP ist seit Maerz 2024 Teil der Core Web Vitals und fliesst als Signal in die Page-Experience-Bewertung ein. Der Effekt auf Rankings ist bei ansonsten aehnlicher Content-Qualitaet spuerbar, wichtiger ist jedoch meist der direkte Effekt auf Nutzerverhalten und Umsatz.
Wie schnell wirken sich Optimierungen auf die Messwerte aus?
Labordaten zeigen Verbesserungen sofort nach der Aenderung. Felddaten in der Google Search Console basieren auf einem rollierenden 28-Tage-Zeitraum, sodass belastbare Ergebnisse erst nach etwa vier bis sechs Wochen sichtbar werden.
Kann ein einzelnes Drittanbieter-Skript den INP-Wert wirklich stark verschlechtern?
Ja, gerade schwergewichtige Skripte fuer Tracking, Chat oder A/B-Testing koennen den Haupt-Thread genau in dem Moment blockieren, in dem Nutzerinnen und Nutzer interagieren. Oft reicht das Verzoegern oder Entfernen einzelner Skripte, um den INP-Wert spuerbar zu senken.
Betrifft INP nur grosse, komplexe Websites?
Nein, auch kleine Websites koennen schlechte INP-Werte haben, etwa durch ein einzelnes ueberladenes Formular-Skript oder ein schwergewichtiges Menue. Die Groesse der Website ist weniger entscheidend als die Menge und Qualitaet des ausgefuehrten JavaScripts.
Reicht ein guter Lighthouse-Score aus, um INP-Probleme auszuschliessen?
Nein, Lighthouse liefert Labordaten aus einer einzelnen simulierten Sitzung und bildet reale Nutzungsmuster nur begrenzt ab. Verlaessliche Aussagen liefern erst die Felddaten aus der Google Search Console oder aus eigenem Real User Monitoring.
Wie haengt INP mit der Mobilnutzung zusammen?
Mobilgeraete haben im Schnitt weniger Rechenleistung als Desktop-PCs, wodurch dieselbe Menge JavaScript dort deutlich laenger blockiert. Da Google bevorzugt mobile Daten fuer die Bewertung heranzieht, sollte jede INP-Optimierung gezielt auch auf leistungsschwaecheren Smartphones getestet werden.