INP und Core Web Vitals: Warum Website-Checks nicht beim Ladebalken enden

Viele Website-Checks hören immer noch dort auf, wo die Seite fertig geladen aussieht. Das war schon immer etwas optimistisch. Seit Interaction to Next Paint, kurz INP, als Core-Web-Vitals-Metrik relevant ist, ist es auch praktisch zu kurz gedacht.

Nutzer:innen bewerten eine Website nicht nur danach, ob der Hero-Bereich irgendwann sichtbar wird. Sie klicken auf Menüs, öffnen Filter, senden Formulare ab, akzeptieren oder verweigern Cookies, wechseln Tabs, starten Videos oder nutzen einen Checkout. Wenn diese Interaktionen verzögert reagieren, fühlt sich die Seite kaputt an — selbst wenn der Lighthouse-Score auf dem Papier freundlich guckt.

Was INP misst

INP bewertet die Reaktionsfähigkeit einer Seite über Interaktionen wie Klicks, Taps und Tastatureingaben. web.dev beschreibt INP als Metrik, die die Latenz von Nutzerinteraktionen über den Lebenszyklus einer Seite beobachtet und daraus einen Wert ableitet, der die allgemeine Reaktionsfähigkeit abbilden soll. Als gute Orientierung nennt web.dev: bis 200 ms ist gut, über 200 bis 500 ms braucht Verbesserung, über 500 ms ist schlecht.

Google hatte INP als Nachfolger von First Input Delay angekündigt. Der wichtige Unterschied: FID betrachtete nur die erste Interaktion. INP schaut breiter auf die tatsächliche Interaktivität einer Seite. Für moderne Websites ist das realistischer, weil das Problem oft nicht beim ersten Klick liegt, sondern bei späteren UI-Zuständen: Cookie-Banner, Filterlisten, Formularvalidierung, Modals, Buchungsstrecken oder JavaScript-Widgets.

Warum das für kleine Websites relevant ist

INP klingt erst einmal nach Performance-Nerd-Territorium. In Wirklichkeit trifft es sehr normale Website-Projekte:

• Ein WordPress-Theme lädt zu viel JavaScript.
• Ein Page Builder erzeugt große DOM-Strukturen.
• Ein Cookie-Banner blockiert den Main Thread.
• Tracking-Skripte laufen auf jeder Unterseite.
• Ein Formular validiert zu viel im Browser.
• Ein Shop-Filter rendert hunderte Elemente neu.
• Ein Chat-Widget hängt sich in jede Interaktion.

Das Ergebnis: Die Seite lädt vielleicht akzeptabel, fühlt sich aber schwer und träge an. Genau dort beginnt der wirtschaftliche Schaden: weniger Anfragen, mehr Abbrüche, schlechtere mobile Erfahrung und genervte Nutzer:innen.

Was ein INP-Check praktisch prüfen sollte

Ein sinnvoller Website-Check sollte nicht nur Startseite und Ladezeit anschauen. Für INP sind echte Interaktionen wichtig:

1. Cookie-Banner testen: öffnen, ablehnen, akzeptieren, Einstellungen speichern.
2. Navigation prüfen: Mobile Menüs, Dropdowns, Tabs und Akkordeons.
3. Formulare testen: Eingabe, Validierung, Fehlermeldungen, Absenden.
4. Conversion-Flows durchgehen: Anfrage, Checkout, Buchung, Login oder Newsletter-Anmeldung.
5. Drittanbieter beobachten: Analytics, Pixel, Chat, Maps, Videos, Consent-Tools.
6. Mobile Geräte ernst nehmen: Schwächere Geräte zeigen Probleme früher als der Entwickler-Laptop.
7. Feld- und Labordaten trennen: PageSpeed Insights, CrUX und RUM beantworten unterschiedliche Fragen.

Der wichtigste Punkt: Ein Labortest ohne Interaktion kann INP-Probleme übersehen. Wenn niemand klickt, tappt oder tippt, sieht man nicht, wo die Website wirklich zäh wird.

Typische technische Ursachen

Schlechter INP ist oft kein einzelner Monster-Bug. Häufig ist es eine Summe kleiner Entscheidungen: zu große JavaScript-Bundles, lange Tasks auf dem Main Thread, unnötige Re-Renders, komplexe Layout-Berechnungen, zu viele Event Listener, Third-Party-Skripte ohne Kontrolle, überladene Tag-Manager oder Animationen ohne Rücksicht auf schwächere Geräte.

Bei Website-Pflichtencheck ist deshalb nicht nur die Frage: Ist die Seite schnell? Die bessere Frage lautet: Welche Interaktionen fühlen sich für echte Nutzer:innen langsam an, und welche Skripte oder Komponenten verursachen das?

Mini-Checkliste für Website-Teams

Für kleine Teams reicht als Start ein wiederholbarer Prozess:

• Einmal pro Quartal PageSpeed Insights für wichtige URLs prüfen.
• Nach Relaunches und größeren Plugin- oder Tracking-Änderungen neu testen.
• Mobile Nutzerflüsse bewusst klicken, nicht nur Desktop anschauen.
• Consent-, Formular- und Checkout-Flows separat prüfen.
• Auffällige Drittanbieter-Skripte dokumentieren.
• JavaScript-Bundles und ungenutzte Skripte regelmäßig ausmisten.
• Für kritische Seiten echte Nutzerdaten oder RUM einplanen.

Das ist keine Performance-Esoterik. Es ist Wartung. Eine Website, die sichtbar lädt, aber bei jeder Interaktion kurz einfriert, ist nicht fast fertig. Sie ist fertig mit den Nerven ihrer Nutzer:innen.

Fazit

INP verschiebt den Blick von "wie schnell erscheint etwas?" zu "wie zuverlässig reagiert die Website?". Für Website-Betreiber, Agenturen und Dev-Teams ist das eine gute Entwicklung, weil sie näher an der echten Nutzung liegt.

Ein guter Website-Check sollte deshalb Ladezeit, Stabilität und Interaktivität gemeinsam betrachten. Core Web Vitals sind kein Selbstzweck. Sie sind ein Frühwarnsystem dafür, wo Nutzer:innen abspringen, bevor sie überhaupt erklären können, warum sich die Seite schlecht anfühlt.

Quellen

• Google Search Central: Introducing INP to Core Web Vitals
• Google Search Central: Understanding Core Web Vitals and Google search results
• web.dev: Interaction to Next Paint (INP)

Hinweis: Dieser Beitrag ist eine technische Einordnung und keine Rechtsberatung.