Wie schneiden moderne Frameworks beim neuen INP-Messwert ab?

Hier erfährst du, wie sich der neue INP-Messwert auf Websites auswirkt, die mit JavaScript-Frameworks und -Bibliotheken erstellt wurden.

Leena Sohoni
Leena Sohoni
Addy Osmani
Addy Osmani
Keen Yee Liau
Keen Yee Liau

Chrome hat vor Kurzem im Bericht UX-Bericht für Chrome einen neuen Test für die Reaktionsfähigkeit eingeführt. Mit diesem Messwert, den wir jetzt als Interaction to Next Paint (INP) bezeichnen, wird die allgemeine Reaktionsfähigkeit auf Nutzerinteraktionen auf der Seite gemessen. Heute möchten wir Ihnen zeigen, wie Websites, die mit modernen JavaScript-Frameworks erstellt wurden, in Bezug auf diesen Messwert stehen. Wir möchten besprechen, warum INP für Frameworks relevant ist und wie Aurora und Frameworks daran arbeiten, die Reaktionszeit zu optimieren.

Hintergrund

Chrome verwendet First Input Delay (FID) als Teil des Core Web Vitals (CWV), um die Reaktionsgeschwindigkeit von Websites zu messen. FID gibt die Wartezeit von der ersten Nutzerinteraktion bis zu dem Moment an, in dem der Browser die mit der Interaktion verbundenen Event-Handler verarbeiten kann. Dies beinhaltet nicht die Zeit, die für die Verarbeitung der Event-Handler, die Verarbeitung nachfolgender Interaktionen auf derselben Seite oder die Darstellung des nächsten Frames nach der Ausführung der Ereignis-Callbacks benötigt wird. Diese Reaktionszeit ist jedoch von entscheidender Bedeutung für die Nutzererfahrung während des gesamten Lebenszyklus einer Seite, da sie etwa 90% der Zeit auf einer Seite verbringen, nachdem diese geladen wurde.

Mit INP wird die Zeit gemessen, die eine Webseite benötigt, um auf Nutzerinteraktionen zu reagieren, vom Beginn der Interaktion bis zu dem Moment, in dem der nächste Frame auf dem Bildschirm angezeigt wird. Mit INP hoffen wir, eine zusammengefasste Messung der wahrgenommenen Latenz aller Interaktionen im Lebenszyklus einer Seite zu ermöglichen. Wir sind der Meinung, dass INP eine genauere Schätzung der Ladezeit von Webseiten und der Reaktionszeit der Laufzeit liefert.

Da mit FID nur die Eingabeverzögerung der ersten Interaktion gemessen wird, haben Webentwickler die nachfolgenden Interaktionen wahrscheinlich nicht proaktiv im Rahmen des CWV-Verbesserungsprozesses optimiert. Bei Websites, die ein hohes Maß an Interaktivität aufweisen, müssten daher erste Schritte unternommen werden, um diesen Messwert gut zu nutzen.

Die Rolle von Frameworks

Da viele Websites für die Interaktivität auf JavaScript angewiesen sind, wird die INP-Bewertung hauptsächlich von der Menge des im Hauptthread verarbeiteten JavaScript-Codes beeinflusst. JavaScript-Frameworks sind ein wesentlicher Bestandteil der modernen Frontend-Webentwicklung und bieten Entwicklern wertvolle Abstraktionen für das Routing, die Ereignisverarbeitung und die Aufteilung von JavaScript-Code. Daher spielen sie eine zentrale Rolle bei der Optimierung der Reaktionsschnelligkeit und der User Experience von Websites, auf denen sie verwendet werden.

Eventuell wurden durch Frameworks schon früher Maßnahmen zur Verbesserung der Reaktionsgeschwindigkeit durch die Verbesserung des FID-Werts für Websites ergriffen. Jetzt müsste es jedoch die verfügbaren Messwerte zur Reaktionszeit analysieren und darauf hinarbeiten, die gefundenen Lücken zu schließen. Im Allgemeinen weist INP in der Regel niedrigere Erfolgsraten auf und der Unterschied im Messprozess erfordert eine zusätzliche Codeoptimierung. Die folgende Tabelle fasst die Gründe dafür zusammen.

FID INP
Messwerte ermitteln Misst die Dauer zwischen der ersten Nutzereingabe und der Zeit, zu der der entsprechende Event-Handler ausgeführt wird. Misst die Gesamtinteraktionslatenz mithilfe der Verzögerung des
Abhängig von Verfügbarkeit des Hauptthreads zum Ausführen des für die erste Interaktion erforderlichen Event-Handlers. Der Hauptthread könnte blockiert werden, da er beim ersten Seitenaufbau andere Ressourcen verarbeitet. Verfügbarkeit des Hauptthreads und Größe des Skripts, das von den Event-Handlern für verschiedene Interaktionen ausgeführt wird, einschließlich der ersten Interaktion.
Hauptursache für schlechte Bewertungen Ein schlechter FID-Wert wird hauptsächlich durch eine hohe JavaScript-Ausführung im Hauptthread verursacht. Komplexe JavaScript- und andere Rendering-Aufgaben zur Verarbeitung von Ereignissen können nach dem Ausführen von Handlern zu einer schwachen INP führen.
Optimierung Sie können FID optimieren, indem Sie das Laden von Ressourcen beim Seitenaufbau verbessern und den JavaScript-Code optimieren. Ähnlich wie FID für jede Interaktion, plus die Verwendung von Renderingmustern, bei denen wichtige UX-Aktualisierungen gegenüber anderen Renderingaufgaben priorisiert werden.
FID versus INP: Messung und Optimierung

Das Aurora-Team in Chrome verwendet Open-Source-Web-Frameworks, um Entwicklern zu helfen, verschiedene Aspekte der Nutzererfahrung zu verbessern, einschließlich Leistungs- und CWV-Messwerte. Mit der Einführung von INP möchten wir auf die sich ändernden CWV-Messwerte für Framework-basierte Websites vorbereitet sein. Wir haben Daten basierend auf dem experimentellen Messwert für die Reaktionsfähigkeit in CrUX-Berichten erfasst. Wir teilen Ihnen die Erkenntnisse und umzusetzenden Maßnahmen mit, um die Umstellung auf den INP-Messwert für Framework-basierte Websites zu erleichtern.

Experimentelle Messwertdaten zur Reaktionszeit

Ein INP unter oder gleich 200 Millisekunden weist auf eine gute Reaktionsfähigkeit hin. Die Daten aus dem Bericht zur Nutzererfahrung in Chrome und der CWV-Technologiebericht für Juni 2023 enthalten folgende Informationen zur Reaktionszeit für gängige JavaScript-Frameworks.

Technologie Bestanden in %
Anteil der Mobilgeräte (%) Computer
Angular (Version 2.0.0 und höher) 28,6 83,6
Next.js 28,5 87,3
Nuxt.js 32 91,2
Vorbereiten 48,6 92,8
Vue (Version 2.0.0 und höher) 50,3 94,1
Lit 50,0 88,3
CWV-Technologiebericht – INP-Daten für Juni 2023

Die Tabelle zeigt den Prozentsatz der Ursprünge für jedes Framework mit einem guten Reaktionsgrad. Die Zahlen sind ermutigend, aber zeigen, dass es viel Raum für Verbesserungen gibt.

Wie wirkt sich JavaScript auf INP aus?

Die INP-Werte im Feld korrelieren gut mit der im Lab beobachteten Total Blocking Time (TBT). Dies könnte implizieren, dass jedes Skript, das den Hauptthread über einen längeren Zeitraum blockiert, schlecht für INP ist. Eine umfangreiche JavaScript-Ausführung nach einer Interaktion könnte den Hauptthread über einen längeren Zeitraum blockieren und die Antwort auf diese Interaktion verzögern. Hier einige der häufigsten Ursachen für das Blockieren von Skripts:

  • Nicht optimiertes JavaScript:Redundanter Code oder schlechte Strategien zum Aufteilen und Laden von Code können zu JavaScript-Bloat führen und den Hauptthread für längere Zeit blockieren. Das Aufteilen von Code, das progressive Laden und die Aufteilung langer Aufgaben können die Reaktionszeiten erheblich verkürzen.

  • Drittanbieter-Skripts:Drittanbieter-Skripts, die manchmal nicht zur Verarbeitung einer Interaktion erforderlich sind (z. B. Anzeigenskripts), können den Hauptthread blockieren und unnötige Verzögerungen verursachen. Die Priorisierung wichtiger Skripts kann dazu beitragen, die negativen Auswirkungen von Drittanbieter-Skripts zu reduzieren.

  • Mehrere Event-Handler:Mehrere Event-Handler, die jeder Interaktion zugeordnet sind und von denen jeder ein anderes Skript ausführt, können sich gegenseitig beeinträchtigen und zu langen Verzögerungen führen. Einige dieser Aufgaben sind möglicherweise nicht unbedingt erforderlich und können für einen Web Worker oder im inaktiven Browser geplant werden.

  • Framework-Overhead für die Ereignisverarbeitung:Frameworks können zusätzliche Funktionen und Syntax für die Ereignisverarbeitung haben. Vue verwendet beispielsweise v-on, um Ereignis-Listener an Elemente anzuhängen, während Angular Nutzer-Event-Handler umschließt. Die Implementierung dieser Funktionen erfordert zusätzlichen Framework-Code über einfachem JavaScript.

  • Flüssigkeitszufuhr:Bei der Verwendung eines JavaScript-Frameworks ist es nicht ungewöhnlich, dass ein Server den anfänglichen HTML-Code für eine Seite generiert, der dann mit Event-Handlern und dem Anwendungsstatus erweitert werden muss, damit er in einem Webbrowser interaktiv sein kann. Diesen Prozess nennen wir Hydration. Je nachdem, wie lange das Laden von JavaScript und die Hydration dauern, kann dies ein aufwendiger Prozess sein. Ansonsten wirken sie unter Umständen auch interaktiv. Die Hydration erfolgt häufig automatisch beim Seitenaufbau oder verzögert (z. B. bei der Nutzerinteraktion) und kann sich aufgrund der Aufgabenplanung auf die INP- oder Verarbeitungszeit auswirken. In Bibliotheken wie React kannst du useTransition nutzen, damit sich ein Teil der Komponente im nächsten Frame befindet und etwaige kostspielige Nebeneffekte auf zukünftige Frames übertragen werden. Daher können Aktualisierungen während der Umstellung, die zu dringenderen Aktualisierungen wie Klicks führen, ein Muster sein, das für INP gut sein kann.

  • Prefetching:Ein aggressiver Vorabruf der Ressourcen, die für nachfolgende Navigationen erforderlich sind, kann zu einem Leistungsgewinn führen, wenn er richtig umgesetzt wird. Wenn Sie SPA-Routen jedoch synchron im Voraus abrufen und rendern, kann sich dies negativ auf INP auswirken, da alle diese teuren Rendering-Versuche in einem einzigen Frame abgeschlossen werden. Im Gegensatz dazu wird die Route nicht vorab abgerufen, sondern stattdessen die erforderliche Arbeit gestartet (z. B. fetch()) und die Blockierung der Farbe aufgehoben. Wir empfehlen, zu überprüfen, ob der Ansatz Ihres Frameworks für den Vorabruf die optimale UX bietet und wie sich dies (wenn überhaupt) auf INP auswirken kann.

Um einen guten INP-Score zu erhalten, müssen sich Entwickler von nun an darauf konzentrieren, den Code zu überprüfen, der nach jeder Interaktion auf der Seite ausgeführt wird, und die Aufteilung, Rehydrierung, Ladestrategien sowie die Größe der einzelnen render()-Updates sowohl für eigene als auch für Drittanbieter-Skripts zu optimieren.

Wie gehen Aurora und Frameworks gegen INP-Probleme an?

Aurora nutzt Frameworks und Best Practices, um integrierte Lösungen für häufige Probleme zu bieten. Wir haben mit Next.js, Nuxt.js, Gatsby und Angular an Lösungen gearbeitet, die starke Standardstandards im Framework zur Leistungsoptimierung bieten. Im Folgenden haben wir die Highlights unserer Arbeit in diesem Zusammenhang zusammengefasst:

  • React und Next.js:Mit der Next.js-Skriptkomponente lassen sich Probleme beheben, die durch ineffizientes Laden von Drittanbieter-Skripts verursacht werden. In Next.js wurde detailliertes Chunking eingeführt, um kleinere Blöcke für gemeinsam genutzten Code zu ermöglichen. So wird die Menge an nicht verwendetem, gängigem Code reduziert, der auf allen Seiten heruntergeladen wird. Außerdem arbeiten wir derzeit mit Next.js zusammen, um INP-Daten im Rahmen des Analytics-Dienstes verfügbar zu machen.

  • Angular:Aurora arbeitet mit dem Angular-Team zusammen, um das serverseitige Rendering und die Hydratisierung zu verbessern. Außerdem planen wir, Optimierungen bei der Ereignisverarbeitung und bei der Änderungserkennung zu untersuchen, um INP zu verbessern.

  • Vue und Nuxt.js:Wir suchen nach Möglichkeiten der Zusammenarbeit, hauptsächlich im Hinblick auf das Laden und Rendern von Skripts.

Wie denken Frameworks über die Verbesserung von INP nach?

React und Next.js

Die Zeitaufteilung von React.js, die über startTransition und Suspense implementiert wird, ermöglicht die Aktivierung der selektiven oder progressiven Hydration. Das bedeutet, dass die Flüssigkeitszufuhr kein synchroner Block ist. Das geschieht in kleinen Abschnitten, die jederzeit unterbrochen werden können.

Dies sollte die INP verbessern und es Ihnen ermöglichen, schneller auf Tastaturanschläge, Hover-Effekte während der Umstellung und Klicks zu reagieren. Außerdem bleiben React-Apps so auch bei großen Übergängen wie der automatischen Vervollständigung reaktionsschnell.

Next.js hat ein neues Routing-Framework implementiert, das standardmäßig startTransition für Routenumstellungen verwendet. So können Websiteinhaber*innen mit Next.js die Zeitaufteilung von React anwenden und die Reaktionszeit bei Routenübergängen verbessern.

Angular

Das Angular-Team untersucht mehrere Ideen, die auch bei INP hilfreich sein sollten:

  • Zonenlos: Verringert die anfängliche Bundle-Größe und den erforderlichen Code, der geladen werden muss, bevor eine App etwas rendern kann.
  • Flüssigkeitszufuhr:Bei der Flüssigkeitszufuhr ist der Anteil der App eingeschränkt, der für die Interaktion aufgeweckt werden muss.
  • Weniger Aufwand für CD: Reduzieren Sie beispielsweise die Kosten für die Änderungserkennung, suchen Sie nach Möglichkeiten, weniger von einer App zu überprüfen, und nutzen Sie reaktive Signale über Änderungen.
  • Detailliertere Codeaufteilung: Verkleinern Sie das erste Bundle.
  • Bessere Unterstützung für Ladeanzeigen: beispielsweise beim Re-Rendering der SSR, bei der Routennavigation und bei Lazy Loading.
  • Profilerstellungstools:Bessere Entwicklertools, um die Interaktionskosten nachzuvollziehen, insbesondere im Hinblick auf die Kosten für die Änderungserkennung bei bestimmten Interaktionen.

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

Fazit

Wir gehen davon aus, dass die INP-Bewertung als Vergleichspunkt für Websites dienen wird, um ihre Reaktionsfähigkeit und Leistung in Zukunft zu verbessern. 2023 bauen wir auf unserem vorhandenen INP-Leitfaden auf und bieten Framework-Entwicklern noch mehr praktische Tipps. Wir hoffen, dies durch folgende Maßnahmen erreichen zu können:

  • Erstellung von Kanälen für den einfachen Zugriff auf Felddaten auf INP für Frameworks und Webentwickler
  • Arbeiten Sie mit Frameworks, um Funktionen zu erstellen, die INP standardmäßig verbessern.

Wir freuen uns über Feedback von Framework-Nutzern zu Beginn der INP-Optimierung.