Antworten auf häufig gestellte Fragen zu SPAs, Core Web Vitals und wie Core Web Vitals diese behandelt
Veröffentlicht am 14. September 2021, zuletzt aktualisiert am 11. August 2026
Seit der Einführung der Web Vitals-Initiative im Mai 2020 haben wir im Chrome-Team viele Fragen und viel Feedback zum Programm erhalten.
Das Thema, zu dem wir die meisten Fragen erhalten haben und das wahrscheinlich auch am schwierigsten zu beantworten ist, ist die Messung von 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 recht komplex ist. In diesem Beitrag versuchen wir, die häufigsten Fragen so detailliert und kontextbezogen wie möglich zu beantworten.
Bevor wir ins Detail gehen, ist es wichtig zu erwähnen, dass Google keine Präferenz hinsichtlich der Architektur oder Technologie hat, die zum Erstellen einer Website verwendet wird. Wir sind der Meinung, dass SPAs und Multi-Page-Anwendungen (MPAs) Nutzern hochwertige Erlebnisse 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.
Häufig gestellte Fragen
Im Folgenden finden Sie einige der häufigsten Fragen zu diesem Thema. Wir freuen uns über Feedback, das wir in diese FAQ aufnehmen können. Sie können uns Feedback in unserer Feedbackgruppe geben oder ein Problem melden.
Beziehen sich die Core Web Vitals-Messwerte auf SPA-Routenübergänge?
Bei der Einführung wurde jeder der Core Web Vitals-Messwerte relativ zur aktuellen Navigation auf oberster Ebene gemessen. Wenn eine Seite dynamisch neue Inhalte geladen und die URL der Seite in der Adressleiste aktualisiert hat, hatte dies keine Auswirkungen auf die Messung der Core Web Vitals-Messwerte.
Die Messwerte wurden nicht zurückgesetzt und die URL, die mit jeder Messung verknüpft ist, ist die URL, zu der der Nutzer navigiert ist und die den Seitenaufbau ausgelöst hat.
In Chrome 151 wurden neue APIs eingeführt, mit denen Core Web Vitals für SPA-Routenübergänge gemessen werden können. Zum Zeitpunkt des Schreibens (August 2026) werden diese APIs gerade erst in Messbibliotheken wie web-vitals, RUM-Lösungen und Tools wie Chrome-Entwicklertools verwendet. Chrome hat noch keine Zeitrahmen für die Integration in den Chrome User Experience Report (CrUX) veröffentlicht. Außerdem werden diese neuen APIs von anderen Browser-Engines noch nicht unterstützt. Daher können Core Web Vitals für diese Browser nur für vollständige Seitenaufrufe gemessen werden.
Warum war das so schwer zu lösen?
Es gibt derzeit keine standardisierte Methode zum Erstellen einer SPA. Selbst bei den beliebten SPA- und Routing-Bibliotheken kann sich die Nutzerfreundlichkeit von App zu App erheblich unterscheiden:
- Bei einigen SPAs wird die URL nur aktualisiert, wenn neue Inhalte für die „vollständige Seite“ geladen werden. Bei anderen Websites wird die URL bei kleinen Inhaltsänderungen oder sogar nur bei Änderungen des UI-Status aktualisiert.
- Bei einigen SPAs wird die URL mit der History API aktualisiert, bei anderen werden Hash-Änderungen verwendet, um ältere Browser zu unterstützen. Bei anderen wird die URL überhaupt nicht aktualisiert.
- 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 gleichzeitig, synchron und in einer einzigen JavaScript-Aufgabe geladen. Bei anderen werden Inhalte asynchron in mehreren Aufgaben übertragen (ohne ein klares Ereignis für das Ende der Übertragung).
- Bei einigen SPAs werden Inhalte immer aus dem Netzwerk geladen, bei anderen werden alle Inhalte im Voraus geladen, sodass Routenänderungen sofort aus dem Arbeitsspeicher geladen werden.
Diese Unterschiede machen es sehr schwierig, im großen Maßstab zu definieren und zu identifizieren, was eine SPA-Routenänderung oder sogar eine SPA selbst ausmacht.
In einigen Fällen ist eine SPA-Routenänderung logisch identisch mit einem MPA-Seitenaufruf. In solchen Fällen wäre es gut, wenn die vorhandenen Core Web Vitals-Messwerte angewendet werden könnten.
Ohne solide Heuristiken, um „echte“ Routenänderungen zuverlässig von allen anderen URL-Änderungen zu unterscheiden, sowie klare Signale, die den Beginn und das Ende solcher Übergänge kennzeichnen, würde die Berichterstellung von Core Web Vitals-Messwerten in diesen Fällen die Daten verfälschen und sie weniger nützlich oder repräsentativ für die tatsächliche Nutzerfreundlichkeit auf der Website machen.
Die Arbeit an Soft Navigations hat mit zwei neuen Leistungs-APIs eine Lösung für dieses Problem geschaffen:
PerformanceSoftNavigationmisst, wann eine Nutzerinteraktion sowohl zu einem Paint als auch zu einer URL-Änderung führt. Die Kombination dieser drei Faktoren bietet eine standardisierte Definition einer „Soft Navigation“, unabhängig vom verwendeten Framework und einigen der zuvor genannten Unterschiede. So kann die Leistungszeitachse in separate „Navigations“ unterteilt werden, sodass CLS und INP für jede Navigation gemessen werden können.InteractionContentfulPaintmisst „Contentful Paints“ nach einer Interaktion, sodass FCP und LCP für diese Soft Navigations gemessen werden können.
Durch die Kombination dieser beiden APIs können Core Web Vitals sowohl für vollständige Seitenaufrufe als auch für Soft Navigations gemessen werden.
Sind SPA-Routenänderungen für Core Web Vitals dasselbe wie vollständige Seitenaufrufe?
Nein, es gibt immer noch viele Unterschiede zwischen diesen Arten von Navigationen, die zu unterschiedlichen Core Web Vitals-Messwerten führen können.
Bei einer Soft Navigation sind Inhalte auf der Seite vorhanden und einige oder alle Inhalte werden aktualisiert, um die neue „Seite“ anzuzeigen. In vielerlei Hinsicht ähnelt dies dem Unterschied zwischen einem vollständigen Seitenaufruf ohne Cache und einem Seitenaufruf, bei dem einige oder alle Seitenressourcen im Cache gespeichert sind. Es ist jedoch noch extremer, da einige Inhalte möglicherweise gerendert bleiben.
Theoretisch besteht der Hauptunterschied darin, dass Soft Navigations viel schneller sein können. Es gibt aber auch andere, subtilere Unterschiede.
Bei den neuen Soft Navigation-APIs werden nur neue Inhalte berücksichtigt. Wenn also auf einer Seite der <h1> und Textinhalt aktualisiert wird, aber zwischen den Seiten dasselbe Hero-Image verwendet wird, wird das Hero-Image nicht als LCP-Kandidat betrachtet, wenn es nicht neu gerendert wurde. Dies führt zu Unterschieden bei den Elementen, die zur Berechnung der LCP-Zeit verwendet werden, je nachdem, ob dieselbe Seite als vollständiger Seitenaufruf oder als Soft Navigation von einer anderen vorhandenen Seite geladen wird.
Ebenso kann INP bei Soft Navigations niedriger sein, da viel JavaScript, das zum Ausführen der Website erforderlich ist, bereits geladen ist. Auf die gleiche Weise kann eine Soft Navigation weniger (oder mehr!) CLS haben, wenn derselbe Inhalt bei einem vollständigen Seitenaufruf CLS verursacht, aber bei einer Soft Navigation nicht geladen oder neu gerendert werden muss.
Es gibt auch geringfügige Unterschiede beim Zeitpunkt der Messungen bei vollständigen Seitenaufrufen (gemessen nach der Verarbeitung der Navigationsinteraktion) im Vergleich zu Soft Navigations (gemessen ab dem Startzeitpunkt der Interaktion).
Wie bereits erwähnt, ähneln viele dieser Unterschiede denen zwischen Seiten ohne Cache und Seiten mit Cache. Das Konzept, das mit Core Web Vitals gemessen werden soll, gilt weiterhin. Es ist jedoch wichtig, diese Feinheiten zu verstehen, wenn Sie Probleme mit Core Web Vitals untersuchen.
Ist es für SPAs schwieriger, bei Core Web Vitals gut abzuschneiden als für MPAs?
Es gibt nichts in der SPA-Architektur, das verhindern würde, 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.
Gut optimierte MPAs haben jedoch einige Vorteile bei der Einhaltung der Core Web Vitals-Grenzwerte, die SPAs nicht haben. Dies wurde weitgehend durch die zuvor beschriebene Arbeit an Soft Navigations behoben. Es kann jedoch weiterhin der Fall sein, wenn diese neuen APIs noch nicht verwendet werden. Der Grund dafür ist, 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 der Website laden. Das wiederum bedeutet, dass bei einem größeren Prozentsatz der Verteilung aller Seitenaufrufe für eine MPA einige oder alle Unterressourcen im Cache gespeichert sind.
Damit eine MPA bei den Core Web Vitals-Messwerten besser abschneidet als eine SPA, müssen jedoch einige Voraussetzungen erfüllt sein:
- Die MPA muss über ein optimiertes Caching von Unterressourcen verfügen, damit Seitenaufrufe derselben Quelle tatsächlich schneller sind als Seitenaufrufe anderer Quellen im 75. Perzentil.
- Nutzer, die MPAs besuchen, müssen mehrere Seiten aufrufen, damit die Website von den Caching-Vorteilen profitiert, die zu schnelleren Seitenaufrufen führen.
Da bei Core Web Vitals-Tests das 75. Perzentil der Seitenaufrufe berücksichtigt wird, erhöht eine größere Anzahl gut funktionierender Seitenaufrufe im Dataset die Wahrscheinlichkeit, dass der Aufruf im 75. Perzentil der Verteilung innerhalb der empfohlenen Grenzwerte liegt.
Ein wichtiger Punkt beim Vergleich von Core Web Vitals-Werten ist, wie die Daten zusammengefasst werden. Das heißt, ob das Dataset in der Verteilung alle Seiten Ihrer Website oder Quelle oder nur Seitenaufrufe für eine bestimmte Seiten-URL enthält.
Wenn die Werte aller Seiten einer Quelle zusammengefasst werden, können einzelne schnelle Seiten das 75. Perzentil für die Quelle insgesamt verbessern. Wenn jedoch nach einzelnen Seiten zusammengefasst wird, haben die Werte einer Seite keine Auswirkungen auf die Werte der nächsten. Wenn Sie die Werte einer MPA nach Seite zusammenfassen, verbessern schnelle Cache-Aufrufe auf der Zahlungsseite nicht die Werte für langsame anfängliche Aufrufe auf der Landing Page der Website.
Sie können den Wert Ihrer Website für verschiedene Zusammenfassungsmethoden mit PageSpeed Insights oder der Chrome User Experience Report API prüfen. Dort werden Werte für einzelne Seiten-URLs und die gesamte Quelle angegeben.
Eine weitere Möglichkeit, wie sich die SPA-Architektur auf die Core Web Vitals-Werte auswirken kann, sind Messwerte, die die gesamte Lebensdauer einer Seite berücksichtigen. Da Nutzer, die SPAs besuchen, in der Regel während der gesamten Sitzung auf derselben „Seite“ bleiben, können Messwerte, die sich im Laufe der Zeit ansammeln, für SPAs ungünstiger sein als für MPAs.
Mit der Arbeit an Soft Navigations sollte es unserer Meinung nach keine Nachteile für SPAs in Bezug auf die Messung von Core Web Vitals geben. Die vollständige Integration dieser APIs in alle Tools und Berichtslösungen wird jedoch Zeit in Anspruch nehmen.
Wenn SPA-Architekturen die Nutzerfreundlichkeit verbessern, sollte sich das nicht in den Messwerten widerspiegeln?
Ja, das sollte so sein. Es war schwierig, die Verbesserung der Nutzerfreundlichkeit im großen Maßstab zu quantifizieren, da SPAs heute auf so viele verschiedene Arten im Web implementiert werden. Wir haben jetzt eine Lösung für das Messproblem. Wenn diese neuen APIs verwendet werden, sollten sich alle Verbesserungen durch den Wechsel zu SPAs in den Messwerten widerspiegeln.
Die Web-Performance-Branche (einschließlich Google) hat 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 wie für den Seitenaufbau selbst. Das liegt nicht daran, dass die Leistung nach dem Laden nicht wichtig ist, sondern daran, dass die Nutzerfreundlichkeit und die Interaktionen nach dem Laden viel vielfältiger und weniger gut definiert sind. Daher ist es schwierig, Messwerte dafür zu entwickeln.
Aber auch wenn wir jetzt mehr Messwerte für die Leistung nach dem Laden haben, um die Leistung von SPAs zu messen, möchten wir die Ladeleistung nicht ignorieren, nur weil sich die Leistung nach dem Laden verbessert hat.
Eines der Ziele der Web Vitals-Initiative ist es, eine gute Nutzerfreundlichkeit in möglichst vielen Aspekten des Ladens und der Nutzung einer Webseite zu fördern und zu belohnen. Wir möchten keine Szenarien fördern, in denen schlechte Erfahrungen gerechtfertigt sind, wenn Sie genügend gute Erfahrungen machen können, um sie auszugleichen. Nutzer möchten, dass Seiten schnell geladen werden und schnell zu neuen Inhalten übergehen. Wir haben versucht, Messwerte zu entwickeln, die diese Arten von Erfahrungen bevorzugen.
Wir haben unsere Website von einer MPA zu einer SPA umgestellt und unsere Werte sind gesunken. Ist das zu erwarten?
Das ist unterschiedlich. Es gibt eine Reihe von Gründen, warum sich Ihre Werte nach einer größeren Architekturmigration ändern können. Ein Rückgang der Anzahl der Aufrufe mit Cache kann einen Teil der Änderung erklären.
Eine schnelle Möglichkeit, das zu überprüfen, besteht darin, mit Lighthouse sowohl eine MPA- als auch eine SPA-Version einer Ihrer Landingpages zu testen. Wenn der Lighthouse-Wert für einen der Core Web Vitals-Messwerte für die SPA-Version niedriger ist, hat sich die Ladeleistung nach dem Update wahrscheinlich verschlechtert.
Sollte ich meine Website von einer SPA zu einer MPA umstellen, um bei Core Web Vitals besser abzuschneiden?
Wahrscheinlich nicht. Sie sollten nur 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 Nutzerfreundlichkeit bietet.
Mit der Arbeit an Soft Navigations haben wir die Messprobleme unserer Meinung nach behoben. Ein Wechsel aus diesem Grund allein ist daher nicht sinnvoll.
Wenn Sie jedoch Grund zur Annahme haben, dass sich die Leistung verbessern wird, anstatt nur die Messwerte, dann kann das ein Grund sein, von SPA zu MPA zu wechseln (oder umgekehrt).
Wenn Core Web Vitals-Werte nur für die Landingpages einer SPA gemeldet werden, wie kann ich Probleme beheben, die auf „Seiten“ nach einem Routenübergang auftreten?
Google-Tools, die Felddaten für den Core Web Vitals-Messwert melden (z. B. Search Console und PageSpeed Insights), beziehen ihre Daten aus dem Bericht zur Nutzererfahrung in Chrome (Chrome User Experience, CrUX). In CrUX werden Daten entweder nach Ursprung oder nach Seiten-URL zusammengefasst (d. h. nach der Seiten-URL zum Zeitpunkt der Ladezeit).
Wir arbeiten daran, dass CrUX in den zusammengefassten Daten auch Daten nach SPA-Route berücksichtigt. Als Websiteinhaber können Sie die neuen APIs jedoch jetzt schon verwenden, um Core Web Vitals nach SPA-Route zu messen und so zu sehen, wie sich Ihre Werte ändern könnten.
Weitere Informationen und Best Practices finden Sie unter Soft Navigations messen.
Was unternimmt Google, um sicherzustellen, dass MPAs im Vergleich zu SPAs keinen unfairen Vorteil haben?
Wie bereits erwähnt, sind wir der Meinung, dass die Arbeit an Soft Navigations dazu geführt hat, dass SPAs in dieser Hinsicht keine Nachteile haben sollten. Die vollständige Integration in alle Tools und Berichtslösungen wird jedoch Zeit in Anspruch nehmen.
Seitenaufrufe anderer Quellen und Seitenaufrufe derselben Quelle getrennt bewerten
Derzeit werden bei den Core Web Vitals-Messwerten alle Seitenaufrufe in einem einzigen Bucket zusammengefasst. Es wird nicht zwischen neuen und wiederkehrenden Besuchen oder Landingpages und Checkout-Seiten oder anderen Zusammenfassungstypen unterschieden, bei denen der Cache-Status Auswirkungen auf die Leistung haben 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 und möglicherweise sogar völlig unterschiedliche Grenzwert empfehlungen zu verwenden.
Wir möchten zwar effektive Cache-Implementierungen belohnen, aber wir möchten nicht, dass schnelle Navigationen innerhalb der Website langsame Landingpage-Aufrufe ausgleichen können. Außerdem möchten wir Websites nicht dazu anregen, lange Seiten in eine Sammlung kürzerer Seiten aufzuteilen, nur um die Messwerte zu verbessern.
Durch die getrennte Bewertung von Seitenaufrufen anderer Quellen und Seitenaufrufen derselben Quelle können wir sicherstellen, dass beide Arten von Erfahrungen wichtig sind, ohne dass die relative Beliebtheit einer Art auf einer bestimmten Website die Verteilung eines bestimmten Messwerts verzerrt.
Schlussgedanken
Google ist fest entschlossen, die Web Vitals-Messwerte zu verbessern und sicherzustellen, dass sie hochwertige Erfahrungen messen und fördern, die für Nutzer wichtig sind. Wir sind uns jedoch bewusst, dass es derzeit Lücken bei der Messung gibt. Die Messwerte können jetzt SPA-Routenübergänge abdecken, wodurch eine der Hauptlücken geschlossen wird.
Wir sind auch der Meinung, dass diese neuen APIs (insbesondere InteractionContentfulPaint) über die Messung von Core Web Vitals für Soft Navigations hinaus weitere Verwendungsmöglichkeiten und potenzielle Vorteile bieten. Wir freuen uns sehr darauf, diese weiterzuentwickeln, nachdem der Hauptgrund für ihre Einführung behoben wurde.
Ich hoffe, dieser Beitrag hat dazu beigetragen, dieses komplexe und vielschichtige Thema zu beleuchten. Wenn Sie Feedback zu den aktuellen oder zukünftigen Web Vitals-Messwerten haben, senden Sie eine E-Mail an web-vitals-feedback@googlegroups.com.