INP-Realitätscheck: Warum mobile Websites an den Core Web Vitals scheitern

Die Seite lädt, das Bild ist da, der Text steht. Dann tippt jemand auf das Menü und nichts passiert. Eine halbe Sekunde später klappt es auf. Genau diese halbe Sekunde misst Interaction to Next Paint, kurz INP. Es ist die Kennzahl, an der ein großer Teil der mobilen Websites weiterhin durchfällt, während dieselben Seiten auf dem Schreibtischrechner passable Werte zeigen. Der Grund ist selten das Hosting. Er liegt in überladenen Baukästen, Dutzenden nachträglich eingebauten Erweiterungen und Skriptmengen, die niemand mehr überblickt.

Was INP eigentlich misst

INP hat 2024 die frühere Kennzahl First Input Delay abgelöst. Der Unterschied ist grundlegend. Die alte Kennzahl maß nur die Verzögerung bis zum Beginn der Verarbeitung der ersten Eingabe. Ein Trick reichte oft aus, um gut auszusehen: Wenn der Browser die erste Berührung schnell entgegennahm, war der Wert grün, auch wenn danach zwei Sekunden nichts sichtbar wurde.

INP misst den vollständigen Weg: von der Eingabe über die Verarbeitung bis zu dem Moment, in dem der Browser das nächste Bild zeichnet. Bewertet wird nicht die erste, sondern praktisch die schlechteste Interaktion einer Sitzung. Wer also zwanzig flüssige Klicks hat und einen zähen, wird nach dem zähen bewertet. Das ist unbequem, aber es entspricht dem, was Besucher als langsam empfinden.

Die Schwellen sind klar: bis 200 Millisekunden gilt als gut, zwischen 200 und 500 als verbesserungswürdig, darüber als schlecht. Zum Vergleich die beiden anderen Kennzahlen aus dem Kernsatz: Largest Contentful Paint sollte unter 2,5 Sekunden liegen, Cumulative Layout Shift unter 0,1. Bewertet wird jeweils das 75. Perzentil der echten Besuche, nicht der Bestwert im Labor.

Warum mobil so viel schlechter abschneidet

Der übliche Denkfehler lautet: Die Leitung ist schuld. Tatsächlich entscheidet bei INP nicht die Bandbreite, sondern die Rechenleistung. Ein Telefon der Mittelklasse hat einen deutlich schwächeren Einzelkern als ein Bürorechner und drosselt zusätzlich, wenn es warm wird. JavaScript läuft dabei in einem einzigen Hauptstrang. Solange dieser Strang mit einer Aufgabe beschäftigt ist, kann er auf keine Berührung reagieren.

Genau deshalb bricht die Interaktionsmetrik zuerst mobil ein. Die Seite lädt vielleicht sogar zügig, aber danach arbeitet der Hauptstrang minutenlang Aufgaben ab: Zustimmungsdialoge, Statistikskripte, Chat-Fenster, Karussells, Animationsbibliotheken, Schriftlader, Videoeinbettungen, Nachverfolgung für drei Werbeplattformen. Jede dieser Aufgaben blockiert für einige Dutzend bis mehrere hundert Millisekunden. Wer in dieser Zeit tippt, wartet.

Dazu kommt die Größe der Seitenstruktur. Baukästen erzeugen für ein einfaches Layout gern mehrere tausend Elemente, viele davon nur für Abstände und Effekte. Jede Änderung an dieser Struktur zwingt den Browser zu Neuberechnung und Neuzeichnung. Auf dem Bürorechner fällt das nicht auf, auf dem Telefon schon.

Die üblichen Verursacher

In der Praxis wiederholen sich dieselben sechs Muster:

• Seitenbaukästen mit Effektschichten. Verschachtelte Container, Animationen beim Scrollen, Parallaxe, Zähler, Slider. Jeder Effekt bringt eigene Skripte mit, die dauerhaft mitlaufen.
• Vierzig und mehr Erweiterungen. Jede lädt Skripte und Stilangaben auf allen Seiten, auch dort, wo sie nichts tut. Formularbaukasten, Bewertungsanzeige, Buchungssystem, zwei Statistikwerkzeuge, drei Erweiterungen für Optimierung.
• Zustimmungsdialoge von Drittanbietern. Sie laufen vor allem anderen, blockieren die erste Interaktion und starten anschließend eine Kaskade weiterer Skripte.
• Eingebettete Fremdinhalte. Videoeinbettungen, Kartendienste, Chatfenster und Bewertungsanzeigen ziehen im Hintergrund oft mehr Code nach als die eigene Seite insgesamt hat.
• Skriptgesteuerte Kleinigkeiten. Aufklappmenüs, Reiter und Bildergalerien, die mit Skript gelöst wurden, obwohl sie heute mit reinem HTML und CSS funktionieren.
• Ereignisbehandlung, die zu viel tut. Ein Klick, der gleichzeitig Zustand speichert, Nachverfolgung meldet, eine Animation startet und die Seitenstruktur umbaut, bevor überhaupt etwas sichtbar wird.

Warum der Lighthouse-Wert Sie beruhigt und trotzdem täuscht

Viele prüfen ihre Seite einmal im Labortest, sehen eine grüne Zahl und legen das Thema ab. Der Haken: Der Labortest lädt die Seite und misst, er bedient sie nicht. INP entsteht aber erst durch Bedienung. Deshalb liefert ein Labortest keinen INP-Wert, sondern nur einen Ersatzwert, meist die Gesamtblockierzeit.

Die belastbare Quelle sind Felddaten aus echten Besuchen. Sie stehen im Bericht zu den Core Web Vitals in der Google Search Console und in den Nutzungsdaten, die PageSpeed Insights oberhalb des Labortests anzeigt. Wichtig ist die Trennung nach Gerätetyp. Der mobile Wert ist der, der zählt, weil der Großteil der Besuche mobil stattfindet.

Wer genauer wissen will, welche Interaktion die schlechte Zahl verursacht, misst im Browser mit: In den Entwicklerwerkzeugen zeigt die Leistungsaufzeichnung die langen Aufgaben und die Interaktionen samt Dauer. Dabei unbedingt die Drosselung auf ein durchschnittliches Telefon einstellen, sonst sieht alles gut aus.

Was wirklich hilft

Die Reihenfolge ist entscheidend. Erst weglassen, dann verschieben, dann optimieren. Wer mit Optimierungserweiterungen anfängt, packt eine weitere Schicht auf das Problem.

1. Bestand aufräumen. Jede Erweiterung, die nicht nachweislich gebraucht wird, fliegt raus. Danach prüfen, welche der verbleibenden ihre Skripte auf allen Seiten lädt, obwohl sie nur auf einer arbeitet.
2. Fremdinhalte entkoppeln. Karten, Videos und Chatfenster erst nach einem bewussten Klick laden. Eine Vorschaugrafik mit Startschaltfläche kostet nichts und spart oft ein Megabyte Code.
3. Lange Aufgaben zerlegen. Arbeit, die nicht sofort sichtbar sein muss, in kleine Häppchen aufteilen und dem Browser zwischendurch die Kontrolle zurückgeben. Moderne Browser bieten dafür eine eigene Funktion zum Abgeben der Kontrolle, ersatzweise genügt ein kurzes Auslagern.
4. Erst zeichnen, dann melden. Im Klickereignis nur das erledigen, was sichtbar sein muss. Nachverfolgung, Protokollierung und Speicherung laufen danach, nicht davor.
5. Interaktionen ohne Skript lösen. Aufklappbereiche, Menüs und Dialoge lassen sich heute mit HTML-Elementen und CSS umsetzen. Das ist schneller, barrierearm und fällt nie aus.
6. Seitenstruktur verkleinern. Weniger Verschachtelung, weniger Elemente, keine Effektschichten ohne Zweck. Bereiche außerhalb des Sichtfelds lassen sich zusätzlich von der Berechnung ausnehmen.
7. Skripte einordnen. Was nicht für die erste Ansicht gebraucht wird, wird zurückgestellt oder erst bei Bedarf nachgeladen. Schriften mit Anzeigeverhalten laden, damit Text sofort lesbar ist.
8. Danach erneut messen. Nicht im Labor, sondern in den Felddaten. Diese brauchen einige Wochen, bis sie die Änderung abbilden.

Der ehrliche Punkt: manchmal lohnt der Neubau

Es gibt Seiten, bei denen sich jede Stunde Optimierung auszahlt. Und es gibt Seiten, bei denen der Unterbau das Problem ist. Wenn ein Baukasten die Ausgabe erzeugt, hat man auf die Menge des ausgelieferten Codes nur begrenzten Einfluss. Dann folgt ein bekanntes Muster: Optimierungserweiterung Nummer eins bringt zehn Punkte, Nummer zwei bricht das Layout, Nummer drei verschiebt das Problem auf die Unterseiten.

Die Rechnung ist nüchtern: Wenn die vorhandene Seite dauerhaft Pflege braucht, um mittelmäßige Werte zu halten, ist ein sauber gebauter Neuaufbau meist der günstigere Weg. Eine Seite, die ohne Effektschichten auskommt, erreicht gute Werte nicht durch Nachbessern, sondern von selbst. Wie man diese Entscheidung sortiert, steht im Beitrag Website selbst bauen oder bauen lassen.

Was Core Web Vitals für die Sichtbarkeit bedeuten

Die Kennzahlen sind ein Rankingfaktor, aber ein schwacher. Eine langsame Seite mit der besten Antwort schlägt weiterhin eine schnelle Seite ohne Inhalt. Der eigentliche Hebel liegt woanders: Wer auf dem Telefon zweimal vergeblich tippt, geht zurück. Diese Abbrüche kosten unmittelbar Anfragen, unabhängig von jeder Suchmaschine.

Dazu kommt der Nebeneffekt in Richtung Maschinen. Seiten, die ihre Inhalte erst nach mehreren Sekunden Skriptausführung zeigen, werden auch von automatisierten Systemen unvollständig erfasst. Dieselbe Aufräumarbeit, die INP verbessert, macht eine Seite gleichzeitig besser lesbar für Suchmaschinen und KI-Systeme, wie im Beitrag Webseiten bauen 2026: Ihre nächsten Besucher sind KI-Agenten beschrieben.

Worauf es am Ende ankommt

INP belohnt keine Tricks. Man kann eine träge Seite nicht schnell konfigurieren. Die Kennzahl misst, wie viel Arbeit der Browser leisten muss, bevor er auf einen Menschen reagieren darf. Weniger Arbeit heißt bessere Werte, und weniger Arbeit entsteht durch Weglassen, nicht durch Hinzufügen.

Der praktische Einstieg dauert eine halbe Stunde: Felddaten für Mobilgeräte ansehen, die schlechteste Seitengruppe herausgreifen, im Browser mit gedrosseltem Prozessor die auffällige Interaktion aufzeichnen und die drei größten Verursacher notieren. In den allermeisten Fällen stehen dort Namen, die nie jemand bewusst ausgewählt hat.

Weiterführend: Ladezeit testen und verbessern sowie Warum Webseiten zu viel Text haben.