Eine Kategorieseite lädt, der Nutzer klickt auf ein Produkt, filtert, legt in den Warenkorb und geht zur Kasse: gefühlt fünf Seiten, technisch ein einziger Dokument-Load. Genau dort endet die Messung. Die Core Web Vitals werden relativ zur aktuellen Top-Level-Navigation erhoben, und ein Routen-Wechsel per History-API hat keinen Einfluss darauf, wie die Metriken gemessen werden - die Werte werden nicht zurückgesetzt (Quelle: web.dev). LCP misst damit den ersten Bildaufbau und danach nie wieder, während CLS und INP über den gesamten Seiten-Lebenszyklus weiterlaufen (Quelle: web.dev). CrUX aggregiert zusätzlich nur nach Origin oder nach der URL zum Ladezeitpunkt und kann nicht nach SPA-Route gruppieren (Quelle: web.dev). Das Ergebnis kennen viele Betreiber von Single-Page-Apps: passable Felddaten bei schlechtem Bauchgefühl. Chrome schließt diese Lücke mit der Soft-Navigations-API, die ab Chrome 151 ungeflaggt für alle Sites bereitsteht (Quelle: Chrome for Developers). Dieser Beitrag zeigt, wie die Erkennung arbeitet, welche Eintragstypen sie liefert und wie sich LCP, INP und CLS damit in Route-Abschnitte schneiden lassen - die Grundlage jeder belastbaren Core-Web-Vitals-Optimierung.
Warum SPAs nur den ersten Load melden
Die Messlücke ist kein Bug, sondern eine Folge der Definition. Alle Core-Web-Vitals-Metriken beziehen sich auf die aktuelle Top-Level-Navigation der Seite (Quelle: web.dev). Eine harte Navigation - also ein echter Dokument-Load - setzt diesen Bezugspunkt neu. Ein Routen-Wechsel in einer Single-Page-App tut das nicht: Der Browser tauscht DOM-Inhalte aus und ändert die URL per pushState oder replaceState, aber das Dokument bleibt dasselbe. Für die Messschicht ist deshalb weiterhin der allererste Aufruf maßgeblich.
Für jede Metrik hat das eine eigene Konsequenz. LCP gehört zum Seitenaufbau, der die Navigation ausgelöst hat - klickt sich ein Nutzer von der Kategorie in die Produktdetailseite, entsteht kein neuer LCP-Kandidat, obwohl sich der komplette sichtbare Inhalt austauscht. CLS akkumuliert seit April 2021 nur noch über das schlechteste Verschiebungsfenster, wird aber nach einem Routen-Wechsel eben nicht zurückgesetzt, wie es bei einem vollen Seitenaufbau in einer klassischen Multi-Page-Architektur der Fall wäre (Quelle: web.dev). INP misst die Interaktionslatenz über den gesamten Seiten-Lebenszyklus (Quelle: web.dev) - in einer langlebigen SPA also über Minuten und Dutzende Routen hinweg, zusammengefasst in einem einzigen Wert.
Dazu kommt die Aggregationsebene. CrUX fasst Daten nach Origin oder nach Seiten-URL zusammen, wobei die URL zum Ladezeitpunkt gilt - eine Gruppierung nach SPA-Route ist damit nicht möglich (Quelle: web.dev). Alles, was ein Nutzer nach dem Einstieg erlebt, landet rechnerisch auf der Einstiegs-URL. Wer wissen will, ob der Checkout langsamer ist als die Kategorieseite, findet die Antwort in den Felddaten schlicht nicht. Eine saubere technische Analyse muss diese Lücke deshalb aktiv adressieren, statt sie zu übergehen.
Interessant ist die Verzerrungsrichtung: Sie ist nicht durchgängig schmeichelhaft. Der einmalige LCP kann einen guten Wert liefern, während die eigentliche Route-Performance nie geprüft wird - das schmeichelt. INP und CLS sammeln dagegen über die ganze Sitzung und werden vom schlechtesten Moment dominiert - das bestraft. Google merkt zudem an, dass an der SPA-Architektur nichts liegt, das eine Seite grundsätzlich langsamer machen würde; gut optimierte Multi-Page-Architekturen profitieren aber davon, dass Folgeaufrufe aus dem Cache kommen und einen größeren Anteil der Verteilung am 75. Perzentil ausmachen (Quelle: web.dev). Wie CrUX und eigenes Monitoring generell auseinanderlaufen, vertieft der Beitrag zu Felddaten aus CrUX und eigenem RUM.
Abgrenzung: Messlücke, nicht Framework-Tuning
Wie Chrome eine Soft Navigation erkennt
Chrome erkennt eine Soft Navigation nicht per Framework-Hook, sondern heuristisch aus dem beobachtbaren Verhalten der Seite. Drei Bedingungen müssen zusammenkommen: Die Navigation wird durch eine Nutzeraktion ausgelöst, sie führt zu einer für den Nutzer sichtbaren URL-Änderung, und die Interaktion resultiert in einem sichtbaren Paint (Quelle: Chrome for Developers). Erst wenn alle drei erfüllt sind, gilt der Vorgang als Navigation.
Die Spezifikation formuliert dasselbe technischer: Eine Soft Navigation ist eine nutzerinitiierte Same-Document-Navigation aus einer vertrauenswürdigen Interaktion, einer dynamischen DOM-Aktualisierung und einer Same-Document-History-Änderung über die History-API oder die Navigation-API (Quelle: WICG Soft Navigations). Mindestens eine inhaltliche Aktualisierung der Seite muss beobachtet werden; die übrigen Feinheiten überlässt der Entwurf ausdrücklich der Anwendung (Quelle: WICG Soft Navigations). Im letzten Origin-Trial kam replaceState als zusätzlicher Auslöser hinzu (Quelle: Chrome for Developers Blog) - relevant für alle Apps, die Filter- und Sortierzustände in die URL schreiben, ohne einen History-Eintrag anzulegen.
Nutzer-Interaktion
Ein vertrauenswürdiger Klick oder Tap startet den Vorgang. Programmatische Routen-Wechsel ohne Nutzeraktion - etwa ein Redirect nach dem Laden - erfüllen die Bedingung nicht.
Sichtbare URL-Änderung
Die Adresse ändert sich für den Nutzer sichtbar, über die History-API oder die Navigation-API. Reines clientseitiges Filtern ohne URL-Wechsel zählt nicht als Navigation.
Sichtbarer Paint
Die Interaktion führt zu einer inhaltlichen Aktualisierung, die tatsächlich gezeichnet wird. Ein reiner Zustandswechsel ohne sichtbares Ergebnis bleibt unerkannt.
Die Attribution über asynchrone Grenzen hinweg ist der technisch anspruchsvolle Teil. Eine Interaktion löst einen fetch aus, dessen Antwort später das DOM verändert - die Heuristik muss diese Änderung auf die ursprüngliche Interaktion zurückführen. Chrome nutzt dafür intern eine Task-Attribution, die den Interaktionskontext über fetch und setTimeout hinweg propagiert (Quelle: WICG Soft Navigations). Ein rein zeitbasierter Ansatz wurde verworfen, weil Nutzer alle paar Sekunden interagieren und Zeitfenster die langsamen Ausreißer von vier bis zehn Sekunden gerade nicht erfassen würden (Quelle: WICG Soft Navigations). Für die Frontend-Optimierung ist das die entscheidende Nachricht: Die Kette Interaktion, Datenabruf, Rendering wird als Einheit betrachtet.
Die neuen Eintragstypen und die navigationId
Beobachtbar sind zwei neue Eintragstypen: soft-navigation wird nach jeder erkannten Soft Navigation ausgegeben, interaction-contentful-paint nach Interaktionen, die einen inhaltlichen Paint verursachen (Quelle: Chrome for Developers). Ein soft-navigation-Eintrag trägt den Namen der neuen URL, eine navigationId als eindeutige Referenz, die interactionId der auslösenden Interaktion, startTime als Zeitpunkt der Interaktion sowie paintTime und presentationTime als FCP dieser Navigation; die Methode getLargestInteractionContentfulPaint() liefert den größten zugehörigen Paint-Eintrag (Quelle: Chrome for Developers).
Der eigentliche Hebel für das Route-Schneiden ist aber die navigationId. Sie wird an sieben Eintragstypen angehängt: first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event und layout-shift (Quelle: Chrome for Developers). Damit lässt sich jeder einzelne Layout-Shift und jedes Interaktions-Event einer konkreten Route zuordnen - genau die Zuordnung, die bisher fehlte. Ein Detail des letzten Origin-Trials ist dabei wichtig: interaction-contentful-paint wurde von den Soft Navigations entkoppelt und wird nun für alle Interaktionen ausgegeben, nicht nur für navigierende; ergänzend kam das Attribut largestInteractionContentfulPaint am SoftNavigationEntry hinzu (Quelle: Chrome for Developers Blog).
| Aspekt | Harte Navigation | Soft Navigation |
|---|---|---|
| Zeitursprung | Dokument-Load setzt den Bezugspunkt neu | startTime des Eintrags muss selbst abgezogen werden |
| TTFB | echter Wert aus der Navigation Timing | wird als 0 berichtet (Quelle: Chrome for Developers) |
| LCP | größter Paint des Dokument-Loads | über getLargestInteractionContentfulPaint() |
| CLS | startet bei 0 | wird an der Route-Grenze auf 0 zurückgesetzt |
| INP | über den gesamten Lebenszyklus | je Route bis zur nächsten Navigation |
| CrUX-Meldung | etabliert, Grundlage der Bewertung | noch nicht entschieden (Quelle: Chrome for Developers) |
Die Zeitrechnung ist die häufigste Stolperfalle. Die Timings werden weiterhin relativ zur ursprünglichen harten Navigation zurückgegeben - wer Werte relativ zur Route braucht, muss die startTime der Soft Navigation selbst abziehen (Quelle: Chrome for Developers). Wird das vergessen, wachsen die LCP-Werte mit der Sitzungsdauer, und die dritte Route sieht dramatisch schlechter aus als die erste, ohne dass sich etwas verschlechtert hätte. Für Teams, die ohnehin an schnellen Übergängen arbeiten, lohnt der Blick auf Speculation Rules für sofortige Navigation - dort geht es um das Beschleunigen, hier um das Messen.
LCP, INP und CLS je Route schneiden
Das Ziel ist ein Datensatz, in dem jede Route einen eigenen Satz Kernmetriken trägt - so, als wäre sie eine eigene Seite. Für LCP liefert getLargestInteractionContentfulPaint() am Soft-Navigation-Eintrag den Ausgangspunkt; die zugehörigen interaction-contentful-paint-Einträge werden über die interactionId gematcht, ausdrücklich nicht über die navigationId (Quelle: Chrome for Developers). Anschließend wird die passende Soft-Navigation-Startzeit abgezogen (Quelle: Chrome for Developers).
Für CLS und INP gilt eine einfachere Regel: Beide werden bei jeder Soft Navigation auf 0 initialisiert und bis zur nächsten Navigation gemessen (Quelle: Chrome for Developers). Praktisch heißt das, dass die Metriken der vorherigen Route finalisiert werden, sobald eine neue Soft Navigation eintrifft (Quelle: Chrome for Developers). Damit wird aus dem Sitzungswert eine Folge von Routen-Werten - und aus einem diffusen INP über zwanzig Minuten wird die Erkenntnis, dass ausgerechnet der Warenkorb-Übergang klemmt. Wie sich INP überhaupt beheben lässt, wenn der Schuldige gefunden ist, behandelt der Beitrag zu INP und Interaction to Next Paint.
Einträge an der Route-Grenze
navigationId tragen (Quelle: Chrome for Developers). Ein Layout-Shift, der während des Übergangs entsteht, landet also nicht zwingend dort, wo man ihn erwartet. Wer Route-Werte in Sekundenbruchteilen auswertet, sollte diese Unschärfe kennen und Grenzfälle bewusst behandeln, statt sie als Messfehler abzutun.Der CLS-Fall verdient besondere Aufmerksamkeit, weil er die Verzerrung am deutlichsten zeigt. Ohne Route-Schnitt trägt eine SPA den schlechtesten Verschiebungsburst der gesamten Sitzung mit sich - unabhängig davon, auf welcher Route er entstand. Mit Route-Schnitt bleibt er dort, wo er hingehört. Das ändert die Priorisierung grundlegend, weil plötzlich sichtbar wird, welches Template das Problem verursacht. Die Mechanik der Verschiebungen selbst und ihre typischen Ursachen behandelt der Beitrag zu Cumulative Layout Shift vermeiden.
Messung mit dem PerformanceObserver aufsetzen
Der Einstieg ist unspektakulär: Ein PerformanceObserver auf den Typ soft-navigation mit buffered: true liefert auch bereits ausgegebene Einträge nach (Quelle: Chrome for Developers). Wichtig ist die Feature-Erkennung, damit ältere Browser sauber durchlaufen - dafür prüft man PerformanceObserver.supportedEntryTypes auf soft-navigation oder alternativ 'SoftNavigationEntry' in window (Quelle: Chrome for Developers).
// Soft Navigations beobachten und Route-Abschnitte bilden
let current = null;
new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (current) finalise(current); // vorherige Route abschließen
current = {
id: entry.navigationId,
url: entry.name,
start: entry.startTime, // neuer Zeitursprung
lcp: 0, cls: 0, inp: 0
};
const icp = entry.getLargestInteractionContentfulPaint();
if (icp) current.lcp = icp.startTime - entry.startTime;
}
}).observe({ type: 'soft-navigation', buffered: true });
new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (!current || entry.navigationId !== current.id) continue;
if (!entry.hadRecentInput) current.cls += entry.value;
}
}).observe({ type: 'layout-shift', buffered: true });Ein Detail entscheidet über die Tauglichkeit in langlebigen Apps: Der Abruf per getEntriesByType ist auf die ersten 50 gepufferten Einträge begrenzt - deshalb ist ein Observer, der Einträge laufend entgegennimmt, die empfohlene Methode und für Apps mit mehr als 50 Soft Navigations notwendig (Quelle: Chrome for Developers). Wer eine Anwendung betreibt, in der Nutzer über Stunden dutzende Routen durchlaufen, sollte also gar nicht erst mit periodischen Abfragen anfangen. Für SaaS-Anwendungen mit langen Sitzungen ist das der Normalfall, nicht die Ausnahme.
- Observer auf
soft-navigationregistrieren, nicht periodisch abfragen - wegen des Limits von 50 gepufferten Einträgen (Quelle: Chrome for Developers). -
startTimeder Soft Navigation von allen Timings abziehen, da Werte relativ zur harten Navigation zurückkommen (Quelle: Chrome for Developers). - CLS und INP an jeder Route-Grenze auf 0 setzen und die Vorgänger-Route finalisieren (Quelle: Chrome for Developers).
- LCP-Einträge über die
interactionIdmatchen, nicht über dienavigationId(Quelle: Chrome for Developers). - TTFB je Soft Navigation als 0 behandeln und im Reporting nicht als Verbesserung ausweisen (Quelle: Chrome for Developers).
- Feature-Erkennung voranstellen, damit Browser ohne Unterstützung unverändert weiterlaufen (Quelle: Chrome for Developers).
Beim Ausspielen der Daten gilt dieselbe Disziplin wie bei jedem Monitoring: sparsam, gebündelt und ohne die Seite auszubremsen. Route-Werte werden erst gesendet, wenn die Route abgeschlossen ist, und beim Verlassen der Seite gesammelt nachgereicht. Dass sich Nutzdaten dabei stark komprimieren lassen, zeigt der Beitrag zu Shared Dictionaries und Delta-Kompression - relevant, sobald Route-Telemetrie in Volumen geht.
Typische Fehldeutungen in der Praxis
Die häufigste Enttäuschung: Die Heuristik greift nicht, wo man sie erwartet. Reines clientseitiges Filtern ohne URL-Wechsel und ohne sichtbaren Paint wird nicht als Navigation erkannt (Quelle: Chrome for Developers). Eine Facettensuche, die nur die Trefferliste austauscht, aber die Adresse unangetastet lässt, bleibt also ein stiller Vorgang - fachlich ist es für den Nutzer ein Seitenwechsel, technisch nicht. Chrome benennt das offen: Die Definition kann falsch-positive Ergebnisse liefern, die Nutzer nicht als Navigation empfinden würden, ebenso wie falsch-negative, bei denen der Nutzer sehr wohl von einem Seitenwechsel ausgeht, die Kriterien aber nicht erfüllt sind (Quelle: Chrome for Developers).
Die Heuristik ist eine Näherung, kein Vertrag
Ein zweiter Fallstrick betrifft die Referenzen auf Elemente. Wartet man mit der Auswertung zu lange, etwa bis zum Entladen der Seite, kann die verschachtelte LCP-Element-Referenz bereits vom Garbage Collector eingesammelt, aus dem DOM entfernt oder abgehängt sein und null zurückgeben (Quelle: WICG Soft Navigations). Wer das auslösende Element protokollieren will, muss es am Ende der Route auslesen, nicht am Ende der Sitzung.
Der dritte Punkt ist organisatorisch. Route-Werte sind nicht mit den bisherigen Sitzungswerten vergleichbar - eine SPA, die plötzlich saubere Werte je Route ausweist, hat sich nicht verbessert, sondern misst anders. Wer den Umstieg macht, sollte einen Stichtag setzen, beide Sichten eine Zeit lang parallel führen und nicht der Versuchung erliegen, den Wechsel als Erfolg zu verkaufen. Was ein Laborwerkzeug dazu beitragen kann und was nicht, ordnet ein Lighthouse-Audit ein: Es misst den Dokument-Load, nicht den Routen-Weg.
Was der Chrome-Stand zu CrUX offenlässt
Hier ist Nüchternheit angebracht. Der Chrome-Stand ist eindeutig: Wie Soft Navigations nach dem Launch in CrUX berichtet werden, ist noch zu entscheiden (Quelle: Chrome for Developers). Der finale Origin-Trial diente ausdrücklich der Bewertung der API und nicht der Frage, wie die Daten in CrUX oder in Werkzeugen genutzt werden - das werde entschieden, wenn man mit der API zufrieden sei und sie außerhalb des Origin-Trials starte (Quelle: Chrome for Developers Blog). Der Trial lief von Chrome 147 bis Chrome 149; ab Chrome 151 ist die Funktion ungeflaggt für alle Sites verfügbar (Quelle: Chrome for Developers, Chrome for Developers Blog).
Daraus folgt eine unbequeme, aber wichtige Trennung: Die Route-Messung ist ab Chrome 151 im eigenen Monitoring möglich, ein Effekt auf die rankingrelevante Bewertung ist damit nicht verbunden. Wer die API einführt, gewinnt Erkenntnis über den echten Nutzerweg - nicht automatisch bessere Felddaten in der Search Console. Das ist kein Argument gegen die Einführung, sondern eines für ehrliche Erwartungen.
Auch die Standardisierung steht am Anfang. Die Arbeit läuft in der WICG als Inkubation, Chromium hat eine experimentelle Umsetzung, während für Gecko und WebKit noch keine öffentlichen Signale vorliegen (Quelle: WICG Soft Navigations). Wer heute misst, misst zunächst in Chrome - was der Abdeckung von CrUX entspricht, aber eben nicht der gesamten Nutzerbasis. Das Web Almanac ordnet die Richtung ein: Moderne Single-Page-Websites nutzen oft JavaScript-basierte Navigationen, und die Unterstützung für Soft Navigations soll die Erfassung dieser seiteninternen Übergänge verbessern und ein genaueres Bild liefern (Quelle: HTTP Archive Web Almanac 2025).
Wie genau Soft Navigations in CrUX berichtet werden, sobald die Funktion gestartet ist, muss noch entschieden werden.
Der Kontext hilft bei der Einordnung des Aufwands. 2025 erreichten 48 Prozent der Mobile-Websites und 56 Prozent der Desktop-Websites gute Core Web Vitals (Quelle: HTTP Archive Web Almanac 2025). Beim LCP waren es 62 Prozent mobil und 74 Prozent auf dem Desktop, beim CLS 81 Prozent mobil und 72 Prozent auf dem Desktop (Quelle: HTTP Archive Web Almanac 2025). Beim INP liegen die Werte mit 77 Prozent mobil und 97 Prozent auf dem Desktop am höchsten (Quelle: HTTP Archive Web Almanac 2025) - ausgerechnet jene Metrik, die in SPAs über die ganze Sitzung läuft und deren Route-Bezug bislang fehlt. Wie sich die Schwellen und Bewertungsregeln insgesamt entwickelt haben, fasst der Beitrag zu den Core Web Vitals 2026 zusammen. Dass zusätzlich KI-Crawler messbar Last erzeugen und damit die Serverseite der Gleichung verschieben, behandelt der Beitrag zur Last durch KI-Crawler.
Von der Route-Messung zur Optimierung
Messen ist kein Selbstzweck. Der Wert der Soft-Navigations-API entsteht erst, wenn aus Route-Werten Entscheidungen werden. Der Ablauf ist immer derselbe: Route-Messung sauber aufsetzen, die entstehenden LCP-, INP- und CLS-Werte je Route über einige Wochen sammeln, die Routen nach Wirkung sortieren - Traffic mal Abstand zum Schwellenwert - und dann gezielt an den zwei, drei Templates arbeiten, die den Unterschied machen.
In der Praxis fallen dabei fast immer dieselben Muster auf: Ein Routen-Übergang hält am Datenabruf fest, statt eine Zwischenansicht zu zeichnen. Ein Template lädt sein Hauptbild erst nach dem Framework-Code. Ein Filter schiebt die Trefferliste nach unten, weil die Höhe nicht reserviert ist. Keines dieser Probleme ist exotisch - sie waren nur unsichtbar, solange alle Routen auf einen Sitzungswert zusammenfielen. Genau dieses Sichtbarmachen ist der Zweck einer belastbaren Performance-Analyse.
Wir setzen die Route-Messung auf, interpretieren die pro Route entstehenden LCP-, INP- und CLS-Werte und leiten daraus die Maßnahmen ab - vom Ladeverhalten der Templates über die Interaktionslatenz bis zur Stabilität des Layouts beim Routen-Wechsel. Dass die Ergebnisse anschließend belegbar sind statt behauptet, ist der eigentliche Punkt: Erst der Route-Schnitt macht aus einem diffusen Sitzungswert eine Aussage, mit der sich arbeiten lässt. Wie dieses Vorgehen im Detail aussieht, zeigen unsere Leistungen rund um Web-Performance.
Quellen und Studien
soft-navigation und interaction-contentful-paint, Felder des SoftNavigationEntry, navigationId an sieben Eintragstypen, TTFB als 0, CLS- und INP-Reset an der Route-Grenze, Timings relativ zur harten Navigation, Limit von 50 gepufferten Einträgen, Feature-Erkennung, Chrome 151 ungeflaggt, offene CrUX-Meldung); Chrome for Developers Blog - Final Soft Navigations origin trial (Origin-Trial von Chrome 147 bis Chrome 149, Entkopplung von InteractionContentfulPaint, replaceState als Auslöser, Attribut largestInteractionContentfulPaint, Zweck des Trials); web.dev (Google) - How SPA architectures affect Core Web Vitals (Messung relativ zur Top-Level-Navigation, kein Reset bei Routen-Wechseln, CLS-Verhalten gegenüber Multi-Page-Architekturen, INP über den gesamten Lebenszyklus, CrUX-Aggregation nach Origin oder Lade-URL); WICG Soft Navigations Specification (Definition der Same-Document-Navigation, Kriterien, Task-Attribution über asynchrone Grenzen, Garbage-Collection der LCP-Element-Referenz, Inkubationsstand, Signale von Gecko und WebKit); HTTP Archive Web Almanac 2025 (Anteile guter Core Web Vitals nach Gerät und Metrik, Einordnung JavaScript-basierter Navigationen). Stand der Angaben: Juli 2026.