Wie lässt sich INP durch die Optimierung der Core Web Vitals auf Mobilgeräten senken?

Um den INP auf Mobilgeräten zu verbessern, kommt es nicht in erster Linie darauf an, dass die Seite schneller heruntergeladen wird. Entscheidend ist, dass der Browser nach einem Klick, Tippen oder einer Tastatureingabe so schnell wie möglich den nächsten Frame anzeigt. Komprimierte Bilder und ein CDN können das Ladeerlebnis verbessern, lösen aber nicht unmittelbar das Problem, dass eine Schaltfläche nach dem Klick lange keine Rückmeldung gibt. Ist der Hauptthread durch Skriptausführung oder Rendering belegt, können Interaktionen weiterhin stocken.

Um zu beurteilen, wie sich die Core Web Vitals für ein besseres mobiles Nutzungserlebnis optimieren lassen, sollte der INP in Eingabeverzögerung, Verarbeitungsdauer und Darstellungsverzögerung aufgeschlüsselt werden. Anschließend werden die jeweiligen Ursachen gezielt behoben. Es reicht weder aus, nur die Dauer des Klick-Callbacks zu verkürzen, noch nur einen einzelnen Labortest-Score zu verbessern, um nachzuweisen, dass die Interaktionsreaktion für echte Nutzer besser geworden ist.

Der INP misst die Zeit bis zum nächsten Frame nach einer Interaktion, nicht die Dauer bis zum Abschluss eines Geschäftsvorgangs

Der INP (Interaction to Next Paint) erfasst qualifizierte Klick-, Tipp- und Tastaturinteraktionen während des Seitenaufrufs und gibt Aufschluss über die Reaktionsfähigkeit der langsameren Interaktionen. Bei vielen Interaktionen werden gemäß den Regeln einige wenige Extremwerte bei der Berechnung ignoriert. Der INP ist daher weder einfach der Durchschnitt aller Klickzeiten noch gleichbedeutend mit dem absoluten Maximum.

In der Bewertung der Core Web Vitals von Google gilt ein INP von höchstens 200 Millisekunden als „gut“, ein Wert über 200 und höchstens 500 Millisekunden als „verbesserungsbedürftig“ und ein Wert über 500 Millisekunden als „schlecht“. Ob eine Website die Grenzwerte einhält, wird anhand des 75. Perzentils realer Besuchsdaten beurteilt, getrennt für Mobilgeräte und Desktop. Das ist eine andere statistische Betrachtung als die Auswahl repräsentativer Interaktionen innerhalb eines einzelnen Seitenaufrufs.

Der INP ist auch nicht mit der Antwortzeit einer API gleichzusetzen. Wird nach dem Absenden einer Anfrage sofort der Status „Wird gesendet“ angezeigt und die Netzwerkanfrage erst danach abgeschlossen, kann der INP dieser Interaktion niedrig sein. Ein niedriger INP bedeutet jedoch nicht, dass der Geschäftsvorgang erfolgreich war. Die Dauer der Anfrage, die Fehlerrate und doppelte Übermittlungen müssen weiterhin separat überwacht werden.

Erst feststellen, welcher Abschnitt langsam ist, dann die passende Maßnahme wählen

Die Eingabeverzögerung einer Interaktion ist die Wartezeit zwischen der Nutzeraktion und dem Beginn der Ausführung des Event-Callbacks. Die Verarbeitungsdauer ist die Zeit, die die zugehörigen Callbacks für ihre Ausführung benötigen. Die Darstellungsverzögerung ist die Zeit vom Ende des Callbacks bis zur Anzeige des nächsten Frames. Jeder dieser drei Abschnitte kann auf Mobilgeräten zum Engpass werden.

Wenn der Hauptthread beim Klick des Nutzers gerade Skripte analysiert, Drittanbieter-Code ausführt oder andere Aufgaben bearbeitet, erhöht sich die Eingabeverzögerung. Werden im Callback synchron viele Produkte gefiltert, ein ganzes Formular validiert oder zahlreiche Komponenten aktualisiert, steigt die Verarbeitungsdauer. Sind nach Ende des Callbacks außerdem umfangreiche Stilberechnungen, Layout- und Rendering-Arbeiten erforderlich, erhöht sich die Darstellungsverzögerung.

Mit dem Performance-Panel der Chrome DevTools lassen sich Aktionen wie das Öffnen eines Menüs, das Filtern von Produkten, der Wechsel einer Spezifikation und das Absenden einer Anfrage aufzeichnen. Anhand des Interaktionsverlaufs können Hauptthread-Aufgaben und Rendering-Aktivitäten untersucht werden. Aufgaben, die länger als 50 Millisekunden dauern, gelten als Long Tasks, sind aber lediglich ein Hinweis für die Fehlersuche: Auch mehrere aufeinanderfolgende kurze Aufgaben können das Rendering verzögern. Dass „keine Long Tasks vorhanden sind“, ist daher kein Nachweis dafür, dass der INP die Anforderungen erfüllt.

Blockierungen reduzieren, statt Skripte lediglich später auszuführen

Bei einer hohen Eingabeverzögerung sollte geprüft werden, ob Skripte gerade dann gebündelt ausgeführt werden, wenn Nutzer mit der Seite zu interagieren beginnen. Auf Marketing-Websites sollten insbesondere Live-Chat, Tracking-Tags, Werbe-Tracking und Pop-up-Komponenten hinsichtlich Ladezeit und Ausführungskosten einzeln überprüft werden. async oder defer ändern den Lade- und Ausführungszeitpunkt von Skripten, verhindern aber nicht, dass deren Laufzeit den Hauptthread beansprucht.

Nicht notwendige Skripte können abhängig vom Seitenzweck, dem Einwilligungsstatus oder dem tatsächlichen Nutzungsbedarf geladen werden. Außerdem sollten doppelte Tags entfernt werden. Beim verzögerten Laden ist darauf zu achten, nicht alle Skripte erst beim ersten Klick zu starten. Andernfalls werden die Ladekosten lediglich auf den Interaktionspfad verlagert.

Synchrone Berechnungen sollten in mehreren Abschnitten verarbeitet werden, wobei der Hauptthread zwischen den Abschnitten freigegeben wird. In unterstützten Browsern kann scheduler.yield() verwendet werden; in anderen Umgebungen ist eine Fallback-Lösung erforderlich. Es ist nicht zuverlässig, Aufgaben lediglich mit Promise oder queueMicrotask aufzuteilen, da die Microtask-Warteschlange vor dem Rendering weiterhin abgearbeitet werden kann. CPU-intensive Berechnungen, die nicht vom DOM abhängen, können in einen Web Worker ausgelagert werden. Dabei sind jedoch der Aufwand für die Kommunikation und das Kopieren von Daten zu berücksichtigen.

Event-Callbacks und Rendering gemeinsam reduzieren

Ein Klick-Callback sollte zunächst notwendige Zustandsänderungen vornehmen, etwa einen Ladezustand anzeigen, die aktuelle Auswahl markieren oder eine erneute Übermittlung verhindern. Nicht dringende Aufgaben können anschließend eingeplant werden. Die Benutzeroberfläche zuerst zu ändern und danach noch eine längere synchrone Berechnung auszuführen, bedeutet nicht, dass Nutzer die Rückmeldung bereits sehen. Der Browser muss Gelegenheit zum Rendering erhalten.

Bei Produktfiltern können Berechnungsergebnisse zwischengespeichert werden, damit nicht bei jeder Interaktion alle Daten erneut durchlaufen werden müssen. Bei der Formularvalidierung sollte vermieden werden, das gesamte Formular bei jeder Eingabe eines Zeichens neu zu berechnen. Debouncing eignet sich, um nicht sofort notwendige Abfragen zu reduzieren, sollte aber weder die visuelle Rückmeldung einer Schaltfläche verzögern noch dazu dienen, Verzögerungen bei notwendigen Aktionen zu kaschieren.

Bei einer hohen Darstellungsverzögerung sollten DOM-Größe, Reichweite von Stiländerungen und Aktualisierungsgrenzen von Komponenten geprüft werden. Lange Produktlisten können virtualisiert werden; Anforderungen an Barrierefreiheit und Suchmaschinen-Crawling müssen dabei jedoch ebenfalls berücksichtigt werden. Wiederholtes „Stile schreiben – Maße lesen“ kann erzwungene Layoutberechnungen auslösen. Deshalb sollten Lesevorgänge möglichst gebündelt vor den Schreibvorgängen erfolgen. Bei Framework-Anwendungen sollte außerdem geprüft werden, ob eine lokale Zustandsänderung unnötige Aktualisierungen anderer Komponenten auslöst, statt nur die Callback-Dauer zu erfassen.

Auch requestAnimationFrame ist kein Auffangbecken für zeitaufwendige Aufgaben: Der darin ausgeführte Code läuft vor dem Rendering. Umfangreiche Berechnungen können daher weiterhin den nächsten Frame blockieren.

Echte Nutzungsdaten zur Validierung heranziehen, statt sich auf einen einzelnen Test zu verlassen

Labortests eignen sich dazu, Ursachen nachzustellen; das Monitoring realer Nutzer zeigt, wie groß die Auswirkungen sind. Die CrUX-Daten in PageSpeed Insights spiegeln das tatsächliche Nutzungserlebnis wider. Bei zu geringem Traffic fehlen möglicherweise Daten auf Seitenebene. Fehlende Daten dürfen nicht als Hinweis auf gute Performance verstanden werden. Die Total Blocking Time in Lighthouse kann helfen, die Belastung des Hauptthreads während des Ladevorgangs zu erkennen, ist aber kein Ersatz für den INP.

Auf der Website kann web-vitals einschließlich seiner Attribution-Funktion verwendet werden, um das Interaktionsziel, den Seitentyp und die Dauer der einzelnen Phasen zu erfassen. Dabei sollten keine personenbezogenen Informationen wie Formularinhalte gesammelt werden. Die Tests sollten auf echten Mobilgeräten und unter angemessener CPU-Drosselung durchgeführt werden. Der schmale Ansichtsmodus eines Desktop-Browsers bildet die Unterschiede bei der Rechenleistung mobiler Geräte nicht ab.

Bei der Abnahme nach dem Rollout sollten die INP-Verteilungen für vergleichbare Seitentypen und ähnliche Gerätebedingungen verglichen und geprüft werden, ob wichtige Interaktionen weiterhin korrekt abgeschlossen werden. CrUX verwendet rollierende Daten aus 28 Tagen; deshalb ist nicht zu erwarten, dass sich alle Auswirkungen einer Änderung sofort widerspiegeln. Gemäß der INP-Definition von Google ist der Nachweis einer wirksamen Optimierung eine kürzere tatsächliche Wartezeit bei Interaktionen, nicht ein geringeres Ressourcenvolumen oder ein besseres Ergebnis bei einem einzelnen Leistungstest.