Hier finden Sie Antworten auf häufig gestellte Fragen zu SPAs, Core Web Vitals und der Pläne von Google zur Behebung aktueller Einschränkungen bei der Messung.
Seit der Einführung der Web Vitals-Initiative im Mai 2020 haben wir vom Chrome-Team viele hilfreiche Fragen und Feedback zum Programm erhalten.
Zu diesem Thema, zu dem wir die meisten Fragen erhalten haben – und wahrscheinlich auch die schwierigste Frage – ist die Messung von Core Web Vitals in einer App mit einer Seite (Single-Page Application, SPA) und wie sich SPA-Architekturen auf die Core Web Vitals-Werte auswirken.
Diese Fragen sind schwer zu beantworten, da das Problem sehr differenziert ist. In diesem Beitrag werden wir daher versuchen, die häufigsten Fragen zu beantworten und so viele Details und Kontext wie möglich bereitzustellen.
Bevor wir jedoch ins Detail gehen, möchte ich darauf hinweisen, dass Google keine Präferenz dafür hat, welche Architektur oder Technologie zum Erstellen einer Website verwendet wird. Wir sind der Meinung, dass sowohl SPAs als auch mehrseitige Anwendungen (MPAs) in der Lage sind, Nutzern eine qualitativ hochwertige Nutzererfahrung zu bieten, und wir beabsichtigen im Rahmen der WebVitals-Initiative, Messwerte bereitzustellen, die die Nutzerfreundlichkeit unabhängig von der Technologie messen. Aufgrund der Einschränkungen der Webplattform ist dies derzeit nicht in jedem Fall möglich. Wir arbeiten jedoch aktiv daran, diese Lücken zu schließen.
Häufig gestellte Fragen
Beinhaltet Core Web Vitals-Messwerte SPA-Routenübergänge?
Nein. Jeder Core Web Vitals-Messwert wird bezogen auf die aktuelle Seitennavigation auf oberster Ebene gemessen. Wenn eine Seite dynamisch neue Inhalte lädt und die URL der Seite in der Adressleiste aktualisiert, hat das keinen Einfluss darauf, wie die Core Web Vitals-Messwerte gemessen werden. Messwerte werden nicht zurückgesetzt. Außerdem ist die URL, die jeder Messwertmessung zugeordnet ist, die URL, die der Nutzer aufgerufen hat, über die der Seitenaufbau gestartet wurde.
Können SPA-Routenänderungen bei den Core Web Vitals-Messwerten genauso behandelt werden wie beim herkömmlichen Seitenaufbau?
Leider nein. Noch nicht.
Es gibt derzeit keine standardisierte Methode, eine SPA zu erstellen, und selbst unter den beliebten SPA- und Routing-Bibliotheken kann die Nutzererfahrung von App zu App sehr unterschiedlich sein:
- Einige SPAs aktualisieren die URL nur dann, wenn neue ganzseitige Inhalte geladen werden, während andere Websites die URL bei kleinen Inhaltsänderungen oder sogar nur bei Änderungen des UI-Status aktualisieren.
- Einige SPAs aktualisieren die URL mithilfe der History API, während andere Hash-Änderungen vornehmen, um ältere Browser zu unterstützen. Bei anderen wird die URL überhaupt nicht aktualisiert.
- Einige SPAs laden Inhalte und aktualisieren dann die URL, andere aktualisieren die URL, bevor die Inhalte geladen werden.
- Einige SPAs laden alle Inhalte auf einmal, synchron, in einer einzigen JavaScript-Aufgabe, während andere Inhalte asynchron über mehrere Aufgaben hinweg übertragen (ohne eindeutiges Übergangs-Endereignis).
- Einige SPAs laden immer Inhalte aus dem Netzwerk, während andere alle Inhalte vorab laden, sodass Routenänderungen sofort aus dem Speicher geladen werden.
Aufgrund dieser Unterschiede ist es sehr schwierig, eine SPA-Routenänderung oder sogar eine SPA selbst zu definieren und zu identifizieren in großem Maßstab.
In einigen Fällen ist eine Routenänderung für SPA logisch identisch mit einem MPA-Seitenaufbau. In solchen Fällen wäre es hilfreich, wenn die vorhandenen Core Web Vitals-Messwerte angewendet werden könnten.
Ohne solide Heuristik, um „echte“ Routenänderungen von allen anderen URL-Änderungen zuverlässig erkennen zu können – und auch keine eindeutigen Signale für den Beginn und das Ende solcher Umstellungen –, wären die Berichte zu Core Web Vitals-Messwerten ungenau und die Daten wären nicht mehr so hilfreich oder repräsentativ für die tatsächliche Nutzererfahrung auf der Website.
Ist es für SPAs schwieriger, bei den Core Web Vitals gute Ergebnisse zu erzielen als MPAs?
Es gibt nichts in der SPA-Architektur, das verhindert, dass eine Seite in einer SPA genauso schnell geladen wird und bei allen Core Web Vitals-Messwerten genauso schnell bewertet wird wie eine ähnliche Seite in einer MPA.
Korrekt optimierte MPAs haben jedoch einige Vorteile bei der Erfüllung der Core Web Vitals-Grenzwerte, die es derzeit bei SPAs nicht gibt. Der Grund dafür ist, dass bei der MPA-Architektur jede "Seite" als ganzseitige Navigation geladen wird, anstatt Inhalte dynamisch abzurufen und in die vorhandene Seite einzufügen. Dadurch ist es wahrscheinlicher, dass Nutzer, die eine MPA-Website besuchen, mehr als eine Seite der Website laden. Dies bedeutet wiederum, dass ein größerer Prozentsatz der Verteilung aller Seitenladevorgänge für eine MPA einige oder alle Unterressourcen umfasst.
Für eine MPA, die bei den Core Web Vitals-Messwerten eine bessere Leistung erbringt, als eine SPA, müssen einige Voraussetzungen erfüllt sein:
- Die MPA muss das Caching von Unterressourcen optimieren, damit Seiten mit demselben Ursprung tatsächlich schneller geladen werden als ursprungsübergreifende Seiten im 75. Perzentil.
- Nutzer, die MPAs besuchen, müssen mehrere Seiten aufrufen, damit die Website von den Caching-Vorteilen profitiert, die zu einem schnelleren Laden der Seiten führen.
Da bei den Core Web Vitals-Bewertungen das 75. Perzentil der Seitenaufrufe berücksichtigt wird, erhöht sich die Wahrscheinlichkeit, dass der Besuch beim 75. Perzentil der Verteilung innerhalb der empfohlenen Grenzwerte liegt, wenn mehr und leistungsstarke Seitenaufrufe im Dataset vorhanden sind.
Beachten Sie beim Vergleich der Core Web Vitals-Werte, wie die Daten aggregiert werden, d. h., ob der Datensatz in der Verteilung alle Seiten Ihrer Website oder Quelle enthält oder nur die Seitenladevorgänge einer bestimmten Seiten-URL.
Bei der Zusammenfassung der Bewertungen aller Seiten in einem Ursprung können einzelne schnelle Seiten das 75. Perzentil für den Ursprung als Ganzes verbessern. Bei der Zusammenfassung nach einzelnen Seiten wirken sich die Bewertungen einer Seite jedoch nicht auf die Bewertungen der nächsten Seite aus. Mit anderen Worten: Wenn die Bewertungen einer MPA nach Seite aggregiert werden, verbessern schnelle Cache-Ladevorgänge auf der Zahlungsseite nicht die Bewertung langsamer anfänglicher Ladevorgänge auf der Landingpage der Website.
Sie können die Punktzahl Ihrer Website für verschiedene Aggregationsmethoden mithilfe von PageSpeed Insights oder der Chrome User Experience Report API überprüfen. Diese enthält Punktzahlen für einzelne Seiten-URLs und den gesamten Ursprung.
Eine weitere Möglichkeit, wie sich die SPA-Architektur auf Core Web Vitals-Werte auswirken kann, sind Messwerte, die die gesamte Lebensdauer einer Seite berücksichtigen. Da die Besucher von SPAs in der Regel die ganze Sitzung auf derselben „Seite“ bleiben, können sich im Laufe der Zeit angesammelte Messwerte für SPAs schlechter als MPAs darstellen.
Im April 2021 haben wir Änderungen am CLS-Messwert angekündigt, durch die dieses Problem teilweise behoben wurde. Früher wurde CLS über die gesamte Seitenlebensdauer hinweg angesammelt, jetzt aber nur für ein bestimmtes Zeitfenster – im Grunde die extremste Burst von Layout Shifts auf einer bestimmten Seite.
Aber auch mit der neuen CLS-Definition sind SPAs immer noch im Nachteil, da der CLS-Wert nach einem Routenübergang nicht „zurückgesetzt“ wird, wie es beim Laden ganzer Seiten in einer MPA-Datei der Fall ist. Dies kann auch zu Verwirrung führen, da Layoutverschiebungen nach einem Routenübergang der URL der Seite beim Laden zugeordnet werden und nicht der URL in der Adressleiste zum Zeitpunkt der Verschiebung (weitere Informationen).
Wenn SPA-Architekturen die User Experience verbessern, sollte sich diese Verbesserung nicht in den Metriken widerspiegeln?
Ja, das sollte sie haben. Wie bereits erwähnt, ist es angesichts der vielen verschiedenen Möglichkeiten, wie SPAs heute im Web implementiert werden, schwierig zu quantifizieren, wie viel sich die Leistung verbessert hat.
Die Wahrheit ist, dass die Branche für die Webleistung (einschließlich Google) bisher nicht so viel Zeit und Aufwand in die Entwicklung nutzerorientierter Messwerte für die Leistung nach dem Laden einer Seite investiert hat wie für den Seitenaufbau selbst. Dies liegt nicht daran, dass die Leistung nach dem Laden nicht wichtig ist, sondern daran, dass UX und Interaktionen nach dem Laden so viel vielfältiger und weniger klar definiert sind, was es schwierig macht, Messwerte für sie zu entwerfen.
Aber selbst wenn wir die Post-Load-Messwerte genau definiert hätten, um die SPA-Leistung zu messen, sollten wir den Ladevorgang nicht ignorieren, nur weil der Vorgang nach dem Laden besser geworden ist.
Eines der Ziele der Web Vitals-Initiative besteht darin, eine gute Nutzererfahrung bei möglichst vielen Aspekten des Ladens und Verwendens einer Webseite zu fördern und zu fördern. Wir möchten keine Szenarien fördern, in denen schlechte Erfahrungen gerechtfertigt sind, wenn Sie genug positive Erfahrungen machen können, um sie auszugleichen. Nutzer möchten, dass Seiten schnell geladen und schnell zu neuen Inhalten übergehen. Wir haben versucht, Messwerte zu entwickeln, die diese Art von Inhalten besser berücksichtigen.
Es stimmt also, dass eine MPA-Version einer Website bei den Core Web Vitals-Messwerten beim 75. Perzentil besser abschneidet als eine SPA-Version derselben Website. Die SPA-Version sollte dennoch den Grenzwert für „gut“ erreichen. Wenn die SPA-Version für die meisten Nutzer nicht den Schwellenwert „gut“ erreicht, wird die anfängliche Ladezeit wahrscheinlich immer noch nicht als gut empfunden – auch wenn die nachfolgende In-Page-Navigation hervorragend ist.
Für die Zukunft planen wir, Messwerte zu entwickeln, die eine positive Nutzererfahrung nach dem Laden fördern. Wir sind der Meinung, dass dies der beste Weg ist, um qualitativ hochwertige SPAs so zu fördern, dass der anfängliche Ladevorgang nicht beeinträchtigt wird. Wir haben bereits einen neuen Messwert namens Interaction to Next Paint (INP) bereitgestellt, mit dem die Interaktionslatenz über den gesamten Seitenlebenszyklus hinweg gemessen wird. Wir arbeiten auch aktiv an anderen Messwerten nach dem Laden, einschließlich Messwerten, die SPA-Routenübergänge messen (siehe unten).
Wir haben unsere Website von einer MPA auf eine SPA umgestellt und unsere Bewertungen sind rückläufig. Ist das normal?
Das ist unterschiedlich. Es gibt eine Reihe von Gründen, warum sich Ihre Punktzahlen nach einer größeren Architekturmigration ändern können, aber eine Verringerung der Anzahl von warmen Cache-Ladevorgängen könnte für einen Teil der Änderung verantwortlich sein.
Eine schnelle Möglichkeit zur Überprüfung wäre, sowohl eine MPA- als auch eine SPA-Version einer Ihrer Landingpages mit Lighthouse zu testen. Wenn der Lighthouse-Wert für einen der Core Web Vitals-Messwerte für die SPA-Version niedriger ist, hat sich die Ladezeit nach dem Update wahrscheinlich verschlechtert.
Sollte ich meine Website von einer SPA in eine MPA umwandeln, um bei Core Web Vitals bessere Ergebnisse zu erzielen?
Nicht unbedingt. Sie sollten nur dann von einer SPA zu einer MPA wechseln, wenn Sie mit Ihrem SPA-Stack nicht zufrieden sind und Grund zur Annahme haben, dass diese eine bessere Nutzererfahrung bieten wird.
Da die Core Web Vitals-Messwerte im Laufe der Zeit immer besser werden und einen größeren Teil des gesamten Surferlebnisses abdecken, sollten Teams mit leistungsstarken SPAs, die eine hervorragende Nutzererfahrung bieten, davon ausgehen, dass ihre Core Web Vitals-Werte dies widerspiegeln.
Wie kann ich Probleme beheben, die nach einer Routenumstellung auf „Seiten“ auftreten, wenn Core Web Vitals-Werte nur für die Landingpages einer SPA erfasst werden?
Google-Tools wie Search Console und PageSpeed Insights, die Felddaten für den Core Web Vitals-Messwert angeben, beziehen ihre Daten aus dem Bericht zur Nutzererfahrung in Chrome (CrUX). In CrUX werden die Daten entweder nach dem Ursprung oder nach der Seiten-URL (die Seiten-URL zum Zeitpunkt der Ladezeit) aggregiert.
Aus allen oben aufgeführten Gründen kann CrUX keine Daten nach SPA-Route aggregieren. Als Websiteinhaber, der mit Ihrer eigenen Architektur vertraut ist, können Sie dies jedoch selbst messen. Außerdem können Sie mit vielen Analysetools signalisieren, wenn eine SPA-Routenänderung auftritt, und Ihre Messdaten entsprechend aktualisieren.
Wenn Sie Web Vitals-Messwerte mit einem Analysetool messen, müssen Sie sowohl die aktuelle Routen-URL als auch die URL der Originalseite erfassen. So lassen sich sowohl einzelne Probleme beheben, die während des gesamten Seitenlebenszyklus auftreten, als auch nach URL der ursprünglichen Seite aggregieren, damit die Messwerte in den Google-Tools gemessen und in Berichten dargestellt werden.
Weitere Informationen und Best Practices zu diesem Thema finden Sie unter Leistung der Leistung im Feld beheben.
Was unternimmt Google, um sicherzustellen, dass MPAs gegenüber SPAs keinen unfairen Vorteil haben?
Wie bereits erwähnt, kann eine ordnungsgemäß optimierte MPA in einigen Fällen bessere Web Vitals-Werte im 75. Perzentil liefern, da sie wahrscheinlich einen höheren Prozentsatz der im Cache gespeicherten Seitenaufrufe hat. Im Gegensatz dazu werden echte Verbesserungen der Nutzerfreundlichkeit bei ordnungsgemäß optimierten SPAs derzeit bei keinem der Core Web Vitals-Messwerte erfasst.
Wir bei Google sind uns bewusst, dass dadurch Anreize geschaffen werden, die nicht ganz mit den Zielen der Web Vitals-Initiative übereinstimmen, und wir suchen aktiv nach Möglichkeiten, dieses Problem zu beheben. Derzeit untersuchen wir zwei mögliche Lösungen, eine kurzfristig und eine längerfristige:
- Beurteilen Sie ursprungsübergreifende und Same-Origin-Page-Besuche separat.
- Entwerfen Sie neue APIs, die eine bessere SPA-Messung ermöglichen.
Ursprungsübergreifende und Same-Origin-Page-Besuche getrennt bewerten
Heute fassen die Core Web Vitals-Messwerte alle Seitenaufrufe in einem einzigen Bucket zusammen. Sie unterscheiden nicht zwischen neuen und wiederkehrenden Besuchen oder Landingpages von Zahlungsseiten oder anderen Aggregationstypen, bei denen sich der Cache-Status auf die Leistung auswirken könnte.
Eine Möglichkeit, die Unterschiede zwischen der SPA- und MPA-Leistung zu normalisieren, wäre, verschiedene Arten von Besuchen unterschiedlich gewichtet zu bekommen, möglicherweise sogar bei völlig unterschiedlichen Empfehlungen für Schwellenwerte.
Wir möchten auf jeden Fall effektive Cache-Implementierungen belohnen, möchten aber nicht, dass eine schnelle Website-Navigation den langsamen Ladevorgang von Landingpages überdeckt. Wir möchten auch keine Anreize dafür schaffen, lange Seiten in eine Ansammlung kurzer Seiten zu unterteilen, nur um die Messwerte zu verbessern.
Durch die separate Bewertung von ursprungsübergreifenden und Same-Origin-Seitenaufrufen können wir dafür sorgen, dass beide Arten von Erfahrungen wichtig sind, ohne dass die relative Beliebtheit eines Typs auf einer bestimmten Website die Verteilung eines bestimmten Messwerts verzerrt.
Neue APIs entwickeln, die eine bessere SPA-Messung ermöglichen
Eine weitere Lösung, an der parallel zu den obigen Ausführungen derzeit gearbeitet wird, ist eine neue App History API, mit der aktuelle SPA-Muster standardisiert werden können und die SPA-Nutzung in großem Maßstab einfacher gemessen und nachvollzogen werden kann.
Mit der App History API wird ein neues navigate-Ereignis eingeführt, das zwei wichtige Funktionen speziell für die SPA-Messung hat:
- Ein
userInitiated-Flag, das nur auf „true“ gesetzt ist, wenn die Navigation über einen Linkklick, das Senden eines Formulars oder die „Zurück“- oder „Weiter“-UI des Browsers initiiert wurde. - Eine
transitionWhile()-Methode, bei der ein Versprechen erforderlich ist, mit dem der Entwickler signalisieren kann, wann die Arbeit, die er mit der Navigation begonnen hat, abgeschlossen ist.
Mit dem Flag userInitiated kann ein semantischer Startpunkt für einen SPA-Routenübergang festgelegt werden, der auf eine klare Nutzerabsicht hinweist. Das Auflösen des transitionWhile()-Versprechens kann dem Browser dabei helfen, Paints mit der spezifischen Routenübergang in Beziehung zu setzen. So kann unter Umständen der größte Contentful Paint im Zusammenhang mit diesem Übergang ermittelt werden.
Aufbauend auf der im vorherigen Abschnitt vorgestellten Idee ist es möglicherweise sogar möglich, die Übergangszeit für SPA-Routen in denselben Bucket zu aggregieren, wenn Seiten mit demselben Ursprung in einer MPA geladen werden. Das ist besonders interessant, denn so könnte eine Website, die von einer MPA zu einer SPA migriert wird, die Leistung vorher und nachher vergleichen.
Natürlich ist weitere Forschung erforderlich, bevor wir wissen, ob wir diese Entscheidungen treffen können. Wenn du Vorschläge oder Feedback zu diesen Vorschlägen hast, sende eine E-Mail an web-vitals-feedback@googlegroups.com.
Schlussgedanken
Google ist bestrebt, die Web Vitals-Messwerte zu verbessern und dafür zu sorgen, dass Nutzer qualitativ hochwertige Inhalte messen und entsprechende Anreize dafür schaffen. Dennoch ist uns bewusst, dass es auch heute noch Lücken bei der Messung gibt. Die Messwerte decken derzeit nicht jeden Aspekt der Nutzererfahrung ab, aber wir arbeiten aktiv daran, diese Lücken zu schließen.
Trotz der aktuellen Einschränkungen sind wir der Auffassung, dass die Bereiche, die mit den vorhandenen Messwerten erfasst werden, entscheidend für den Zustand und den Erfolg des Webs sind. Wenn Websites (unabhängig von der Architektur) die empfohlenen Grenzwerte nicht erreichen, glauben wir, dass Verbesserungspotenzial besteht.
Ich hoffe, dass ich Ihnen mit diesem Beitrag etwas über dieses komplexe und differenzierte Thema erzählen konnte. Wenn Sie Feedback zu aktuellen oder zukünftigen Web Vitals-Messwerten haben, senden Sie bitte eine E-Mail an web-vitals-feedback@googlegroups.com.