Neuer Ursprungstest für die Soft Navigation

Barry Pollard
Michal Mocny

Veröffentlicht am 31. Juli 2025

Chrome startet ab Chrome 139 einen neuen Ursprungstest für die Soft Navigations API, mit der wir bereits experimentiert haben. Bei diesem Ursprungstest können Websites die API auf ihrer Website mit echten Nutzern testen, um sie in der Praxis zu testen und dem Chrome-Team Feedback zu geben.

Was sind Soft Navigations?

Bei einer Soft Navigation fängt JavaScript eine Navigation ab (z. B. durch Klicken auf einen Link) und aktualisiert den Inhalt auf der vorhandenen Seite, anstatt eine neue Seite zu laden. Die URL wird dann in der Adressleiste aktualisiert (mit einem Verlaufsstatus, der Soft Navigations zurück und vorwärts ermöglicht). Für den Nutzer sehen diese wie herkömmliche Navigationen aus, aber für den Browser ist die Seite immer noch die ursprüngliche Seite.

Warum die Soft Navigation API erforderlich ist

Die Soft Navigations API ist eine vorgeschlagene API, mit der heuristisch sogenannte „Soft Navigations“ erkannt werden können, wie sie von Single-Page-Anwendung-Websites (SPAs) 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 wie die Verwaltung des Navigationsverlaufs sind mit aktuellen APIs möglich. Andere Aktionen wie das Messen von Core Web Vitals 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. Andere JavaScript-Elemente und der Browser selbst wissen es jedoch nicht.

Core Web Vitals und SPAs

Einer der Hauptgründe für die Soft Navigation API ist die Möglichkeit, Core Web Vitals für SPAs zu messen. Core Web Vitals werden sowohl vom Browser (zur Anzeige in Tools wie dem Bericht zur Nutzererfahrung in Chrome) als auch von Real User Monitoring-JavaScript-Bibliotheken (RUM) gemessen.

JavaScript-Frameworks können einige Aspekte der Core Web Vitals messen. Insbesondere Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS) basieren auf Primitiven (der Event Timing API bzw. der Layout Instability API), die über einen beliebigen Zeitraum gemessen werden können, um die INP- und CLS-Messwerte zu berechnen. Da der Browser Largest Contentful Paint (LCP) jedoch basierend auf Seitennavigationen und ‑interaktionen meldet und abschließt, haben JavaScript-Frameworks nur Einblick in die anfängliche Ladeleistung für SPAs.

So ermöglicht die Soft Navigation API die Messung von Core Web Vitals für SPAs

In der ersten Iteration der Soft Navigation API wurden die Heuristiken für Soft Navigation mit dem Zurücksetzen von LCP kombiniert. Nach dem Zurücksetzen kann LCP für Soft Navigations für neue Contentful Paint-Ereignisse neu ausgegeben werden, sodass dieser Messwert für Soft Navigations gemessen werden kann.

In dieser neuesten Iteration wird ein anderer Ansatz verfolgt und diese Konzepte in die Soft Navigation API und einen neuen Leistungseintrag für Interaction to Contentful Paint entkoppelt. Der interaction-contentful-paint Eintrag misst den Contentful Paint nach Interaktionen. Derzeit wird dieser Eintrag nur für Soft Navigations ausgegeben. Wenn er für alle Interaktionen aktiviert ist, ergeben sich jedoch weitere potenzielle Anwendungsfälle über LCP hinaus.

Außerdem wurde für jeden der Leistungseinträge largest-contentful-paint, interaction-contentful-paint, event-timing und layout-shift ein Bezeichner für die Navigation hinzugefügt, auf die sich der Eintrag bezieht. Leistungseinträge werden nach dem Ereignis ausgegeben, das sie messen – in der Regel während der Leerlaufzeit. Das bedeutet, dass sich die URL häufig geändert hat, wenn der Leistungseintrag ausgegeben wird. Wenn die Navigation im Eintrag enthalten ist, ist es viel einfacher, Core Web Vitals für die angegebene URL zu messen, ohne die Zeiten der Leistungseinträge mit den Zeiten der Soft Navigation-Einträge abgleichen zu müssen.

Warum eine Heuristik?

Die Soft Navigation API betrachtet eine Soft Navigation, wenn Folgendes geschieht:

  • Es erfolgt eine nutzerbasierte Interaktion (URL-Aktualisierungen ohne Nutzerinteraktion werden nicht gezählt).
  • … die zu einer DOM-Änderung und einem Paint-Ereignis führt.
  • … und eine URL-Aktualisierung erfolgt.
  • URL-Aktualisierung, einschließlich einer Änderung des Verlaufs.

Die API verwendet diesen heuristischen Ansatz, anstatt einem JavaScript-Framework zu erlauben, eine Soft Navigation „auszugeben“ oder auf der Navigation API aufzubauen. So wird ein einheitliches Verständnis davon ermöglicht, was eine Soft Navigation ausmacht, unabhängig vom Framework oder davon, wie ein Entwickler es verwendet.

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

Anstatt sich auf Framework-Entscheidungen zu verlassen, wird die Erkennung von Soft Navigations in den Browser integriert. So werden kanonische Heuristiken erstellt (mit Ihrem Feedback aus diesem Ursprungstest), mit denen wir Core Web Vitals für Soft Navigations im großen Maßstab messen und solche Messungen im großen Maßstab vergleichbar machen können.

Frameworks und Entwickler können die Heuristiken der Soft Navigations API auch ignorieren und die zugrunde liegenden APIs für Event Timing, Layout Instability und Interaction to Contentful Paint verwenden, um zusätzliche Leistungsmesswerte nach Bedarf zu messen. Wir empfehlen jedoch, Core Web Vitals mit der Heuristik zu verwenden, um Messungen auf verschiedenen Websites zu ermöglichen.

Hilfe beim Testen der Soft Navigation API erforderlich

Wir benötigen Hilfe beim Testen der Soft Navigations API, um zu prüfen, ob die Heuristik Ihren Erwartungen entspricht, wann eine Soft Navigation erfolgt ist. Gibt es Fälle, in denen die API keine Soft Navigations meldet, obwohl Sie der Meinung sind, dass sie stattgefunden haben? Meldet die API im Gegenteil zu viele Navigationen, die Sie nicht als Soft Navigations betrachten?

Beispiele für Probleme sind, wenn eine URL mit replaceState aktualisiert wird, anstatt einen Verlauf hinzuzufügen, oder wenn eine Navigation erfolgt, die nicht vom Nutzer initiiert wurde (z. B. eine Abmeldung bei Zeitüberschreitung). In beiden Fällen werden die Heuristiken nicht erfüllt. Das Chrome-Team ist damit einverstanden, diese Fälle nicht zu berücksichtigen. Wir möchten jedoch von Webentwicklern hören, ob sie damit einverstanden sind. Wir möchten insbesondere von Fällen erfahren, in denen die Heuristiken erfüllt zu sein scheinen, die API die Soft Navigation aber trotzdem nicht erkennt.

Außerdem möchten wir wissen, ob diese API und das neue Interaction to Contentful Paint-Primitiv den primären Anwendungsfall erfüllt, nämlich die Messung der Core Web Vitals für SPAs zu ermöglichen.

Wir möchten, dass die API so nützlich wie möglich ist. Das ist viel einfacher, bevor sie eingeführt wird und Websites von einer Implementierung abhängig werden. Deshalb bitten wir SPA-Entwickler und alle, die an der Messung der Webleistung für diese Websites interessiert sind, diese API auszuprobieren und uns mitzuteilen, wie sie funktioniert.

Testen

Die API kann lokal mit Chrome-Flags oder Befehlszeilenoptionen getestet werden. Außerdem kann sie im Rahmen des Ursprungstests in der Praxis getestet werden.

Weitere technische Details zur API und insbesondere dazu, wie die Core Web Vitals gemessen werden, finden Sie in unserer Dokumentation oder im GitHub-Repository. Außerdem ist eine experimentelle Soft Navigation-Version der web-vitals-Bibliothek verfügbar.

Feedback

Wir freuen uns über Feedback zu diesem Test an folgenden Stellen:

Wenn Sie sich nicht sicher sind, machen Sie sich keine Sorgen. Wir freuen uns über Feedback an beiden Stellen und werden die Probleme an beiden Stellen priorisieren und an die richtige Stelle weiterleiten.