Soft Navigations in CrUX: was SPA-Shops bis Mai 2027 prüfen

Auslöser ist der Start der Soft-Navigations-Schnittstelle in Chrome 151 (web.dev). Chrome erkennt eine Soft Navigation, wenn drei Merkmale zusammenkommen: Eine Nutzeraktion löst den Wechsel aus, die Adresse ändert sich sichtbar, und auf der Seite wird sichtbar neu gezeichnet (Chrome for Developers). Bisher erfasste CrUX in einer Single-Page-App nur den ersten, harten Seitenaufruf. Alle späteren Klicks liefen als Teil dieser ersten Seite mit, samt ihrer Interaktionen und Layoutverschiebungen. Ein Kunde, der mehrere Produkte ansieht, ging also mit einem einzigen Seitenaufruf in die Statistik ein, und die langsamste Interaktion der ganzen Sitzung landete bei der Einstiegsseite.

Neu sind drei experimentelle Kennzahlen, die harte und weiche Navigationen gemeinsam auswerten. Sie tragen bewusst den Zusatz experimentell, damit klar ist, dass sich ihre Definition noch ändern kann:

Wichtig für die Einordnung: Die stabilen Core-Web-Vitals-Werte bleiben unverändert, die experimentellen werden parallel dazu erprobt. Auch die Search Console zeigt bis zur Umstellung die bisherigen Werte, und die meisten Werkzeuge berichten die Core Web Vitals noch ohne die neuen Soft-Navigation-Kennzahlen (web.dev). Für das nächste CrUX-Release im November stellt Chrome weitere experimentelle Kennzahlen in Aussicht, für First Contentful Paint und für die Navigationstypen (web.dev). Wer jetzt einen Bericht für die Geschäftsführung baut, sollte deshalb wissen, welche Lesart welches Werkzeug gerade zeigt.

Für Shopware-Shops entscheidet die Bauart. Die klassische Storefront rendert Seiten serverseitig mit Twig-Vorlagen; der Browser ruft die Store API dabei nicht selbst auf, das erledigen die Controller des Shops (Shopware-Dokumentation). Jeder Wechsel zwischen Kategorie und Produkt ist dort ein vollständiger Seitenaufruf, und solche Shops sehen in den experimentellen Werten wenig Bewegung. Anders bei Headless-Projekten: Shopware Frontends ist der Baukasten für eigenständige Storefronts, die Demo-Umsetzung basiert auf Vue.js und Nuxt und holt die Daten zur Laufzeit über die Store API (Shopware-Dokumentation). Ein solches Frontend wechselt Seiten über seinen eigenen Router, und solche Wechsel erfasst Chrome als Soft Navigations, sobald die drei Merkmale erfüllt sind.

Eine Grauzone liegt im Produktlisting. Auch die klassische Storefront schreibt die Filterauswahl beim Klick per history.pushState in die Adresse und lädt die Produktliste im Hintergrund nach (Shopware-Quellcode). Damit können alle drei Merkmale einer Soft Navigation erfüllt sein: Nutzeraktion, sichtbare Adressänderung, sichtbarer Neuaufbau. Ob Chrome einen Filterklick tatsächlich als Navigation wertet, hängt an seiner Heuristik. Prüfen lässt sich das im Performance-Panel der DevTools, das Soft Navigations in der Live-Ansicht und im Trace markiert (Chrome for Developers). Für Shopware-Projekte gehört diese Prüfung bei uns zur Shopware-Performance-Optimierung.

Dazu kommt eine Besonderheit der CrUX-Daten: Abfrageparameter wie ?utm_medium=email entfernt CrUX aus der Adresse, damit alle Aufrufe einer Seite zusammengefasst werden (CrUX-Dokumentation). Werden Filterklicks als Soft Navigation erfasst, fließen sie damit voraussichtlich in die Werte der Kategorie-URL ohne Parameter ein. Die Kategorieseite trägt dann nicht nur die Erfahrung des ersten Aufrufs, sondern auch die der Filterwechsel. Diese Anzeichen sprechen für einen hohen Anteil weicher Seitenwechsel:

Klicken Besucher durch viele Folgeansichten, verbessert sich der LCP, weil weiche Navigationen Code und Dateien wiederverwenden, die beim ersten Aufruf schon geladen wurden. Bei Android-Origins mit 75 bis 100 Prozent Soft Navigations steigt der Anteil mit gutem LCP von 26 auf 87 Prozent (web.dev). Chrome betont ausdrücklich, dass SPAs dadurch nicht insgesamt schneller sind als klassische Websites: Folgeklicks sind auf jeder Website schneller, und SPAs mit vielen Folgeklicks rücken damit an klassische Websites mit vielen Folgeklicks heran (web.dev).

Für die Fehlersuche ändert sich das LCP-Element. Die Soft-Navigation-Messung berücksichtigt nur neu gezeichnete Inhalte: Bleibt ein großes Bild zwischen zwei Ansichten stehen und wechselt nur der Text darunter, wird bei der weichen Navigation der Text zum LCP-Element (Chrome for Developers). Ein Kopfbild oder Banner, das beim Direkteinstieg das LCP-Element ist, scheidet nach einem Klick innerhalb des Shops also aus, wenn es stehen bleibt. Wie sich der LCP in seine Phasen zerlegen lässt, zeigt der Beitrag zur LCP-Subpart-Analyse.

Auch der CLS verbessert sich in der Regel, weil Layoutverschiebungen nicht mehr über eine lange Sitzung angesammelt, sondern je Ansicht bewertet werden. Websites mit vielen Soft Navigations liegen damit auf dem Desktop gleichauf mit klassischen Websites und auf Android fast gleichauf (web.dev). Bleibt der CLS einer Route trotzdem schlecht, liegt die Ursache in dieser Ansicht selbst: nachladende Bewertungen, Banner ohne reservierte Fläche oder Bilder ohne Maße. Hilfe dazu bietet der Beitrag Cumulative Layout Shift vermeiden.

Die History API wird jeden Montag aktualisiert und umfasst die vorangegangenen 40 Wochen, je Woche ein Erhebungszeitraum (CrUX-Dokumentation). Wie weit die experimentellen Reihen dort zurückreichen, zeigt die Antwort selbst: Zeiträume ohne geeignete Daten stehen als NaN beziehungsweise null in der Zeitreihe (CrUX-Dokumentation). Wer jetzt mit der Beobachtung beginnt, hat bis zur geplanten Umstellung mehrere Monate Verlauf und kann echte Trends von einzelnen Ausreißern trennen.

Für Auswertungen über viele Domains oder Länder bietet sich BigQuery an. Der Datensatz erscheint monatlich am zweiten Dienstag des Folgemonats (CrUX-Dokumentation), die neuen Spalten liegen im Bereich experimental als largest_contentful_paint_with_softnavs, interaction_to_next_paint_with_softnavs und cumulative_layout_shift_with_softnavs. Chrome rechnet ausdrücklich mit Verschiebungen von Monat zu Monat, solange die Messung verfeinert wird (web.dev). Ein einzelner Monatswert ist darum ein Zwischenstand, kein Urteil. So gehen Sie beim Vergleich vor:

Chrome peilt den Abschluss der Experimentphase für Mai 2027 an, ausdrücklich abhängig von Rückmeldungen (web.dev). Der Termin kann sich also verschieben. Für die Planung reicht er trotzdem, denn die Arbeit lässt sich in drei Abschnitte gliedern, die auch bei einer späteren Umstellung in dieser Reihenfolge sinnvoll bleiben.

CrUX zeigt, dass sich etwas verschiebt, aber nicht, an welcher Route. Dafür braucht es Real User Monitoring mit Soft-Navigation-Unterstützung. Die JavaScript-Bibliothek web-vitals unterstützt Soft Navigations ab Version 6.0.0 (Chrome for Developers). Chrome empfiehlt, den Navigationstyp mitzuschicken, damit sich LCP, INP und CLS getrennt nach weichen und harten Navigationen auswerten lassen. Für eine Übergangszeit lohnt die doppelte Messung: einmal nach bisheriger Lesart, einmal je Soft Navigation. So bleiben Verlauf und Vergleich mit anderen Browsern erhalten (Chrome for Developers).

Dabei gilt eine Grenze: Andere Browser-Engines als Chromium unterstützen die neuen Schnittstellen noch nicht, dort lassen sich Core Web Vitals nur über volle Seitenaufrufe messen (web.dev). Besucher mit Safari auf dem iPhone bleiben also in der bisherigen Lesart. Welche Messdaten Sie ohne Einwilligung erheben dürfen, klärt der Beitrag zur Performance-Messung ohne Einwilligung.

Für Headless-Shops und App-artige Portale beginnt die Vorbereitung mit einer ehrlichen Bestandsaufnahme: Wie groß ist der Anteil weicher Seitenwechsel, und welche Kennzahl verschiebt sich wie stark? In unserer Performance-Analyse vergleichen wir stabile und experimentelle CrUX-Werte je Gerätetyp und Seitentyp und ordnen die Abstände Ihren Vorlagen zu. Wo CrUX nicht reicht, richten wir die Routenmessung im eigenen Monitoring ein, mit getrennter Auswertung für Chromium und andere Browser.

Danach geht es an die Ursachen. Für gute Core Web Vitals in Single-Page-Apps sind das vor allem lange Aufgaben beim Routenwechsel, späte Hauptbilder und Platzhalter ohne feste Maße. Für Anwendungen mit Login und Dashboard gelten die Ansätze unserer Seite PageSpeed für SaaS-Anwendungen, für Shopware-Shops kommen Store API und Caching dazu. Ziel ist, dass Ihre Werte zum Zeitpunkt der Umstellung aus echten Verbesserungen kommen und nicht nur aus der neuen Messart.