INP-Bereitschaft

INP-Readiness ist eine Kurzform dafür, wie gut eine Seite darauf vorbereitet ist, Interaction to Next Paint (Interaktion bis zum nächsten sichtbaren Update) im Feld zu bestehen – nicht nur in einem Labortest. Für SEO-Teams ist das relevant, weil INP ein Core Web Vital ist und weil träge Interfaces die Formularfertigstellung, die Add-to-Cart-Rate und die Lead-Qualität ruinieren.

Was INP-Readiness eigentlich bedeutet

INP misst die Latenz einer Nutzerinteraktion bis zum nächsten visuellen Update. Klick. Tippen. Tastendruck. Google klassifiziert 200 ms oder weniger als gut, 200–500 ms als verbesserungsbedürftig und 500 ms+ als schlecht.

Der wichtige Punkt: Das ist größtenteils Feld-Daten. Google Search Console und PageSpeed Insights stützen sich stark auf Daten des Chrome UX Report, wenn genug Traffic vorhanden ist. Lighthouse kann wahrscheinliche Ursachen aufzeigen, belegt aber nicht, dass deine Seite im Betrieb wirklich bereit ist.

Warum SEOs das berücksichtigen sollten

INP hat FID im März 2024 als Core Web Vital abgelöst. Diese Änderung war wichtig, weil FID zu nachsichtig war. Eine Seite konnte beim ersten Tap schnell reagieren und dann beim zweiten, dritten oder vierten Interaktionsschritt einfrieren – und sah unter FID trotzdem noch in Ordnung aus. INP ist strenger. Bessere Kennzahl. Schwerer vorzutäuschen.

Allerdings: Übertreibe den Einfluss auf Rankings nicht. Google hat nie gesagt, dass Core Web Vitals ein besonders starker Ranking-Faktor sind. John Mueller von Google hat Signale zur Seiten-Erfahrung wiederholt als Tie-Breaker eingeordnet, wenn andere Signale ähnlich sind. Der Business Case ist in der Regel stärker als der reine Ranking-Fall.

So bewertest du die Readiness

• Google Search Console: Prüfe den Bericht zu den Core Web Vitals für die URL-Gruppen nach Mobile und Desktop. Das ist deine oberste SEO-Perspektive.
• PageSpeed Insights: Vergleiche CrUX-Feld-Daten mit Lighthouse-Diagnosen. Wenn das Feld-INP 280 ms beträgt und das Lab-INP 90 ms, dann haben deine echten Nutzer Probleme, die dein Test-Setup nicht erkannt hat.
• Chrome DevTools: Nutze das Performance-Panel, um lange Tasks, Verzögerungen in Event Handlern und Rendering-Engpässe zu finden.
• Screaming Frog: Crawle Templates und ordne zu, welche Seitentypen schweres JS, Third-Party-Widgets oder aufgeblähte Component Libraries laden.
• Ahrefs oder Semrush: Setze Reparaturen priorisiert an den Templates an, die die meisten organischen Einstiege liefern – nicht an zufälligen Pages mit niedrigem Traffic.

Was INP typischerweise kaputt macht

• Lange Main-Thread-Tasks über 50 ms
• Starkes Client-Side-Rendering in React-, Vue- oder Angular-Apps
• Third-Party-Skripte wie Chat, A/B-Testing, Consent-Tools und Heatmaps
• Teure DOM-Updates und Layout Thrashing nach der Eingabe
• Geringe Endgeräte (Low-End Android) mit schwachen CPUs – „läuft am Desktop gut“ sagt hier nichts aus

Der ehrliche Vorbehalt: INP-Daten können verrauscht sein. Seiten mit wenig Traffic haben möglicherweise nicht genug CrUX-Daten. Die URL-Gruppierung in der GSC kann verstecken, welches konkrete Template genau scheitert. Und manche Interaktionen kommen schlicht nicht häufig genug vor, um sich erst zu zeigen, wenn eine Funktion echte Nutzung bekommt.

Was gute Teams tun

Sie behandeln INP-Readiness als Template- und Revenue-Problem, nicht als reinen Vanity-Score. Behebe zuerst Checkout, Lead-Formular, Produktfilter, interne Suche und Navigation. Wenn eine Kategorieseite 50.000 organische Besuche im Monat hat und bei 260 ms INP landet, verdient das Aufmerksamkeit, bevor du ein Blog-Template polierst, das bereits bei 140 ms liegt.

Surfer SEO, Moz, Ahrefs und Semrush können INP nicht direkt diagnostizieren. Sie helfen dir zu entscheiden, wo sich Performance-Arbeit am meisten lohnt. Das Debugging passiert weiterhin in GSC, PageSpeed Insights, Chrome DevTools und deinem RUM-Setup.