Letzter Ursprungstest für Soft Navigations ab Chrome 147

Barry Pollard
Michal Mocny

Veröffentlicht am 20. April 2026

Chrome plant, die Soft Navigations API, mit der wir bereits experimentiert haben, im Laufe des Jahres einzuführen. Zur Vorbereitung darauf bieten wir ab Chrome 147 bis Chrome 149 einen weiteren Ursprungstest an. In diesem Test wird Feedback aus früheren Tests in die erwartete endgültige Form der API einbezogen. Wir empfehlen Websiteinhabern, die sich für diese Funktion interessieren, einen letzten Test der erwarteten endgültigen Form der API vor der Veröffentlichung durchzuführen.

Was sind Soft-Navigationen?

Bei einer „Soft Navigation“ wird ein Seitenaufruf (z. B. durch Klicken auf einen Link) von JavaScript abgefangen und der Inhalt der vorhandenen Seite wird aktualisiert, anstatt eine neue Seite zu laden. Die URL wird jedoch weiterhin in der Adressleiste aktualisiert. Für Nutzer sehen diese Übergänge wie herkömmliche Navigationen aus, aus Browsersicht ist die Seite jedoch weiterhin die ursprüngliche Seite.

Erforderlichkeit der Soft Navigation API

Die Soft Navigations API ist eine vorgeschlagene API zur Erkennung von Soft Navigations, die von Websites mit Single-Page-Anwendung (SPA) verwendet werden. Da bei einer Soft-Navigation keine tatsächliche Seitennavigation erfolgt, müssen bestimmte Aktionen, die normalerweise bei einer Navigation ausgeführt werden, manuell über JavaScript verwaltet werden. Einige Aktionen, z. B. die Verwaltung des Navigationsverlaufs, sind mit den aktuellen APIs möglich. Andere Aktionen wie Core Web Vitals erfassen sind für diese Navigationen jedoch nicht möglich.

Mit der Soft Navigation API können Soft Navigations beobachtet werden. Das JavaScript, das die Soft-Navigation initiiert (in der Regel ein JavaScript-Framework), weiß, wann eine Navigation erfolgt. Anderes JavaScript, das von der Website verwendet wird (z. B. Analytics-Scripts), und der Browser selbst wissen das jedoch nicht.

Core Web Vitals und SPAs

Einer der Hauptgründe für die Soft Navigation API ist, dass damit Core Web Vitals für SPAs gemessen werden können. Core Web Vitals werden sowohl vom Browser (zur Anzeige in Tools wie dem Bericht zur Nutzererfahrung in Chrome) als auch von Websiteinhabern mithilfe von RUM-Lösungen (Real User Monitoring) gemessen.

JavaScript-Frameworks können einige Aspekte der Core Web Vitals für SPAs messen. Insbesondere Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS) basieren auf Primitiven (Event Timing API bzw. Layout Instability API), die über eine beliebige Zeitspanne gemessen werden können, um diese Messwerte zu berechnen. Andere Messwerte wie Largest Contentful Paint (LCP) werden jedoch nur vom Browser ausgegeben – basierend auf Seitennavigationen und nach der Interaktion abgeschlossen.

Wie die API die Messung von Core Web Vitals für SPAs ermöglicht

Mit der Soft Navigation API werden zwei neue Leistungseinträge eingeführt:

  • Ein SoftNavigationEntry-Eintrag, der ausgegeben wird, wenn alle Anforderungen für Soft Navigation erfüllt sind. Dazu gehören ein interactionId für die Interaktion, die die Soft Navigation ausgelöst hat, eine eindeutige navigationId und ein name, das auf die neue URL festgelegt ist, sowie verschiedene Paint-Timings, mit denen sich der First Contentful Paint der Soft Navigation messen lässt.
  • Ein InteractionContentfulPaint-Eintrag, mit dem mehrere Contentful Paints mit zunehmender Größe nach Interaktionen gemessen werden können, um den LCP für Soft Navigations zu messen.

Diese neuen Einträge können mit einem PerformanceObserver mit den Typen soft-navigation und interaction-contentful-paint beobachtet werden.

Die API erweitert auch jeden der Leistungsdatensätze für largest-contentful-paint, interaction-contentful-paint, event-timing und layout-shift (und andere) um eine Kennung, navigationId, die die Navigation darstellt, für die der Eintrag gilt. Da PerformanceObservers Leistungseinträge erst beobachten, wenn die Seite inaktiv ist, kann einige Zeit zwischen dem Ereignis, das den Leistungseintrag erstellt hat, und der Beobachtung vergehen. Das gilt insbesondere, wenn die Seite sehr stark ausgelastet ist, z. B. bei Soft-Navigations. Mit diesem navigationId-Wert können Einträge der richtigen Navigation zugeordnet werden.

Einige interaction-contentful-paint-Einträge können vor und einige nach der Navigation erfolgen. Anstatt alle Paints zu erfassen, die zu einer Soft Navigation führen könnten, enthält der Eintrag soft-navigation einen Eintrag largestInteractionContentfulPaint, der den bis zu diesem Zeitpunkt größten Paint darstellt.

Zusammen ermöglichen sie die Messung der Core Web Vitals für:

  • LCP: largest-contentful-paint für den initialen Seitenaufbau und die neuen Einträge interaction-contentful-paint und soft-navigation für Soft-Navigations.
  • CLS: Verwenden Sie layout-shift-Einträge und segmentieren Sie sie anhand der soft-navigation-Einträge für Soft Navigations.
  • INP: Verwenden Sie event-Einträge und segmentieren Sie sie anhand der soft-navigation-Einträge für Soft Navigations.
  • FCP: first-contentful-paint für den anfänglichen Seitenaufbau und die Details zum Paint-Timing für die neuen soft-navigation-Einträge für Soft Navigations.

Weitere Informationen finden Sie in der Dokumentation zu Soft Navigations.

Wie werden Soft Navigations ausgelöst?

Die Soft Navigation API löst eine Soft Navigation aus, wenn Folgendes passiert:

  • Eine Nutzerinteraktion erfolgt.
  • … was dazu führt, dass Inhalte für den Nutzer sichtbar gerendert werden.
  • … und eine URL-Aktualisierung erfolgt.

Die API verfolgt diesen Ansatz, anstatt ein JavaScript-Framework eine Soft Navigation „ausgeben“ zu lassen oder auf der Navigation API aufzubauen. Das hat zwei Gründe:

  1. Erstens umfasst dies alle bestehenden SPA-Websites, ohne dass Änderungen an diesen Websites erforderlich sind.
  2. Zweitens wird so ein einheitliches Verständnis davon ermöglicht, was eine Soft Navigation ist, unabhängig davon, wie ein Framework oder Entwickler Navigationen behandelt.

Frameworks oder Entwickler können die URL für eine Soft Navigation auch ohne Nutzerinteraktion oder DOM-Aktualisierung aktualisieren, die Nutzer als Navigation betrachten würden. Sie können die URL auch zu verschiedenen Zeiten aktualisieren: zu Beginn der Interaktion, nur am Ende, wenn sie abgeschlossen ist, oder in einem beliebigen Zustand dazwischen.

Wenn die Erkennung von Soft-Navigations direkt in den Browser integriert wird, anstatt sich auf Frameworks und Entwickler zu verlassen, wird eine kanonische Definition geschaffen, die es ermöglicht, Core Web Vitals für Soft-Navigations im großen Maßstab zu messen und diese Messungen im großen Maßstab vergleichbar zu machen.

Frameworks und Entwickler können die Soft Navigations API auch ignorieren und die zugrunde liegenden Event Timing API, Layout Instability API und den neuen InteractionContentfulPaint-Leistungseintrag verwenden, um zusätzliche Leistungsmesswerte zu erfassen. Wir empfehlen jedoch, die API zur Messung der Core Web Vitals zu verwenden, um eine konsistente Messung auf allen Websites und in allen Tools zu ermöglichen.

Hilfe beim Testen der Soft Navigation API

Wir benötigen Ihre Hilfe, um die Soft Navigations API zu testen und festzustellen, ob sie Ihren Erwartungen entspricht, wann eine Soft Navigation stattfindet. Werden Soft Navigations von der API nicht gemeldet, obwohl sie Ihrer Meinung nach stattgefunden haben? Werden in der API umgekehrt zu viele Navigations gemeldet, die Sie nicht als Navigations betrachten?

Was hat sich seit dem letzten Ursprungstest geändert?

Die primäre Änderung in dieser neuesten Version besteht darin, InteractionContentfulPaint von den Soft-Navigationen zu entkoppeln, um andere Anwendungsfälle für diesen Leistungseintrag zu ermöglichen, und das zusätzliche Attribut largestInteractionContentfulPaint für SoftNavigationEntry.

Aus Website-Sicht umfasst die API jetzt auch replaceState als Soft-Navigationen, da wir Ihr Feedback erhalten haben, dass dies unter vielen Umständen als Navigation wichtig ist. Wir freuen uns, wenn Sie uns über weitere Fälle informieren, in denen die API keine Soft Navigation erkennt.

Außerdem haben wir unzählige weitere Verbesserungen an der Implementierung vorgenommen. Wenn Sie genau wissen möchten, was sich in der neuesten Version geändert hat, finden Sie im Änderungsprotokoll für Soft Navigations einen detaillierten Verlauf aller Änderungen.

Wir möchten, dass die API so nützlich wie möglich ist, und sind offen für weitere Änderungen, um dies zu erreichen. Änderungen lassen sich viel einfacher in die API implementieren, bevor sie eingeführt wird und Websites von einer Implementierung abhängig sind. Wir bitten daher SPA-Entwickler und alle, die die Webleistung für diese Websites messen möchten, diese API zu testen und uns Feedback dazu zu geben.

Testen

Die API kann lokal mit Chrome-Flags oder Befehlszeilenoptionen getestet werden. Außerdem können Sie die Funktion mit einem Ursprungstest in der Praxis testen. Weitere Informationen zu Ursprungstests

Weitere technische Details zur API, insbesondere wie die Core Web Vitals gemessen werden, finden Sie in unserer Dokumentation oder im GitHub-Repository.

Außerdem ist auf GitHub und npm eine experimentelle Version der Web-Vitals-Bibliothek mit Soft Navigation verfügbar.

Für einen einfacheren Test wird im Bereich Leistung der Chrome-Entwicklertools ab Chrome 145 die Soft Navigation in Leistungstraces angezeigt, auch ohne dass die Funktion aktiviert ist:

Eine Markierung für Soft-Nav im Bereich „Leistung“ mit einem Trace von youtube.com.

Feedback

Feedback zur API sollte als Probleme auf GitHub gemeldet werden. Fehler in der Chromium-Implementierung sollten im Chrome-Issue-Tracker gemeldet werden. Wenn Sie sich nicht sicher sind, in welche Kategorie das Feedback fällt, ist das kein Problem. Wir ziehen es vor, Feedback an einem der beiden Orte zu erhalten. Wir werden die Probleme an beiden Orten priorisieren und an den richtigen Ort weiterleiten.