Antworten auf häufig gestellte Fragen zu SPAs, zu Core Web Vitals und zum Plan von Google zur Beseitigung der aktuellen Einschränkungen bei der Messung
Seit Einführung der Web Vitals-Initiative im Mai 2020 im Chrome-Team haben viele interessante Fragen und Feedback zur .
Vielleicht das Thema, zu dem wir die meisten Fragen erhalten haben, zu dem auch ist die Messung von Core Web Vitals App mit nur einer Seite und die Auswirkungen von SPA-Architekturen auf die Core Web Vitals-Werte.
Diese Fragen sind schwer zu beantworten, da das Problem sehr differenziert ist. In diesem Post beantworten wir die am häufigsten gestellten Fragen, mit so vielen Details und Kontext wie möglich.
Bevor wir jedoch auf die Einzelheiten eingehen, ist es wichtig zu erwähnen, dass Google welche Architektur oder Technologie zum Aufbau eines Website. Sowohl SPAs als auch Multi-Page-Anwendungen (MPAs) den Nutzern qualitativ hochwertige Nutzererfahrungen zu bieten, und unsere Absichten mit dem Web Im Rahmen der Vitals-Initiative werden Messwerte bereitgestellt, die die Nutzererfahrung unabhängig davon messen. der Technologie. Obwohl dies heute nicht in jedem Fall möglich ist, Einschränkungen in der Webplattform), arbeiten wir aktiv daran, diese Lücken.
Häufig gestellte Fragen
Enthalten die Core Web Vitals-Messwerte auch Übergänge von SPA-Routen?
Nein. Jeder Core Web Vitals-Messwert wird im Verhältnis zum aktuellen, für die Seitennavigation auf oberster Ebene. Wenn eine Seite dynamisch aktualisiert und die URL der Seite in der Adressleiste aktualisiert, werden keine wie die Core Web Vitals-Messwerte gemessen werden. Messwerte sind nicht Dabei handelt es sich um die URL, die den Seitenaufbau ausgelöst haben.
Können bei den Core Web Vitals-Messwerten SPA-Routenänderungen wie beim herkömmlichen Seitenaufbau behandelt werden?
Leider nicht. Noch nicht.
Es gibt heute kein standardisiertes Verfahren für den Aufbau einer SPA, selbst bei SPA und Routing-Bibliotheken verwenden, kann die Nutzererfahrung sehr unterschiedlich ausfallen. von App zu App:
- Einige SPAs aktualisieren die URL nur beim Laden einer neuen "vollständigen Seite". Inhalte, während andere Websites aktualisieren die URL bei winzigen inhaltlichen Änderungen oder auch nur bei UI-Status. Änderungen.
- Einige SPAs aktualisieren die URL mithilfe der History API, andere verwenden Hash Änderungen vorgenommen, um ältere Browser zu unterstützen (in anderen wird die URL nicht aktualisiert) überhaupt).
- Einige SPAs laden Inhalte und aktualisieren dann die URL, andere aktualisieren die URL bevor der Inhalt geladen wird.
- Einige SPAs laden alle Inhalte gleichzeitig, synchron, in einem einzigen JavaScript-Code während andere Inhalte asynchron in mehrere Aufgaben (ohne eindeutiges Ende des Übergangs).
- Einige SPAs laden immer Inhalte aus dem Netzwerk, während andere alle Inhalte im Voraus, sodass Routenänderungen sofort aus dem Speicher geladen werden.
Aufgrund dieser Unterschiede können Sie eine SPA-Route definieren und identifizieren. oder sogar eine SPA selbst zu ändern, ist das in großem Maßstab nur schwer umzusetzen.
Manchmal ist eine SPA-Routenänderung logisch identisch mit einem MPA-Seitenladevorgang, In solchen Fällen wäre es gut, wenn die bestehenden Core Web Vitals-Messwerte angewendet werden könnte.
Ohne verlässliche Heuristiken zur zuverlässigen Identifizierung von „realen“ Routenänderungen ab allen anderen URL-Änderungen sowie eindeutige Signale am Anfang und am Ende dass die Meldung der Core Web Vitals-Messwerte in diesen Fällen und machen sie weniger nützlich oder repräsentativ für die tatsächliche User Experience auf der Website.
Ist es für SPAs schwieriger, bei Core Web Vitals eine gute Leistung zu erzielen als für MPAs?
Die SPA-Architektur hat nichts an sich, was verhindern würde, dass eine Seite SPA ebenso schnell geladen werden und auf allen Core-Geräten genauso gut bewertet werden. Web Vitals-Messwerte – als ähnliche Seite in einer MPA-Datei.
Richtig optimierte MPAs haben jedoch auch einige Vorteile bei der Erfüllung der Vitalwerte, die von SPAs derzeit nicht erfüllt werden. Der Grund dafür ist, Architektur, jede „Seite“ als Vollbildnavigation geladen wird (und nicht Content dynamisch abrufen und in die vorhandene Seite einfügen), dass Nutzer, die eine MPA-Datei besuchen, mit höherer Wahrscheinlichkeit mehr als eine Seite aus der was wiederum bedeutet, dass ein größerer Prozentsatz der Verteilung Beim Seitenaufbau für eine MPA-Datei werden einige oder alle Unterressourcen im Cache gespeichert.
Gewährt, für eine MPA, die bei den Core Web Vitals-Messwerten besser abschneidet als eine SPA sind einige Dinge zu beachten:
- Die MPA muss das Caching von Unterressourcen optimieren, um sicherzustellen, werden ursprungsübergreifende Seitenladevorgänge deutlich schneller als ursprungsübergreifende 75. Perzentil.
- Nutzer, die MPAs besuchen, müssen mehrere Seiten besuchen, damit die Website profitieren von den Caching-Vorteilen, die zu einem schnelleren Laden der Seiten führen.
Die Core Web Vitals-Bewertungen berücksichtigen den 75. Perzentil der Seite mehr, leistungsstarke Seitenbesuche im Datensatz zu haben, Wahrscheinlichkeit, dass der Besuch beim 75. Perzentil der Verteilung innerhalb der empfohlenen Grenzwerte.
Ein wichtiger Punkt beim Vergleich der Core Web Vitals-Werte ist die Art und Weise, wie die Daten aggregiert werden, d. h., ob das Dataset in der Verteilung enthält alle Seiten Ihrer Website oder Ihren Ursprung bzw. nur Seitenladevorgänge für eine bestimmte Seiten-URL.
Wenn die Punktzahlen aller Seiten in einem Ursprung zusammengefasst werden, können einzelne schnelle Seiten das 75. Perzentil für den gesamten Ursprung verbessern. Beim Aggregieren nach einzelnen Seiten unterteilt, haben die Bewertungen einer Seite keinen Einfluss auf die Werte der Wenn Sie also die Scores einer MPA nach Seite aggregieren, Ladevorgänge auf der Zahlungsseite verbessern nicht den Wert einer langsamen anfänglichen die auf der Landingpage der Website Seite.
Sie können die Bewertung Ihrer Website für verschiedene Aggregationsmethoden mit PageSpeed Insights oder Bericht zur Nutzererfahrung in Chrome API, die Bewertungen sowohl für einzelne Seiten-URLs als auch für den gesamten Ursprung erfasst.
Eine weitere Möglichkeit, wie die SPA-Architektur die Core Web Vitals-Werte beeinflussen kann, ist Messwerte, die die gesamte Lebensdauer einer Seite berücksichtigen. Da Nutzer, die SPAs besuchen, bleiben häufig auf derselben Seite, während der gesamten Sitzung erfasst werden, mit der Zeit strenger sein als MPAs.
Im April 2021 haben wir Änderungen am CLS-Messwert angekündigt, dieses Problem teilweise gelöst. Zuvor wurden CLS über die die gesamte Lebensdauer der Seite. Jetzt werden sie nur über ein im Prinzip die schlimmsten Layoutverschiebungen auf einer Seite.
Aber selbst mit der neuen CLS-Definition sind SPAs immer noch im Nachteil da der CLS-Wert nicht zurückgesetzt wird, nachdem eine Route so übergangen ist, beim vollständigen Laden der Seite in einer MPA-Datei. Dies kann auch zu Verwirrung führen, die nach einem Routenübergang auftreten, werden der URL der und nicht die URL in der Adressleiste zum Zeitpunkt der Umstellung. (Weitere Informationen unten)
Wenn SPA-Architekturen die Nutzererfahrung verbessern, sollte sich das nicht in den Messwerten widerspiegeln?
Ja, das sollte es. Wie bereits erwähnt, lässt sich nur quantifizieren, und die User Experience verbessert wurde, ist angesichts der vielen unterschiedlichen wie SPAs aktuell im Web implementiert werden.
Die Wahrheit ist, dass die Web-Performance-Branche (einschließlich Google) in der Vergangenheit fast ebenso viel Zeit und Aufwand in die Entwicklung nutzerorientierter für die Leistung nach dem Laden eines wie beim Laden der Seite. Das liegt nicht daran, dass ist die Leistung nicht wichtig, denn die UX und Interaktionen nach dem Laden sind viel vielfältiger und weniger klar definiert, was die Entwicklung von Metriken für .
Aber selbst wenn wir nach dem Laden gut definierte Messwerte zur Messung der SPA die Ladezeiten nicht außer Acht lassen, nur weil die jetzt noch besser.
Eines der Ziele der Web Vitals-Initiative ist es, positive in so vielen Aspekten des Ladens und Nutzens einer Webseite wie möglich. Wir möchten keine Situationen fördern, in denen gerechtfertigt ist, wenn Sie genug gute Erfahrungen haben können, um diese zu kompensieren. Nutzer*innen Seiten schnell laden und schnell zu neuem Content übergehen möchten. Designmetriken, die diese Art von Erfahrungen bevorzugen.
Es stimmt zwar, dass eine MPA-Version einer Website im Core Web- Vitals-Messwerte im 75. Perzentil als eine SPA-Version derselben Website sollten, sollte die SPA-Version trotzdem die „guten“ Grenzwert. Wenn die Die SPA-Version entspricht nicht der „guten“ Version Schwellenwert für die meisten Nutzer erreicht, die Nutzererfahrung beim Laden der Seite wahrscheinlich immer noch nicht als gut empfunden wird – auch wenn die nachfolgende dass die In-Page-Navigation hervorragend funktioniert.
Für die Zukunft planen wir die Entwicklung von Messwerten, die nach Ladevorgängen Wir glauben, dass dies der beste Weg ist, um Anreize für qualitativ hochwertige SPAs so konfigurieren, dass der anfängliche Ladevorgang nicht beeinträchtigt wird. Wir haben Wir haben bereits einen neuen Messwert mit dem Namen Interaction to Next Paint (INP) zur Verfügung gestellt, der die Interaktionslatenz während des gesamten Lebenszyklus der Seite misst. Messwerte 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 gesunken. Ist das zu erwarten?
Das ist unterschiedlich. Es gibt eine Reihe von Gründen, warum sich Ihre Bewertungen nach einem größere Architekturmigration, aber geringere Anzahl von Warm-Cache-Ladevorgängen könnte die Änderung teilweise berücksichtigt werden.
Sie können dies schnell überprüfen, indem Sie sowohl eine MPA- als auch eine SPA-Version einer Ihrer Landingpages mit Lighthouse. Wenn die Der Lighthouse-Score ist bei keinem Core Web Vitals-Messwert für die SPA niedriger ist es wahrscheinlich, dass sich die Ladezeit nach dem aktualisieren.
Sollte ich meine Website von einer SPA auf eine MPA-Datei umstellen, um die Core Web Vitals besser zu bewerten?
Wahrscheinlich nicht. Sie sollten nur dann von einer SPA zu einer MPA wechseln, wenn Sie nicht zufrieden sind. mit Ihrem SPA-Stack und haben Grund zu der Annahme, dass eine MPA eine bessere User Experience ausmacht.
Im Laufe der Zeit werden die Core Web Vitals-Messwerte verbessert und decken immer mehr sollten Teams mit gut entwickelten SPAs, die eine hervorragende Nutzererfahrung bieten, werden sich die Core Web Vitals-Werte auch hier ansehen.
Wie kann ich Probleme auf Seiten beheben, wenn die Core Web Vitals-Werte nur für die Landingpages einer SPA erfasst werden nach einem Routenübergang?
Google-Tools, die Felddaten für den Core Web Vitals-Messwert melden (z. B. die Google Suche) Console und PageSpeed Insights ihre Daten aus der Chrome-Nutzererfahrung Melden (CrUX). Außerdem aggregiert CrUX Daten entweder nach Ursprung oder nach Seiten-URL (d. h. Seiten-URL bei der Ladezeit).
Aus allen oben genannten Gründen können in Chrome zur Nutzererfahrung in Chrome keine Daten nach SPA-Route Als Websiteinhaber, der mit Ihrer eigenen Architektur vertraut ist, können Sie dies selbst messen. Viele Analysetools bieten Ihnen signalisiert, wenn eine SPA-Routenänderung erfolgt und Ihre Messung Daten entsprechend anpassen.
Wenn Sie Web Vitals-Messwerte mit einem Analysetool messen, messen sowohl die URL der aktuellen Weiterleitung als auch die URL der Originalseite. Dadurch wird können Sie einzelne Probleme auf der Seite beheben, und nach der URL der Originalseite aggregiert werden, um den um Messwerte zu erfassen und Berichte dazu zu erstellen.
Weitere Informationen und Best Practices zu diesem Thema finden Sie unter Leistungsfehler beheben in der Feld ein.
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 Berichte liefern. Web Vitals-Werte im 75. Perzentil, da diese wahrscheinlich haben einen höheren Prozentsatz an Seitenaufrufen im Cache. Umgekehrt gibt es echte Verbesserungen Die Nutzererfahrung in ordnungsgemäß optimierten SPAs wird derzeit nicht erfasst. Core Web Vitals-Messwerte berücksichtigt werden.
Wir bei Google sind uns bewusst, dass dies Anreize schafft, die nicht gänzlich übereinstimmen. mit den Zielen der Web Vitals-Initiative. Wir suchen aktiv nach Möglichkeiten, um dieses Problem zu beheben. Derzeit testen wir zwei mögliche Lösungen, eine kurzfristige und einen langfristigen:
- Beurteilen Sie ursprungsübergreifende und Same-Origin-Seitenbesuche separat.
- Entwerfen Sie neue APIs, die eine bessere SPA-Messung ermöglichen.
Ursprungsübergreifende und Same-Origin-Seitenbesuche separat bewerten
Heute fassen die Core Web Vitals-Messwerte alle Seitenaufrufe in einer einzigen neue und wiederkehrende Besucher oder Landingpages, und Zahlungsseiten oder andere Aggregationstypen mit Cache-Status sich auf die Leistung auswirken kann.
Eine Möglichkeit, die Unterschiede zwischen der SPA- und MPA-Leistung zu normalisieren, wäre, unterschiedlich gewichtet für verschiedene Arten von Besuchen, möglicherweise auch mit völlig anderer Schwellenwert Empfehlungen.
Wir möchten effektive Cache-Implementierungen definitiv belohnen, Sie wünschen sich eine schnelle Navigation innerhalb der Website, um eine langsame Landingpage überdecken zu können. geladen wird. Wir möchten auch keine Anreize für Websites schaffen, lange Seiten kürzere Seiten zu erstellen, um die Messwerte zu verbessern.
Durch die getrennte Bewertung von ursprungsübergreifenden und Same-Origin-Seitenbesuchen dass beide Arten von Erfahrungen wichtig sind, ohne die relativen die Beliebtheit eines Typs auf einer bestimmten Website die Verteilung eines bestimmten Messwert.
Neue APIs für eine bessere SPA-Messung entwerfen
Eine weitere Lösung, an der (parallel zu den obigen Ausführungen) aktiv gearbeitet wird, ist eine neue App History API, die bei der Standardisierung SPA-Muster erstellen und die SPA-Nutzung im großen Maßstab leichter messen und verstehen.
Die App History API führt eine neue
navigate
-Ereignis, das
hat zwei wichtige Funktionen, die speziell für die SPA-Messung spezifisch sind:
- A
userInitiated
wird nur dann auf "true" gesetzt, wenn die Navigation über ein Klick auf Links, Formulareinreichungen oder die Browseroberfläche zum Zurückgehen oder Weitergeben. - A
transitionWhile()
bei dem der Entwickler angeben kann, wann für die Navigation abgeschlossen ist.
Mit dem Flag userInitiated
kann ein semantischer Ausgangspunkt für
SPA-Routenübergang, was auf eine eindeutige Nutzerabsicht hinweist. Das transitionWhile()
Versprechung der Auflösung kann dem Browser helfen, Farben mit der spezifischen Route zu korrelieren.
Übergang, sodass es in der Lage sein kann, den größten Contentful Paint
in Bezug auf diese Umstellung.
Aufbauend auf der Idee aus dem vorherigen Abschnitt die Übergangszeit der SPA-Route in einem Bucket zusammenfassen, Seite mit derselben Quelle in einer MPA-Datei geladen. Das ist spannend, weil so eine Website von einer MPA zu einer SPA migrieren, um die Leistung vor und danach.
Natürlich sind weitere Untersuchungen erforderlich, bevor wir wissen, ob wir um diese Entscheidungen zu treffen. Wenn Sie Vorschläge oder Feedback zu diesen erhalten Sie per E-Mail web-vitals-feedback@googlegroups.com
Schlussgedanken
Google setzt alles daran, die Web Vitals-Messwerte zu verbessern und sicherzustellen, Sie messen und fördern qualitativ hochwertige Erfahrungen, die für die Nutzenden. Dennoch ist uns bewusst, dass Messlücken auch heute bestehen. Die decken nicht alle Aspekte der Nutzererfahrung ab. die aktiv daran arbeiten, diese Lücken zu schließen.
Trotz der aktuellen Einschränkungen sind wir der Meinung, dass die bestehenden Messwerte Daten sind entscheidend für die Gesundheit und den Erfolg des Webs dass Websites (unabhängig von der Architektur) die empfohlenen Grenzwerte nicht erreichen, wir glauben, dass es Raum für Verbesserungen gibt.
Ich hoffe, dass ich dir mit diesem Post etwas mehr über dieses komplexe und differenzierte Thema erzählen konnte. Wie immer gilt: Wenn Sie Feedback zu aktuellen oder zukünftigen Web Vitals-Messwerten haben, bitte E-Mail senden web-vitals-feedback@googlegroups.com