Wie schneiden moderne Frameworks beim neuen INP-Messwert ab?

Hier erfahren Sie, wie sich der neue INP-Messwert auf die Nutzerfreundlichkeit von Websites auswirkt, die mit JavaScript-Frameworks und ‑Bibliotheken erstellt wurden.

Leena Sohoni
Leena Sohoni
Keen Yee Liau
Keen Yee Liau

In Chrome wurde vor Kurzem ein neuer experimenteller Messwert für die Reaktionsfähigkeit im Chrome-UX-Bericht eingeführt. Dieser Messwert, der jetzt als Interaction to Next Paint (INP) bezeichnet wird, gibt an, wie schnell die Seite insgesamt auf Nutzerinteraktionen reagiert. Heute möchten wir Ihnen zeigen, wie Websites, die mit modernen JavaScript-Frameworks erstellt wurden, in Bezug auf diesen Messwert abschneiden. Wir möchten besprechen, warum INP für Frameworks relevant ist und wie Aurora und Frameworks die Responsivität optimieren.

Hintergrund

In Chrome wird die Ladereaktionsfähigkeit von Websites mithilfe des Messwerts „First Input Delay“ (FID) als Teil der Core Web Vitals (CWV) gemessen. Der FID misst die Wartezeit zwischen der ersten Nutzerinteraktion und dem Moment, in dem der Browser die mit der Interaktion verbundenen Ereignishandler verarbeiten kann. Die Zeit für die Verarbeitung der Ereignis-Handler, die Verarbeitung nachfolgender Interaktionen auf derselben Seite oder das Zeichnen des nächsten Frames nach dem Ausführen der Ereignis-Callbacks ist nicht enthalten. Die Reaktionsfähigkeit ist jedoch während des gesamten Seitenlebenszyklus für die Nutzerfreundlichkeit entscheidend, da Nutzer etwa 90% der Zeit auf einer Seite verbringen, nachdem sie geladen wurde.

Mit INP wird die Zeit gemessen, die eine Webseite benötigt, um auf Nutzerinteraktionen zu reagieren, vom Beginn der Interaktion durch den Nutzer bis zum Zeitpunkt, an dem der nächste Frame auf dem Bildschirm angezeigt wird. Mit INP möchten wir einen zusammengefassten Messwert für die wahrgenommene Latenz aller Interaktionen im Lebenszyklus der Seite ermöglichen. Wir sind der Ansicht, dass INP eine genauere Schätzung der Ladezeit und der Reaktionsfähigkeit von Webseiten während der Laufzeit ermöglicht.

Da der FID nur die Eingabeverzögerung der ersten Interaktion misst, haben Webentwickler die nachfolgenden Interaktionen im Rahmen ihrer CWV-Optimierung wahrscheinlich nicht proaktiv optimiert. Websites, insbesondere solche mit hoher Interaktivität, müssen sich daher anstrengen, um bei diesem Messwert gut abzuschneiden.

Die Rolle von Frameworks

Da viele Websites JavaScript für die Interaktivität nutzen, wird der INP-Wert hauptsächlich von der Menge an JavaScript beeinflusst, die im Hauptthread verarbeitet wird. JavaScript-Frameworks sind ein wesentlicher Bestandteil der modernen Front-End-Webentwicklung und bieten Entwicklern wertvolle Abstraktionsebenen für das Routing, die Ereignisbehandlung und die Segmentierung von JavaScript-Code. Sie spielen daher eine zentrale Rolle bei der Optimierung der Reaktionsfähigkeit und Nutzerfreundlichkeit von Websites, auf denen sie verwendet werden.

Frameworks haben möglicherweise Maßnahmen zur Verbesserung der Reaktionsfähigkeit ergriffen, indem sie den FID für Websites bereits früher verbessert haben. Jetzt muss er jedoch die verfügbaren Daten zu den Reaktionsmesswerten analysieren und alle erkannten Lücken schließen. Im Allgemeinen haben INP-Tests in der Regel eine geringere Bestehensquote. Aufgrund der Unterschiede beim Analyseverfahren ist eine zusätzliche Codeoptimierung erforderlich. In der folgenden Tabelle sind die Gründe zusammengefasst.

FID INP
Messung Die Dauer zwischen der ersten Nutzereingabe und dem Zeitpunkt, zu dem der entsprechende Ereignishandler ausgeführt wird. Misst die Gesamtlatenz der Interaktion anhand der Verzögerung der
Abhängig von Verfügbarkeit des Hauptthreads zum Ausführen des für die erste Interaktion erforderlichen Ereignis-Handlers. Der Hauptthread könnte blockiert sein, weil er im Rahmen des ersten Seitenladevorgangs andere Ressourcen verarbeitet. Verfügbarkeit des Hauptthreads und Größe des Scripts, das von den Ereignis-Handlern für verschiedene Interaktionen ausgeführt wird, einschließlich der ersten Interaktion.
Hauptgrund für schlechte Bewertungen Ein hoher FID ist hauptsächlich auf eine intensive JavaScript-Ausführung im Hauptthread zurückzuführen. Eine umfangreiche JavaScript-Ereignisbehandlung und andere Rendering-Aufgaben nach dem Ausführen von Handlers können zu einer schlechten INP führen.
Optimierung Der FID kann durch eine Verbesserung des Ressourcenladevorgangs beim Seitenaufbau und durch die Optimierung des JavaScript-Codes optimiert werden. Ähnlich wie FID für jede Interaktion sowie Verwendung von Rendering-Mustern, bei denen wichtige UX-Änderungen gegenüber anderen Rendering-Aufgaben priorisiert werden.
FID im Vergleich zu INP: Messung und Optimierung

Das Aurora-Team in Chrome arbeitet mit Open-Source-Web-Frameworks, um Entwicklern zu helfen, verschiedene Aspekte der Nutzerfreundlichkeit zu verbessern, einschließlich Leistung und CWV-Messwerten. Mit der Einführung von INP möchten wir uns auf die Änderung der CWV-Messwerte für frameworkbasierte Websites vorbereiten. Wir haben Daten basierend auf dem experimentellen Messwert für die Reaktionsfähigkeit in CrUX-Berichten erhoben. Wir teilen Ihnen Informationen und Maßnahmen mit, die den Übergang zu diesem Messwert für frameworkbasierte Websites erleichtern.

Experimentelle Daten zum Messwert „Reaktionsschnelligkeit“

Ein INP von unter 200 Millisekunden weist auf eine gute Reaktionsfähigkeit hin. Die Daten aus dem CrUX-Bericht und dem CWV-Technologiebericht für Juni 2023 liefern uns die folgenden Informationen zur Responsivität beliebter JavaScript-Frameworks.

Technologie Prozentsatz der bestandenen Tests
% Mobilgeräte Computer
Angular (v2.0.0 und höher) 28,6 83,6
Next.js 28,5 87,3
Nuxt.js 32,0 91,2
Preact 48,6 92,8
Vue (v2.0.0 und höher) 50,3 94,1
Lit 50,0 88,3
Bericht zur CWV-Technologie – INP-Daten für Juni 2023

Die Tabelle enthält den Prozentsatz der Ursprünge in den einzelnen Frameworks mit einer guten Bewertung der Reaktionsfähigkeit. Die Zahlen sind ermutigend, aber es gibt noch viel Raum für Verbesserungen.

Wie wirkt sich JavaScript auf die INP aus?

Die INP-Werte vor Ort stimmen gut mit der im Lab beobachteten Gesamtblockierzeit überein. Das könnte bedeuten, dass jedes Script, das den Hauptthread für eine lange Zeit blockiert, schlecht für die INP ist. Eine intensive JavaScript-Ausführung nach einer Interaktion kann den Haupt-Thread für einen längeren Zeitraum blockieren und die Antwort auf diese Interaktion verzögern. Zu den häufigsten Ursachen für das Blockieren von Scripts gehören:

  • Nicht optimiertes JavaScript:Redundanter Code oder schlechte Code-Splitting- und Ladestrategien können zu einer unnötigen Größe von JavaScript führen und den Haupt-Thread für lange Zeit blockieren. Durch Code-Splitting, progressives Laden und das Aufteilen langer Aufgaben lassen sich die Antwortzeiten erheblich verbessern.

  • Drittanbieter-Scripts: Drittanbieter-Scripts, die manchmal nicht zur Verarbeitung einer Interaktion erforderlich sind (z. B. Anzeigen-Scripts), können den Haupt-Thread blockieren und unnötige Verzögerungen verursachen. Wenn Sie wichtige Scripts priorisieren, können Sie die negativen Auswirkungen von Drittanbieter-Scripts reduzieren.

  • Mehrere Ereignis-Handler:Wenn jeder Interaktion mehrere Ereignis-Handler zugewiesen sind, die jeweils ein anderes Script ausführen, kann es zu Überschneidungen kommen, die zu langen Verzögerungen führen. Einige dieser Aufgaben sind möglicherweise nicht unbedingt erforderlich und können auf einem Webworker oder dann geplant werden, wenn der Browser inaktiv ist.

  • Framework-Overhead bei der Ereignisbehandlung:Frameworks können zusätzliche Funktionen/Syntax für die Ereignisbehandlung haben. In Vue wird beispielsweise v-on verwendet, um Ereignis-Listener an Elemente anzuhängen, während Angular Nutzerereignis-Handler umschließt. Für die Implementierung dieser Funktionen ist zusätzlicher Framework-Code erforderlich.

  • Hydration: Bei der Verwendung eines JavaScript-Frameworks generiert ein Server häufig die anfängliche HTML-Datei für eine Seite, die dann mit Ereignis-Handlern und Anwendungsstatus erweitert werden muss, damit sie in einem Webbrowser interaktiv sein kann. Dieser Vorgang wird als Hydratisierung bezeichnet. Je nachdem, wie lange das Laden von JavaScript und die Hydratisierung dauern, kann dies beim Laden zu einer hohen Auslastung führen. Außerdem kann es dazu führen, dass Seiten wie interaktiv erscheinen, obwohl sie es nicht sind. Häufig erfolgt die Hydratisierung automatisch beim Laden der Seite oder verzögert (z. B. bei Nutzerinteraktionen) und kann sich auf die INP oder die Verarbeitungszeit aufgrund der Aufgabenplanung auswirken. In Bibliotheken wie React können Sie useTransition verwenden, damit ein Teil einer Komponente im nächsten Frame gerendert wird und alle kostenintensiveren Nebenwirkungen auf zukünftige Frames verschoben werden. Daher kann es für die Nutzerfreundlichkeit von Vorteil sein, wenn Updates während einer Umstellung zu dringenderen Aktualisierungen wie Klicks führen.

  • Vorab-Caching: Wenn Sie die für nachfolgende Navigationen erforderlichen Ressourcen aggressiv vorzeitig im Cache speichern, kann dies bei richtiger Anwendung zu einer Leistungssteigerung führen. Wenn Sie SPA-Routen jedoch synchron vorab laden und rendern, kann sich das negativ auf die INP auswirken, da alle diese teuren Rendering-Versuche in einem einzigen Frame abgeschlossen werden. Im Gegensatz dazu wird die Route nicht vorab abgerufen, sondern die erforderlichen Arbeiten (z. B. fetch()) werden gestartet und die Blockierung der Malerei aufgehoben. Wir empfehlen Ihnen, noch einmal zu prüfen, ob der Ansatz Ihres Frameworks für das Prefetching die optimale UX bietet und wie sich dies (falls überhaupt) auf die INP auswirken kann.

Um eine gute INP-Bewertung zu erhalten, müssen Entwickler sich künftig darauf konzentrieren, den Code zu prüfen, der nach jeder Interaktion auf der Seite ausgeführt wird. Außerdem müssen sie ihre Strategien für das Chunking, die Rehydration, das Laden und die Größe der einzelnen render()-Aktualisierungen für eigene und Drittanbieter-Scripts optimieren.

Wie gehen Aurora und Frameworks mit INP-Problemen um?

Aurora arbeitet mit Frameworks und nutzt Best Practices, um integrierte Lösungen für häufige Probleme bereitzustellen. Wir haben mit Next.js, Nuxt.js, Gatsby und Angular an Lösungen gearbeitet, die im Rahmen des Frameworks leistungsstarke Standardeinstellungen bieten. Im Folgenden finden Sie die wichtigsten Ergebnisse unserer Arbeit in diesem Zusammenhang:

  • React und Next.js:Mit der Next.js-Script-Komponente lassen sich Probleme beheben, die durch das ineffiziente Laden von Drittanbieter-Scripts verursacht werden. Detaillierte Chunking-Funktionen wurden in Next.js eingeführt, um kleinere Chunks für freigegebenen Code zu ermöglichen. So wird die Menge an nicht verwendetem gemeinsamen Code reduziert, der auf allen Seiten heruntergeladen wird. Außerdem arbeiten wir mit Next.js zusammen, um INP-Daten im Rahmen ihres Analytics-Dienstes verfügbar zu machen.

  • Angular:Aurora arbeitet mit dem Angular-Team zusammen, um Verbesserungen beim serverseitigen Rendering und bei der Hydratation zu untersuchen. Außerdem planen wir, die Ereignisverwaltung und die Änderungserkennung zu optimieren, um die INP zu verbessern.

  • Vue und Nuxt.js:Wir prüfen Möglichkeiten für die Zusammenarbeit, vor allem in Bezug auf das Laden und Rendern von Scripts.

Wie gehen Frameworks vor, um die INP zu verbessern?

React und Next.js

Mit der Zeitslicing-Funktion von React.js, die über startTransition und Suspense implementiert wird, können Sie die selektive oder progressive Bewässerung aktivieren. Das bedeutet, dass die Hydratisierung kein synchroner Block ist. Die Aufzeichnung erfolgt in kleinen Intervallen, die jederzeit unterbrochen werden können.

Dadurch sollte die Eingabeaufforderung verbessert werden und Sie können schneller auf Tastenanschläge, Hover-Effekte während der Umstellung und Klicks reagieren. Außerdem trägt es dazu bei, dass React-Apps auch bei großen Übergängen wie dem automatischen Ausfüllen reaktionsschnell bleiben.

Next.js hat ein neues Routing-Framework implementiert, das standardmäßig startTransition für Routenübergänge verwendet. So können Next.js-Websiteinhaber die Zeitslicing-Funktion von React nutzen und die Reaktionsfähigkeit von Routenübergängen verbessern.

Angular

Das Angular-Team prüft mehrere Ideen, die auch bei INP helfen sollten:

  • Zoneless:Verringert die Größe des ursprünglichen Bundles und den erforderlichen Code, der geladen werden muss, bevor eine App etwas rendern kann.
  • Begrenzung der App-Aktivität:Begrenzung der App-Aktivität, um zu verhindern, dass bei einer Interaktion ein großer Teil der App aktiviert werden muss.
  • Überhead der CD reduzieren:Sie können beispielsweise die Änderungserkennung kostengünstiger gestalten, nach Möglichkeiten suchen, weniger von der App zu prüfen, und reaktive Signale zu den Änderungen nutzen.
  • Detailliertere Codeaufteilung:Machen Sie das ursprüngliche Bundle kleiner.
  • Bessere Unterstützung für Ladesymbole: Beispielsweise beim erneuten Rendern durch serverseitiges Rendern, bei der Routennavigation und bei Lazy Loading-Vorgängen.
  • Profilierungstools:Bessere Entwicklungstools zur Analyse der Interaktionskosten, insbesondere der Kosten für die Änderungserkennung bei bestimmten Interaktionen.

Durch diese Verbesserungen können wir verschiedene Probleme beheben, die zu einer schlechten Reaktionsfähigkeit und Nutzerfreundlichkeit führen, und die CWV-Messwerte sowie den neuen INP-Messwert für frameworkbasierte Websites verbessern.

Fazit

Wir gehen davon aus, dass der INP-Wert Website-Betreibern in Zukunft dabei helfen wird, die Reaktionsfähigkeit und Leistung zu verbessern. Wir werden auf unserem vorhandenen INP-Leitfaden aufbauen, um 2023 noch mehr umsetzbare Tipps für Framework-Entwickler bereitzustellen. Wir hoffen, dies durch folgende Maßnahmen zu erreichen:

  • Erstellen von Kanälen für den einfachen Zugriff auf Felddaten in INP für Frameworks und Webentwickler.
  • Mit Frameworks Funktionen entwickeln, die die INP standardmäßig verbessern

Wir freuen uns über Feedback von Framework-Nutzern, die ihre INP-Optimierung beginnen.