Neuer Ursprungstest für die Soft Navigation

Barry Pollard
Michal Mocny

Veröffentlicht am 31. Juli 2025

In Chrome 139 wird ein neuer Ursprungstest für die Soft Navigations API eingeführt, mit der wir bereits experimentiert haben. Mit diesem Ursprungstest können Websites die API auf ihrer Website mit echten Nutzern testen, um sie in der Praxis zu erproben und dem Chrome-Team Feedback zu geben.

Was sind Soft Navigations?

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 dann in der Adressleiste aktualisiert (mit einem Verlaufsstatus, der Soft Navigations vorwärts und rückwärts ermöglicht). Für den Nutzer sehen diese genauso aus wie herkömmliche Navigationsvorgänge. Für den Browser ist die Seite jedoch weiterhin die Originalseite.

Warum die Soft Navigation API erforderlich ist

Die Soft Navigations API ist eine vorgeschlagene API, mit der sogenannte „Soft Navigations“ heuristisch erkannt werden können, wie sie von Websites mit Single Page Application (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 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 Messung von Core Web Vitals für SPAs zu ermöglichen. Core Web Vitals werden sowohl vom Browser (zur Darstellung in Tools wie dem Bericht zur Nutzererfahrung in Chrome) als auch von JavaScript-Bibliotheken für Real User Monitoring (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 (Event Timing API bzw. Layout Instability API), die über einen beliebigen Zeitraum gemessen werden können, um die INP- und CLS-Messwerte zu berechnen. Andere Messwerte wie Largest Contentful Paint (LCP) werden jedoch nur vom Browser ausgegeben – basierend auf Seitennavigationen und nach der Interaktion abgeschlossen.

Core Web Vitals für SPAs mit der Soft Navigation API messen

In der ersten Iteration der Soft Navigation API wurden die Heuristiken für Soft Navigation mit dem Zurücksetzen von LCP gekoppelt. Nach dem Zurücksetzen kann LCP für Soft Navigations für neue inhaltliche Paints noch einmal ausgegeben werden. So lässt sich dieser Messwert für Soft Navigations messen.

Bei dieser neuesten Version wird ein anderer Ansatz verfolgt und diese Konzepte werden in die Soft Navigation API und einen neuen Leistungseintrag für „Interaction to Contentful Paint“ entkoppelt. Der Eintrag interaction-contentful-paint misst das „Contentful Paint“ nach Interaktionen. Derzeit wird dieses Ereignis nur für Soft Navigations ausgegeben. Wenn es für alle Interaktionen aktiviert ist, sind jedoch auch andere Anwendungsfälle als LCP möglich.

Außerdem wurde für jeden der Leistungsdatensätze largest-contentful-paint, interaction-contentful-paint, event-timing und layout-shift ein Identifier 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. Durch die Einbeziehung der Navigation mit dem Eintrag ist es viel einfacher, Core Web Vitals für die angegebene URL zu messen, ohne dass die Zeiten für Leistungseinträge mit den Zeiten für Soft-Navigationseinträge abgeglichen werden müssen.

Warum eine Heuristik?

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

  • Es findet eine nutzerbasierte Interaktion statt (URL-Aktualisierungen ohne Nutzerinteraktion werden nicht berücksichtigt).
  • … was zu einer DOM-Änderung und einem Rendervorgang 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 zu „emittieren“ oder auf der Navigation API aufzubauen. So wird unabhängig vom Framework oder der Art und Weise, wie ein Entwickler es verwendet, ein einheitliches Verständnis davon ermöglicht, was eine Soft-Navigation ausmacht.

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, z. B. zu Beginn der Interaktion, erst am Ende, wenn sie abgeschlossen ist, oder in einem beliebigen Zwischenzustand.

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

Frameworks und Entwickler können die Heuristik 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 zu erfassen. Wir empfehlen jedoch, die Core Web Vitals mit der Heuristik zu verwenden, um Messungen auf verschiedenen Websites zu ermöglichen.

Hilfe beim Testen der Soft Navigation API

Wir benötigen Ihre Hilfe beim Testen der Soft Navigations API, um zu prüfen, ob die Heuristik Ihren Erwartungen entspricht, wann eine Soft Navigation stattgefunden hat. Gibt es Fälle, in denen die API keine Soft Navigations meldet, obwohl Sie der Meinung sind, dass sie stattgefunden haben? Wird die API bei wiederholten Navigationsvorgängen aufgerufen, die Sie nicht als Soft-Navigationsvorgänge betrachten?

Probleme können beispielsweise auftreten, 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). Beide Fälle lassen sich dadurch erklären, dass die Heuristik nicht übereinstimmt. Das Chrome-Team ist damit einverstanden, diese Fälle nicht einzubeziehen, möchte aber von Webentwicklern wissen, ob sie damit einverstanden sind. Wir möchten insbesondere von Fällen hören, 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-Primitive den primären Anwendungsfall abdecken, 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. Wir bitten daher SPA-Entwickler und alle, die die Webleistung für diese Websites messen möchten, diese API auszuprobieren und uns mitzuteilen, wie sie für Sie funktioniert.

Testen

Die API kann lokal mit Chrome-Flags oder Befehlszeilenoptionen getestet werden. Außerdem kann sie mit dem Ursprungstest 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 Version der Web Vitals-Bibliothek für Soft Navigation verfügbar.

Feedback

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

Wenn Sie sich nicht sicher sind, machen Sie sich keine Sorgen. Wir freuen uns über Feedback an beiden Stellen und leiten Probleme gern an den richtigen Ort weiter.