Core Web Vitals: INP hat FID abgelöst

Warum sich eine schnelle Seite trotzdem langsam anfühlen kann

Eine Website kann bereits sichtbar sein und beim ersten Klick trotzdem stocken. Ein verzögertes Menü ist ein anderes Problem als ein langsam geladenes Bild. INP, kurz für Interaction to Next Paint, betrachtet die Reaktionsfähigkeit auf Mausklicks, Tippen auf dem Touchscreen und Tastatureingaben während eines Seitenbesuchs. Seit März 2024 gehört INP statt FID zu den Core Web Vitals. Scrollen und das bloße Bewegen des Mauszeigers zählen dabei nicht als INP-Interaktionen.

Was der Messwert tatsächlich beschreibt

Die Latenz einer Interaktion besteht aus drei Teilen: Eingabeverzögerung, bis die Verarbeitung beginnen kann; Verarbeitungszeit der zugehörigen Ereignisbehandlung; und Darstellungsverzögerung bis zum nächsten Bild, das der Browser ausgibt. Ein langsamer Wert sagt deshalb noch nicht, welcher dieser Teile das Problem verursacht. Lange JavaScript-Aufgaben und aufwendige Layoutberechnungen sind unterschiedliche Ansatzpunkte.

INP ist kein Durchschnitt aller Klicks. Für einen einzelnen Seitenbesuch wird normalerweise die langsamste Interaktion herangezogen. Bei sehr vielen Interaktionen gibt es eine Ausreißerregel: Pro 50 Interaktionen wird ein besonders hoher Wert bei dieser Auswahl außer Acht gelassen. Besuche ohne gemessene Interaktion liefern keinen INP-Wert.

Wichtig ist außerdem die Grenze der Kennzahl: INP endet mit der nächsten Darstellung. Ein angezeigter Ladehinweis kann die erste Rückmeldung sein; ob eine anschließende Serveranfrage oder Zahlung erfolgreich abgeschlossen wird, beschreibt INP nicht.

Google bewertet INP bis einschließlich 200 Millisekunden als gut, über 200 bis einschließlich 500 als verbesserungsbedürftig und darüber als schlecht. Für die Bewertung einer Seite wird das 75. Perzentil der erfassten Besuche betrachtet, getrennt nach Mobilgeräten und Desktop. Dieser Wert beschreibt eine Grenze, die mindestens 75 Prozent der erfassten Werte erreichen oder unterschreiten. Ein einzelner schneller Test am Bürorechner ersetzt diese Felddaten nicht.

Erst die Interaktion finden, dann optimieren

Ein mögliches Beispielszenario: In einem Shop löst die Auswahl einer Größe gleichzeitig Variantenberechnung, Preisaktualisierung, Bilderwechsel und Tracking-Code aus. Ob davon etwas den Hauptthread blockiert, muss eine Messung zeigen. Bilder stärker zu komprimieren wäre ohne diese Diagnose keine begründete Lösung für die stockende Auswahl.

Für eine erste Untersuchung empfehlen wir diesen Ablauf:

1. Prüfen Sie in PageSpeed Insights, ob Felddaten für die konkrete URL vorliegen oder stattdessen Daten für den gesamten Ursprung angezeigt werden. Search Console arbeitet bei den Core Web Vitals zusätzlich mit Gruppen ähnlicher Seiten. Gruppen- und Ursprungswerte sind keine Einzelmessung der aufgerufenen URL.
2. Reproduzieren Sie wichtige Abläufe auf einem Mobilgerät, das zu Ihrer tatsächlichen Zielgruppe passt: Menü, Filter, Suche, Varianten und Warenkorb.
3. Zeichnen Sie eine Performance-Spur auf. Suchen Sie lange Aufgaben und die tatsächlich langsame Interaktion, statt nur die Startseite beim Laden zu messen.
4. Verändern Sie eine nachgewiesene Ursache und wiederholen Sie denselben Ablauf unter vergleichbaren Bedingungen.

Maßnahmen mit einem klaren Zweck

Drittanbieter-Skripte können Rechenzeit beanspruchen und mit der Verarbeitung von Eingaben konkurrieren. Prüfen Sie deshalb, welcher Code tatsächlich benötigt wird und wann er ausgeführt werden muss. Lange Aufgaben aufzuteilen kann dem Browser Gelegenheit geben, zwischen den Teilen Eingaben und Darstellung zu bearbeiten. Ob diese Änderung hilft, muss am betroffenen Ablauf geprüft werden.

Auch große DOM-Strukturen und aufwendige Layoutberechnungen können die Darstellung verzögern. Untersuchen Sie, ob eine kleine Zustandsänderung unnötig große Teile der Seite aktualisiert. Eine sofortige sichtbare Rückmeldung kann Nutzern zeigen, dass ihre Eingabe angekommen ist; sie ersetzt keinen korrekt abgeschlossenen Geschäftsprozess.

Laborwerte und echte Besuche richtig verbinden

Der übliche Lighthouse-Seitenlade-Test bildet keine vollständige Sitzung mit allen späteren Interaktionen ab. Total Blocking Time (TBT) beschreibt blockierende Arbeit unter den jeweiligen Testbedingungen; TBT ist nicht INP. Nutzen Sie Laborwerte zur Diagnose und Felddaten zur Beurteilung der tatsächlich erfassten Nutzung. Fehlen Felddaten, empfehlen wir gezielte Interaktionstests und, bei Bedarf, datenschutzgerecht eingerichtete eigene Messungen.

Die in PageSpeed Insights angezeigten CrUX-Felddaten beziehen sich auf ein rollierendes Zeitfenster von 28 Tagen. Nach einer Änderung enthalten sie deshalb zunächst weiterhin Besuche mit dem alten Stand. Das ist ein anderer Zeitraum als ein einzelner Test direkt nach der Veröffentlichung.

Halten Sie fest, wann eine Änderung veröffentlicht wurde, welche Interaktionen geprüft wurden und unter welchen Bedingungen die Tests liefen. Trennen Sie dabei klar zwischen dem Ergebnis eines einzelnen Tests und dem aggregierten Feldwert.

Was Sie für eine erste Prüfung sammeln können

Hilfreich sind die betroffenen URLs, ein genauer Ablauf und das verwendete Gerät. „Der Shop ist langsam“ lässt viel offen; „auf dem Smartphone stockt die Auswahl von Größe und Farbe“ führt zu einer überprüfbaren Aufgabe. Notieren Sie auch, ob sich das Verhalten wiederholen lässt und ob es während oder nach dem Laden auftritt.

Quellen und Messgrundlagen

• Google Chrome: INP – Definition, Auswahl der Interaktion und Grenzwerte – offizielles Dokumentationsarchiv.
• Google Chrome: INP optimieren – Phasen und Diagnose, offizielles Dokumentationsarchiv.
• Google Chrome: CrUX-Methodik – URL-/Ursprungsdaten, Seitengruppen und 28-Tage-Fenster, offizielles Dokumentationsarchiv.
• Google Chrome: web-vitals – aktuelle offizielle Messbibliothek; führt INP als Core Web Vital.