Antworten auf häufig gestellte Fragen zu SPAs, Core Web Vitals und den Plänen von Google zur Behebung aktueller Messeinschränkungen.
Seit der Einführung der Web Vitals im Mai 2020 haben wir vom Chrome-Team viele tolle Fragen und Feedback zum Programm erhalten.
Das Thema, zu dem wir wohl die meisten Fragen erhalten haben und das auch am schwierigsten zu beantworten ist, ist die Messung der Core Web Vitals in einer Single-Page-Anwendung (SPA) sowie die Auswirkungen von SPA-Architekturen auf die Core Web Vitals-Werte.
Diese Fragen sind schwer zu beantworten, da das Problem sehr nuanciert ist. In diesem Beitrag versuchen wir, die häufigsten Fragen so detailliert und kontextbezogen wie möglich zu beantworten.
Bevor wir uns jedoch mit den Details befassen, ist es wichtig zu erwähnen, dass Google keine Präferenzen hinsichtlich der Architektur oder Technologie hat, die für die Erstellung einer Website verwendet wird. Wir sind der Meinung, dass sowohl SPAs als auch mehrseitige Anwendungen (Multi-Page Applications, MPAs) Nutzern eine hohe Qualität bieten können. Mit der Web Vitals-Initiative möchten wir Messwerte bereitstellen, mit denen die Nutzerfreundlichkeit unabhängig von der Technologie gemessen werden kann. Aufgrund von 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
Umfassen die Core Web Vitals-Messwerte SPA-Wechsel?
Nein. Jeder der Core Web Vitals-Messwerte wird relativ zur aktuellen Navigation auf der obersten Seite gemessen. Wenn auf einer Seite dynamisch neue Inhalte geladen und die URL der Seite in der Adressleiste aktualisiert wird, hat dies keine Auswirkungen auf die Messung der Core Web Vitals-Messwerte. Die Messwerte werden nicht zurückgesetzt. Die URL, die mit jeder Messwertmessung verknüpft ist, ist die URL, auf die der Nutzer zugegriffen hat, wodurch das Laden der Seite gestartet wurde.
Werden SPA-Routenänderungen in den Core Web Vitals-Messwerten genauso behandelt wie herkömmliche Seitenladevorgänge?
Leider nicht. Zumindest noch nicht.
Es gibt derzeit keine standardisierte Methode zum Erstellen einer SPA. Selbst bei den beliebten SPA- und Routing-Bibliotheken kann die Nutzererfahrung von App zu App sehr unterschiedlich sein:
- Einige SPAs aktualisieren die URL nur beim Laden neuer „Vollseiteninhalte“, während andere Websites die URL bei kleinen Inhaltsänderungen oder sogar nur bei Änderungen des UI-Status aktualisieren.
- Einige SPAs aktualisieren die URL mit der History API, während andere Hash-Änderungen verwenden, um ältere Browser zu unterstützen. Wieder andere aktualisieren die URL gar nicht.
- Bei einigen SPAs werden Inhalte geladen und dann die URL aktualisiert, bei anderen wird die URL aktualisiert, bevor Inhalte geladen werden.
- Bei einigen SPAs werden Inhalte synchron in einem einzigen JavaScript-Task auf einmal geladen, während bei anderen Inhalte asynchron über mehrere Tasks hinweg übertragen werden (ohne klares Ereignis zum Ende der Übertragung).
- Einige SPAs laden Inhalte immer aus dem Netzwerk, während andere alle Inhalte vorab laden, damit Routenänderungen sofort aus dem Arbeitsspeicher geladen werden.
Aufgrund dieser Unterschiede ist es in großem Umfang sehr schwierig, zu definieren und zu erkennen, was eine SPA-Routenänderung oder sogar eine SPA selbst ausmacht.
In einigen Fällen ist eine SPA-Routenänderung logisch mit dem Laden einer MPA-Seite identisch. In solchen Fällen wäre es hilfreich, wenn die vorhandenen Core Web Vitals-Messwerte angewendet werden könnten.
Ohne solide Heuristiken, um „echte“ Routenänderungen von allen anderen URL-Änderungen zuverlässig zu unterscheiden, sowie klare Signale, die den Beginn und das Ende solcher Übergänge kennzeichnen, würden die Core Web Vitals-Messwerte in diesen Fällen die Daten unübersichtlich machen und sie weniger nützlich oder repräsentativ für die tatsächliche Nutzererfahrung auf der Website erscheinen lassen.
Ist es für SPAs schwieriger, gute Core Web Vitals-Werte zu erzielen als für MPAs?
Die SPA-Architektur verhindert nicht, dass eine Seite in einer SPA genauso schnell geladen wird und bei allen Core Web Vitals-Messwerten genauso gut abschneidet wie eine ähnliche Seite in einer MPA.
Richtig optimierte MPAs haben jedoch einige Vorteile bei der Einhaltung der Grenzwerte für Core Web Vitals, die SPAs derzeit nicht haben. Das liegt daran, dass bei der MPA-Architektur jede „Seite“ als vollständige Navigation geladen wird, anstatt Inhalte dynamisch abzurufen und in die vorhandene Seite einzufügen. Das bedeutet, dass Nutzer, die eine MPA besuchen, mit größerer Wahrscheinlichkeit mehr als eine Seite von der Website laden. Das wiederum bedeutet, dass bei einem größeren Prozentsatz der Verteilung aller Seitenladevorgänge für eine MPA einige oder alle untergeordneten Ressourcen im Cache gespeichert werden.
Damit eine MPA bei den Core Web Vitals-Messwerten besser abschneidet als eine SPA, müssen einige Voraussetzungen erfüllt sein:
- Die MPA muss das Caching von untergeordneten Ressourcen optimieren, damit Seitenladezeiten innerhalb desselben Ursprungs tatsächlich schneller sind als Seitenladezeiten mit unterschiedlichen Ursprüngen im 75. Perzentil.
- Nutzer, die MPAs besuchen, müssen mehrere Seiten aufrufen, damit die Website die Vorteile des Cachings nutzen kann, was zu einem schnelleren Seitenaufbau führt.
Da bei der Bewertung der Core Web Vitals der 75. Perzentilwert der Seitenaufrufe berücksichtigt wird, steigt die Wahrscheinlichkeit, dass der Besuch im 75. Perzentil der Verteilung innerhalb der empfohlenen Grenzwerte liegt, wenn der Datensatz mehr leistungsstarke Seitenaufrufe enthält.
Beim Vergleichen der Core Web Vitals-Werte ist es wichtig, zu berücksichtigen, wie die Daten zusammengefasst werden. Das heißt, ob der Datensatz in der Verteilung alle Seiten Ihrer Website oder Quelle oder nur Seitenladevorgänge für eine bestimmte Seiten-URL enthält.
Wenn die Bewertungen aller Seiten eines Ursprungs zusammengefasst werden, können einzelne schnelle Seiten den 75. Perzentilwert für den Ursprung insgesamt verbessern. Bei der Zusammenfassung nach einzelnen Seiten wirken sich die Bewertungen einer Seite jedoch nicht auf die Bewertungen der nächsten aus. Mit anderen Worten: Wenn die Bewertungen einer MPA nach Seiten zusammengefasst werden, verbessern schnelle Cache-Ladezeiten auf der Zahlungsseite nicht die Bewertungen der langsamen ersten Ladezeiten auf der Landingpage der Website.
Sie können den Wert Ihrer Website für verschiedene Aggregationsmethoden mit PageSpeed Insights oder der Chrome User Experience Report API prüfen. Diese API liefert Bewertungen sowohl für einzelne Seiten-URLs als auch für den gesamten Ursprung.
Eine weitere Möglichkeit, wie sich die SPA-Architektur auf die Core Web Vitals-Werte auswirken kann, sind Messwerte, bei denen die gesamte Lebensdauer einer Seite berücksichtigt wird. Da Nutzer, die SPAs besuchen, während der gesamten Sitzung in der Regel auf derselben „Seite“ bleiben, können sich Messwerte, die sich im Laufe der Zeit summieren, bei SPAs stärker auswirken als bei MPAs.
Im April 2021 haben wir Änderungen am CLS-Messwert angekündigt, mit denen dieses Problem teilweise behoben wurde. Bisher wurde der CLS über die gesamte Lebensdauer der Seite erfasst. Jetzt wird er nur über einen bestimmten Zeitraum erfasst, also im Wesentlichen der schlimmste Ausschlag von Layoutverschiebungen auf einer bestimmten Seite.
Selbst mit der neuen CLS-Definition sind SPAs jedoch nach wie vor im Nachteil, da der CLS-Wert nach einer Routenüberleitung nicht zurückgesetzt wird, wie es bei vollständigen Seitenladevorgängen in einer MPA der Fall ist. Das kann auch zu Verwirrung führen, da Layoutänderungen, die nach einem Routenübergang auftreten, der URL der Seite zugewiesen werden, als sie geladen wurde, nicht der URL in der Adressleiste zum Zeitpunkt der Änderung (weitere Informationen finden Sie unten).
Wenn SPA-Architekturen die Nutzerfreundlichkeit verbessern, sollte sich diese Verbesserung in den Messwerten widerspiegeln.
Ja, das sollte der Fall sein. Wie bereits erwähnt, ist es jedoch aufgrund der vielen verschiedenen Möglichkeiten, wie SPAs heute im Web implementiert werden, schwierig, in großem Umfang zu quantifizieren, inwiefern sich die Nutzerfreundlichkeit verbessert hat.
Die Wahrheit ist, dass die Web-Leistungsbranche (einschließlich Google) in der Vergangenheit nicht annähernd so viel Zeit und Mühe in die Entwicklung nutzerorientierter Messwerte für die Leistung einer Seite nach dem Laden investiert hat wie in das Laden der Seite selbst. Das liegt nicht daran, dass die Leistung nach dem Laden nicht wichtig ist, sondern daran, dass die UX und Interaktionen nach dem Laden viel vielfältiger und weniger klar definiert sind, was es schwierig macht, Messwerte dafür zu entwickeln.
Selbst wenn wir gut definierte Messwerte nach dem Laden hätten, um die SPA-Leistung zu messen, würden wir die Ladezeit nicht ignorieren, nur weil die Leistung nach dem Laden besser wurde.
Eines der Ziele der Web Vitals-Initiative besteht darin, die Nutzerfreundlichkeit bei möglichst vielen Aspekten des Ladens und der Nutzung einer Webseite zu fördern und zu belohnen. Wir möchten nicht, dass schlechte Erfahrungen gerechtfertigt werden, wenn es genügend gute Erfahrungen gibt, die sie ausgleichen. Nutzer möchten, dass Seiten schnell geladen und Inhalte schnell angezeigt werden. Wir haben versucht, Messwerte zu entwickeln, die diese Anforderungen erfüllen.
Es stimmt zwar, dass eine MPA-Version einer Website im 75. Perzentil der Core Web Vitals-Messwerte besser abschneiden kann als eine SPA-Version derselben Website. Die SPA-Version sollte jedoch trotzdem den Grenzwert „Gut“ erreichen. Wenn die SPA-Version für die meisten Nutzer nicht den Grenzwert „gut“ erreicht, wird der anfängliche Ladevorgang wahrscheinlich immer noch nicht als gut wahrgenommen – auch wenn die nachfolgende Navigation auf der Seite hervorragend ist.
In Zukunft planen wir, Messwerte zu entwickeln, die eine gute Nutzererfahrung nach dem Laden fördern. Wir sind der Meinung, dass dies der beste Weg ist, Anreize für hochwertige SPAs zu schaffen, ohne die Leistung beim ersten Laden zu beeinträchtigen. Wir haben bereits einen neuen Messwert namens Interaction to Next Paint (INP) eingeführt, mit dem die Interaktionslatenz während des gesamten Seitenlebenszyklus gemessen wird. Wir arbeiten auch aktiv an anderen Messwerten nach dem Laden, einschließlich Messwerten, mit denen SPA-Wechsel gemessen werden (siehe unten).
Wir haben unsere Website von einer MPA zu einer SPA umgestellt und unsere Bewertungen sind gesunken. Ist das normal?
Das ist unterschiedlich. Es gibt eine Reihe von Gründen, warum sich Ihre Bewertungen nach einer größeren Architekturmigration ändern könnten. Ein Rückgang der Anzahl der warmen Cache-Ladevorgänge könnte jedoch zu einem Teil der Änderung beitragen.
Eine schnelle Möglichkeit zur Überprüfung besteht darin, 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 der Aktualisierung wahrscheinlich verschlechtert.
Sollte ich meine Website von einer SPA zu einer MPA wechseln, um bei den Core Web Vitals bessere Werte zu erzielen?
Wahrscheinlich nicht. 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 eine MPA eine bessere Nutzererfahrung bietet.
Im Laufe der Zeit, wenn sich die Core Web Vitals-Messwerte verbessern und einen größeren Teil der gesamten Browsernutzung abdecken, sollten Teams mit gut entwickelten SPAs, die eine hervorragende UX bieten, davon ausgehen, dass sich dies in ihren Core Web Vitals-Werten widerspiegelt.
Wenn Core Web Vitals-Werte nur für die Landingpages einer SPA erfasst werden, wie kann ich Probleme beheben, die auf „Seiten“ nach einer Routenüberleitung auftreten?
Google-Tools, die Felddaten für den Core Web Vitals-Messwert erfassen (z. B. die Search Console und PageSpeed Insights), beziehen ihre Daten aus dem Chrome User Experience Report (CrUX). In CrUX werden Daten entweder nach Ursprung oder nach Seiten-URL (d. h. der Seiten-URL zum Zeitpunkt des Ladens) zusammengefasst.
Aus den oben genannten Gründen können in CrUX keine Daten nach SPA-Route zusammengefasst werden. Als Websiteinhaber, der mit seiner eigenen Architektur vertraut ist, können Sie dies jedoch selbst messen. Viele Analysetools ermöglichen es Ihnen, eine SPA-Wechselroute zu signalisieren und Ihre Messdaten entsprechend zu aktualisieren.
Wenn Sie Web Vitals-Messwerte mit einem Analysetool erfassen, sollten Sie sowohl die aktuelle Routen-URL als auch die URL der ursprünglichen Seite messen. So können Sie sowohl einzelne Probleme beheben, die während des gesamten Lebenszyklus der Seite auftreten, als auch nach der ursprünglichen Seiten-URL aggregieren, um die Messwerte so zu erfassen, wie sie in den Google-Tools erfasst und in Berichten dargestellt werden.
Weitere Informationen und Best Practices zu diesem Thema finden Sie unter Leistung vor Ort analysieren.
Was unternimmt Google, um sicherzustellen, dass MPAs keinen unfairen Vorteil gegenüber SPAs haben?
Wie bereits erwähnt, kann eine richtig optimierte MPA in einigen Fällen bessere Web Vitals-Werte im 75. Perzentil liefern, da sie wahrscheinlich einen höheren Prozentsatz an Seitenbesuchen aus dem Cache hat. Umgekehrt werden echte Verbesserungen der Nutzerfreundlichkeit in richtig optimierten SPAs derzeit von keinem der Core Web Vitals-Messwerte erfasst.
Wir bei Google sind uns bewusst, dass dies Anreize schafft, die nicht vollständig mit den Zielen der Web Vitals-Initiative übereinstimmen. Wir suchen aktiv nach Möglichkeiten, dies zu beheben. Wir prüfen derzeit zwei mögliche Lösungen, eine kurzfristige und eine langfristige:
- Bewerten Sie Seitenbesuche mit und ohne Ursprungsübergang separat.
- Neue APIs entwickeln, die eine bessere SPA-Analyse ermöglichen
Seitenaufrufe mit unterschiedlichem und gleichem Ursprung getrennt bewerten
Derzeit werden alle Seitenaufrufe in den Core Web Vitals-Messwerten in einem einzigen Bucket zusammengefasst. Es wird nicht zwischen neuen und wiederkehrenden Besuchen, Landingpages und Zahlungsseiten oder anderen Aggregationstypen unterschieden, bei denen der Cache-Status sich auf die Leistung auswirken könnte.
Eine Möglichkeit, die Unterschiede zwischen der Leistung von SPAs und MPAs zu normalisieren, besteht darin, verschiedene Arten von Besuchen unterschiedlich zu gewichten, möglicherweise sogar mit völlig unterschiedlichen Empfehlungen für Grenzwerte.
Wir möchten effektive Cache-Implementierungen zwar belohnen, aber nicht, dass eine schnelle Navigation innerhalb der Website eine langsame Ladezeit der Landingpage verdecken kann. Außerdem möchten wir nicht dazu anregen, lange Seiten nur zum Zweck der Verbesserung der Messwerte in mehrere kürzere Seiten aufzuteilen.
Durch die separate Bewertung von Seitenaufrufen mit und ohne Website-Ursprung können wir dafür sorgen, dass beide Arten von Zugriffen 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-Analyse ermöglichen
Eine weitere Lösung, an der parallel zu den oben genannten Maßnahmen aktiv gearbeitet wird, ist die App History API. Sie soll dazu beitragen, aktuelle SPA-Muster zu standardisieren und die SPA-Nutzung im großen Maßstab zu messen und zu verstehen.
Die App History API führt ein neues Ereignis navigate ein, das zwei wichtige Funktionen speziell für die SPA-Analyse bietet:
- Ein
userInitiated-Flag, das nur dann auf „wahr“ gesetzt wird, wenn die Navigation über einen Linkklick, die Formulareinreichung oder die Schaltfläche „Zurück“ oder „Weiter“ des Browsers gestartet wurde. - Eine
transitionWhile()-Methode, die ein Versprechen annimmt, mit dem der Entwickler signalisieren kann, dass die von ihm initiierte Navigation abgeschlossen ist.
Mit dem Flag userInitiated kann ein semantischer Ausgangspunkt für eine SPA-Routenüberleitung festgelegt werden, der eine eindeutige Nutzerabsicht angibt. Die transitionWhile()-Versprechensauflösung kann dem Browser helfen, Paints mit dem jeweiligen Routenübergang zu korrelieren, sodass er möglicherweise die größte LCP im Zusammenhang mit diesem Übergang ermitteln kann.
Aufbauend auf der im vorherigen Abschnitt vorgestellten Idee kann es sogar möglich sein, die SPA-Wechselzeit in denselben Bucket wie das Laden von Seiten mit demselben Ursprung in einer MPA zusammenzufassen. Das ist sehr interessant, da es bei der Migration einer Website von einer MPA zu einer SPA möglich wäre, die Leistung vor und nach der Migration zu vergleichen.
Natürlich sind noch weitere Studien erforderlich, bevor wir wissen, ob wir diese Aussagen mit Sicherheit treffen können. Wenn Sie Vorschläge oder Feedback zu diesen Vorschlägen haben, senden Sie 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 damit die Qualität der Nutzererfahrung gemessen und gefördert wird, die für Nutzer wichtig ist. Wir sind uns jedoch bewusst, dass es derzeit Lücken bei der Messung gibt. Die Messwerte decken derzeit nicht alle Aspekte der Nutzerfreundlichkeit ab. Wir arbeiten jedoch aktiv daran, diese Lücken zu schließen.
Trotz der aktuellen Einschränkungen sind wir der Meinung, dass die Bereiche, die die vorhandenen Messwerte abdecken, für die Gesundheit und den Erfolg des Webs entscheidend sind. Wenn Websites (unabhängig von der Architektur) die empfohlenen Grenzwerte nicht einhalten, besteht unserer Meinung nach Verbesserungspotenzial.
Ich hoffe, dass dieser Beitrag etwas Licht in dieses komplexe und vielschichtige Thema gebracht hat. Wenn Sie Feedback zu den aktuellen oder zukünftigen Web Vitals-Messwerten haben, senden Sie uns einfach eine E-Mail an web-vitals-feedback@googlegroups.com.