Chrome 151’s Soft Navigations API ermöglicht es Single-Page-Apps (SPAs) endlich, Core Web Vitals für jede In-App-Navigation zu melden, aber Googles CrUX-Datensatz zeichnet immer noch nur den ersten Hard Load auf, was Entwickler mit zwei unterschiedlichen Performance-Bildern zurücklässt.

Warum SPA-Metriken bisher hinterherhinkten

Core Web Vitals – Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) und Cumulative Layout Shift (CLS) – wurden im Hinblick auf Hard Navigations definiert. Eine Hard Navigation lädt ein komplett neues Dokument und verwirft den Zustand der vorherigen Seite.

SPAs, die mit React, Vue, Next.js oder ähnlichen Frameworks erstellt wurden, lösen selten Hard Navigations aus. Das Klicken auf einen Link aktualisiert die URL über die History API, lädt Daten im Hintergrund und tauscht Inhalte aus, ohne die Seite vollständig neu zu laden. Die bestehende Performance API erfasst nur den initialen Seitenaufruf, sodass LCP und INP die Latenz, die Nutzer beim Wechsel von einer Route zur nächsten erleben, nie erfassen.

Dieser blinde Fleck verzerrt Dashboards, die Daten aus der Performance Timeline oder Googles Chrome User Experience Report (CrUX) beziehen. Diese zeigen oft einen hervorragenden LCP für die „Shell“-Seite an, ignorieren jedoch langsamere Ladezeiten tiefer in der App, was ein falsches Bild der Performance-Gesundheit vermittelt.

Chromes Soft Navigations API

Chrome 151 hat die Soft Navigations API eingeführt, eine Reihe von Heuristiken, die bestimmte SPA-Interaktionen als echte Navigationen behandeln. Die API achtet auf drei Signale:

  • Eine benutzergesteuerte Interaktion (Klick, Tippen, Tastaturereignis)
  • Eine URL-Änderung über die History API
  • Anschließende Paint-Events, die neue Inhalte rendern

Wenn alle drei zutreffen, protokolliert Chrome eine Soft Navigation in der Performance Timeline, und die Core Web Vitals werden für diesen Übergang genau wie bei einer Hard Navigation berechnet. Die Open-Source-Bibliothek web-vitals hat am 21. Juli die Unterstützung hinzugefügt, sodass Entwickler diese Zahlen bereits mit der API abrufen können, die sie ohnehin nutzen.

In der Praxis sehen Sie nun einen LCP-Wert für jeden Routenwechsel, einen INP, der die tatsächliche Latenz der letzten Benutzereingabe widerspiegelt, und einen CLS, der Layout-Shifts nach einer Soft Navigation erfasst.

Der Datensplit: Chrome vs. CrUX

Googles CrUX (Chrome User Experience Report) bildet die Grundlage für PageSpeed Insights, die Search Console und indirekt auch für Ranking-Signale. CrUX aggregiert nach wie vor nur Daten von Hard Navigations.

Infolgedessen erhält man zwei konsistente, aber unterschiedliche Datenströme:

  • Interne Tools, die die Performance Timeline auslesen, zeigen nun LCP, INP und CLS auf Routenebene an und bieten so eine realistische Sicht darauf, was Nutzer in einer SPA erleben.
  • Googles öffentliche Datensätze zeigen weiterhin nur Metriken für den ersten Seitenaufruf an, was die Basis für die Berichte der Search Console und die Referenzwerte der Google-Ranking-Algorithmen ist.

Beide sind korrekt; sie messen lediglich unterschiedliche Zeitpunkte. Sich ausschließlich auf die Search Console zu verlassen, kann Performance-Regressionen maskieren, die nach dem initialen Laden auftreten, während interne Dashboards allein nicht den Basiswert widerspiegeln, den Google für SEO verwendet.

Worauf Entwickler achten müssen

  • Browser-Unterstützung – Die Soft Navigations API existiert heute nur in Chromium-basierten Browsern. Safari und Firefox verfügen über kein Äquivalent, daher müssen Sie eine Fallback-Logik für einen Teil Ihrer Nutzer bereithalten.
  • Heuristische Grenzen – Die API entscheidet anhand eines Satzes von Hinweisen über eine Soft Navigation. Wenn Ihre App Inhalte aktualisiert, ohne die URL zu ändern (z. B. Modal-Overlays oder Infinite Scroll), erkennt die API diese Übergänge möglicherweise nicht, was zu Lücken in den Daten führt.
  • Testen vor Vertrauen – Da die Erkennung heuristisch erfolgt, sollten Sie eine Reihe von realen Interaktionen in Ihrer App durchführen und die gemeldeten Metriken mit manuellen Zeitmessungen vergleichen (z. B. mit performance.mark). Erst nach Bestätigung der Genauigkeit sollten Sie Optimierungsentscheidungen auf Basis der neuen Zahlen treffen.

Fazit

Chrome 151 gibt SPA-Entwicklern die lang ersehnte Möglichkeit, LCP, INP und CLS für jeden Routenwechsel innerhalb der App zu messen, aber Googles Ranking-Daten spiegeln nach wie vor nur den ersten Hard Load wider. Bis CrUX aufholt, müssen Teams mit zwei parallelen Datensätzen jonglieren: einem, der die wahre Nutzererfahrung wiedergibt, und einem anderen, der die Suchrankings beeinflusst. Die Balance zwischen beiden zu finden – und sich auf eine breitere Browser-Unterstützung vorzubereiten – wird entscheidend sein, um Performance-optimierte SPAs in einem wettbewerbsintensiven Web-Ökosystem zu behaupten.