INP optimieren: die neue Core-Web-Vitals-Metrik meistern

INP hat FID als Core-Web-Vitals-Metrik abgelöst. Wir erklären, was Interaction to Next Paint bedeutet und wie Sie Ihre Website spuerbar reaktionsschneller machen.

04.09.2026 • Christopher Schütz • SEO • 10 Min Lesezeit
INP optimieren: die neue Core-Web-Vitals-Metrik meistern

Seit Maerz 2024 gehört Interaction to Next Paint, kurz INP, zu den drei Core-Web-Vitals-Metriken von Google und hat den langjaehrigen First Input Delay (FID) abgelöst. Während FID nur den ersten Klick einer Nutzerin oder eines Nutzers bewertete, misst INP die Reaktionsfaehigkeit einer Website über den gesamten Seitenbesuch hinweg. Das klingt zunaechst wie ein technisches Detail für Entwicklerteams, hat aber direkte Auswirkungen auf Rankings, Absprungraten und Umsatz. In diesem Ratgeber erklären 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 für 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 nächsten 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 überhaupt vollständig geladen war. Viele Probleme entstehen jedoch erst später, etwa wenn Nutzerinnen und Nutzer durch einen Warenkorb klicken, ein Formular ausfuellen oder ein Dropdown-Menue öffnen, während im Hintergrund noch Skripte laufen. INP erfasst nahezu alle Interaktionen während 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 begründete 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 für echte Nutzerinnen und Nutzer aber langsam und unangenehm an. Mit INP bekommt Google ein Werkzeug, das die gesamte Interaktionsqualität einer Seite abbildet, nicht nur einen einzelnen, oft unrepräsentativen Moment.

Für 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 Überblick

Google bewertet INP in drei Kategorien. Die Grenzwerte gelten für das 75. Perzentil aller Interaktionen echter Nutzerinnen und Nutzer, nicht für Laborwerte einzelner Testklicks:

BewertungINP-WertBedeutung für Nutzer
Gutbis 200 msInteraktionen wirken unmittelbar, kein spuerbares Ruckeln
Verbesserungswuerdig200 bis 500 msleichte Verzoegerung, teilweise als traege wahrgenommen
Schlechtüber 500 msdeutlich 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 Geräte oder Netzwerkverbindungen können diesen Wert also durchaus in die Höhe ziehen, was Optimierungen für Low-End-Smartphones besonders wichtig macht.

Wie wird INP gemessen?

Bei INP wird strikt zwischen Feld- und Labordaten unterschieden, und dieser Unterschied ist für 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 für 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 für Seiten mit ausreichendem Traffic vor und aktualisieren sich rollierend über 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 für den Einstieg: Öffnen 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 für 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.
  • Überladene Event-Handler: Klick- oder Eingabehandler, die synchron aufwendige Berechnungen, DOM-Manipulationen oder API-Aufrufe auslösen, verzoegern die visuelle Rueckmeldung.
  • Grosse DOM-Baeume: Je mehr Elemente eine Seite enthält, 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 auslösen, summieren sich schnell zu spuerbaren Verzoegerungen.

INP optimieren: die wichtigsten Stellschrauben

Die gute Nachricht: INP laesst sich mit gezielten, oft überschaubaren Massnahmen deutlich verbessern. Die folgenden Ansätze haben sich in der Praxis bewährt.

Lange Aufgaben aufbrechen

Grosse JavaScript-Aufgaben lassen sich in kleinere Haeppchen zerlegen, sodass der Browser zwischen den Haeppchen Zeit für Rendering und Nutzereingaben findet. Techniken wie scheduler.yield() oder das klassische Aufsplitten mit setTimeout geben dem Haupt-Thread bewusst Luft. Moderne Frameworks bieten dafür 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 ausführen 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 für die erste Interaktion notwendig ist, verzoegert oder erst nach einer Nutzerinteraktion zu laden. Chat-Widgets, Bewertungs-Plugins und Marketing-Pixel gehören fast immer in diese Kategorie.

Web Worker für 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 während 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-Größe 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 für schlechte INP-Werte besonders anfällig, weil hier viele Interaktionen unmittelbar mit Umsatz verknüpft sind: Warenkorb-Buttons, Variantenauswahl, Mengenanpassung, Filterfunktionen und Checkout-Formulare. Jede spuerbare Verzoegerung an diesen Stellen erhöht das Risiko eines Kaufabbruchs. Gerade bei Themes und Apps auf Plattformen wie Shopify sammeln sich über die Zeit zahlreiche Drittanbieter-Skripte an, von Bewertungs-Apps über Upselling-Tools bis zu Retargeting-Pixeln, die in Summe den Haupt-Thread stark belasten können. Wer einen Shop betreibt oder plant, sollte Performance von Anfang an mitdenken. Als Shopify-Agentur prüfen 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 größte sichtbare Inhalt laedt, Cumulative Layout Shift (CLS) misst unerwuenschte visuelle Spruenge während des Ladens, und INP misst die Reaktionsfaehigkeit auf Interaktionen. Alle drei Metriken haengen technisch eng zusammen, denn dieselben Ursachen, etwa überladenes JavaScript oder schlecht priorisierte Ressourcen, wirken sich häufig 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 für Schritt

Für Unternehmen, die INP strukturiert angehen wollen, hat sich folgendes Vorgehen bewährt:

  • Aktuellen Zustand in der Google Search Console unter Core Web Vitals prüfen 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 prüfen, welche wirklich sofort geladen werden müssen.
  • Grosse JavaScript-Bundles per Code-Splitting aufteilen und nicht kritischen Code verzoegert laden.
  • Event-Handler auf unnoetige synchrone Arbeit prüfen und wo sinnvoll asynchron auslagern.
  • Nach jeder Änderung 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 Unterstützung?

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 können, 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 für 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.

Häufige Fragen

Was bedeutet ein guter INP-Wert konkret für 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 ähnlicher Content-Qualität 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 Änderung. 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 für Tracking, Chat oder A/B-Testing können 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 können schlechte INP-Werte haben, etwa durch ein einzelnes überladenes Formular-Skript oder ein schwergewichtiges Menue. Die Größe der Website ist weniger entscheidend als die Menge und Qualität 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 für die Bewertung heranzieht, sollte jede INP-Optimierung gezielt auch auf leistungsschwaecheren Smartphones getestet werden.

Verwandte Artikel

SEO Lokales SEO 2026: Was sich ändert und wie Sie profitieren SEO Google Updates 2025: Alle Änderungen im Überblick SEO Lokales SEO Schortens: So wirst du bei Google gefunden SEO Google Maps SEO: So landest du im Local 3-Pack

Haben Sie Fragen zu diesem Thema?

Wir beraten Sie gerne persönlich und unverbindlich

Kontakt aufnehmen Weitere Artikel lesen
🔍

Warten Sie!

Wie gut ist Ihre Website wirklich?
Finden Sie es in 30 Sekunden heraus, kostenlos.

Jetzt kostenlosen Website-Check starten → Keine Registrierung nötig · Ergebnis sofort · 100% kostenlos