Experimentieren mit dem Messen der weichen Navigation

Barry Pollard

Michal Mocny

Veröffentlicht am 1. Februar 2023, zuletzt aktualisiert am 30. März 2026

Seit dem Start der Core Web Vitals-Initiative geht es darum, die tatsächliche Nutzerfreundlichkeit einer Website zu messen und nicht die technischen Details, die hinter der Erstellung oder dem Laden einer Website stehen. Die drei Core Web Vitals-Messwerte wurden als nutzerorientierte Messwerte entwickelt. Sie sind eine Weiterentwicklung der vorhandenen technischen Messwerte wie DOMContentLoaded oder load, mit denen Zeitangaben gemessen wurden, die oft nicht damit zusammenhingen, wie Nutzer die Leistung der Seite wahrnahmen. Daher sollte die Technologie, die zum Erstellen der Website verwendet wurde, keinen Einfluss auf die Bewertung haben, sofern die Website eine gute Leistung erbringt.

Die Realität ist immer etwas komplizierter als das Ideal und die beliebte Architektur für Single-Page-Anwendungen wurde von den Core Web Vitals-Messwerten nie vollständig unterstützt. Anstatt einzelne Webseiten zu laden, wenn der Nutzer auf der Website navigiert, verwenden diese Webanwendungen sogenannte „Soft Navigations“. Dabei werden die Seiteninhalte stattdessen durch JavaScript geändert. In diesen Anwendungen wird die Illusion einer herkömmlichen Webseite aufrechterhalten, indem die URL geändert und vorherige URLs in den Browserverlauf aufgenommen werden, damit die Schaltflächen „Zurück“ und „Vor“ wie erwartet funktionieren.

Viele JavaScript-Frameworks verwenden dieses Modell, aber jedes auf eine andere Weise. Da dies nicht dem entspricht, was der Browser traditionell als „Seite“ versteht, war die Messung bisher schwierig. Wo soll die Grenze zwischen einer Interaktion auf der aktuellen Seite und einer neuen Seite gezogen werden?

Das Chrome-Team beschäftigt sich schon seit einiger Zeit mit dieser Herausforderung und möchte eine Definition für „Soft-Navigation“ standardisieren und festlegen, wie die Core Web Vitals dafür gemessen werden können – ähnlich wie bei Websites, die in der herkömmlichen Architektur mit mehreren Seiten (Multi-Page Architecture, MPA) implementiert sind.

Wir haben die API basierend auf dem Feedback von Entwicklern zum letzten Origin Trial verbessert und bitten Entwickler nun, die neueste Version zu testen und Feedback zum Ansatz zu geben, bevor sie eingeführt wird. Wir sind ziemlich zuversichtlich, was die API in diesen Iterationen erreicht hat, und möchten sie noch in diesem Jahr einführen. Das hängt jedoch vom Feedback zu diesem neuesten Ursprungstest ab.

Was ist die Soft-Navigation?

Wir haben die folgende Definition für eine weiche Navigation entwickelt:

• Die Navigation wird durch eine Nutzeraktion initiiert.
• Die Navigation führt zu einer sichtbaren URL-Änderung für den Nutzer.
• Die Interaktion führt zu einem sichtbaren Rendern.

Bei einigen Websites können diese Heuristiken zu falsch positiven Ergebnissen führen (Nutzer würden nicht wirklich von einer „Navigation“ sprechen) oder zu falsch negativen Ergebnissen (Nutzer würden von einer „Navigation“ sprechen, obwohl die Kriterien nicht erfüllt sind). Wir freuen uns über Feedback zu den Heuristiken im Repository für die Soft Navigation-Spezifikation.

DevTools-Unterstützung für Soft-Navigationen

Wir haben Unterstützung für Soft Navigations im Leistungsbereich der DevTools in der Trace-Ansicht hinzugefügt:

Sie sehen Markierungen für Soft Navigations und LCP, die beide mit einem * gekennzeichnet sind, um sie von den üblichen Einträgen für Hard Navigations zu unterscheiden. Diese Funktion ist standardmäßig aktiviert und unabhängig von den Änderungen an der Performance API, die wir als Nächstes besprechen. So können Sie schnell testen, ob das Soft-Navigation-Experiment auf Ihrer Website richtig funktioniert.

Derzeit werden in der Trace-Ansicht nur die Zeitstempel für die Soft Navigation und den LCP angezeigt. Andere Messwerte (z. B. LCP) und die Unterstützung in der Ansicht Live-Messwerte werden später hinzugefügt.

Wie implementiert Chrome Soft Navigations für Webentwickler?

Sobald die Heuristiken für Soft-Navigation aktiviert sind (weitere Informationen dazu finden Sie im nächsten Abschnitt), ändert Chrome die Art und Weise, wie einige Leistungsmesswerte gemeldet werden:

• Nach jeder erkannten Soft Navigation wird ein soft-navigation-Ereignis PerformanceTiming ausgegeben.
• Dieser soft-navigation-Eintrag enthält ein navigationId, die neue URL im Attribut name sowie ein interactionId der initiierenden Interaktion.
• Nach Interaktionen, die einen Contentful Paint verursachen, werden ein oder mehrere interaction-contentful-paint-Einträge ausgegeben. Damit lässt sich Largest Contentful Paint (LCP) für Soft Navigations messen, wenn durch die Interaktion eine Soft Navigation ausgelöst wird.
• Das Attribut navigationId wird jedem Leistungszeitpunkt (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event und layout-shift) hinzugefügt. Es entspricht dem Navigationseintrag, unter dem das Ereignis ausgegeben wurde. Wenn sich diese Einträge über Soft Navigations erstrecken, können sie je nach Zeitpunkt der Ausgabe des Eintrags das vorherige oder nächste navigationId enthalten. Weitere Informationen finden Sie im Abschnitt Messwerte für die entsprechende URL melden.
• Der soft-navigation-Eintrag enthält einen largestInteractionContentfulPaint-Eintrag mit dem größten interaction-contentful-paint-Eintrag, der im Rahmen der Navigation ausgegeben wurde. Dieser Wert kann dann als anfänglicher LCP für diese Navigation verwendet werden. Der LCP kann dann aktualisiert werden, wenn weitere interaction-contentful-paint-Einträge für diese Interaktion beobachtet werden.
• Möglicherweise erfolgen einige interaction-contentful-paint-Einträge vor der Soft Navigation, wenn die URL erst nach diesen Rendervorgängen aktualisiert wird. In diesen Fällen muss der größte largestInteractionContentfulPaint-Eintrag nicht gepuffert und auf alte Einträge zurückgeblickt werden. largestInteractionContentfulPaint ist eine genaue Kopie des größten interaction-contentful-paint-Eintrags. Für diesen Eintrag wurde also das vorherige navigationId verwendet, da die Darstellung zu diesem Zeitpunkt erfolgte. Diese Darstellungen sollten jedoch anhand des neuen navigationId gemessen werden.
• Der Eintrag soft-navigation enthält auch paintTime und presentationTime als FCP für diese Navigation.
• Beachten Sie, dass interaction-contentful-paint-Einträge auch nach weiteren Interaktionen ausgegeben werden. Der LCP für eine URL sollte jedoch auf interaction-contentful-paint-Einträge beschränkt werden, die mit den Soft-Navigations-Einträgen interactionId übereinstimmen, um diese auszuschließen.

Durch diese Änderungen können die Core Web Vitals und einige der zugehörigen diagnostischen Messwerte pro Seitenaufruf gemessen werden. Es gibt jedoch einige Besonderheiten, die berücksichtigt werden müssen.

Welche Auswirkungen hat die Aktivierung von Soft Navigations in Chrome?

Im Folgenden sind einige der Änderungen aufgeführt, die Websiteinhaber nach der Aktivierung dieser Funktion berücksichtigen müssen:

• Durch die Überwachung der soft-navigation-Einträge können die Leistungseinträge in die einzelnen „Navigationen“ unterteilt werden.
• CLS- und INP-Messwerte können bereits nach Belieben aufgeschlüsselt werden, anstatt über den gesamten Seitenlebenszyklus hinweg gemessen zu werden. Die Soft Navigation API bietet jedoch eine standardisierte Messung dafür, wann dies geschieht, unabhängig von der zugrunde liegenden Technologie.
• Der largest-contentful-paint-Eintrag wird bei einer Interaktion abgeschlossen, die zum Starten einer Soft-Navigation erforderlich ist. Er kann also nur verwendet werden, um den LCP für die erste „harte“ Navigation zu messen. Das bedeutet, dass sich dieser Wert nicht ändert, wenn Soft Navigations gemessen werden. Der LCP für den ursprünglichen, harten Seitenaufbau kann also wie gewohnt gemessen werden.
• Der neue interaction-contentful-paint-Eintrag, der aus Interaktionen ausgegeben wird, kann verwendet werden, um den LCP für Soft Navigations zu messen. Es gibt jedoch einige Aspekte, die bei der Verwendung dieses Eintrags berücksichtigt werden müssen.
• Beachten Sie, dass nicht alle Nutzer diese Soft-Navigation-API unterstützen, insbesondere bei älteren Chrome-Versionen und bei Nutzern anderer Browser. Einige Nutzer melden möglicherweise keine Messwerte, die auf Soft-Navigation basieren, auch wenn sie Core Web Vitals-Messwerte melden.
• Da es sich um eine neue experimentelle Funktion handelt, die nicht standardmäßig aktiviert ist, sollten Websites sie auf unerwünschte Nebenwirkungen testen.

Erkundigen Sie sich bei Ihrem RUM-Anbieter, ob er die Messung von Core Web Vitals nach Soft Navigation unterstützt. Viele planen, diesen neuen Standard zu testen, und werden die bisherigen Überlegungen berücksichtigen. In der Zwischenzeit erlauben einige Anbieter auch eingeschränkte Messungen von Leistungsmesswerten auf Grundlage ihrer eigenen Heuristiken.

Weitere Informationen zum Messen der Messwerte für Soft Navigations finden Sie im Abschnitt zum Messen von Core Web Vitals pro Soft Navigation.

Wie aktiviere ich Soft Navigations in Chrome?

Soft Navigations sind in Chrome nicht standardmäßig aktiviert, können aber durch explizites Aktivieren dieser Funktion getestet werden.

Entwickler können diese Funktion aktivieren, indem sie das Flag unter chrome://flags/#soft-navigation-heuristics aktivieren. Alternativ kann sie beim Starten von Chrome mit den Befehlszeilenargumenten --enable-features=SoftNavigationHeuristics aktiviert werden. Wenn Sie das Flag chrome://flags/#enable-experimental-web-platform-features aktivieren, werden auch die Soft-Navigationen aktiviert.

Für Websites, die diese Funktion für alle Besucher aktivieren möchten, um die Auswirkungen zu sehen, wird ab Chrome 147 ein Origin Trial durchgeführt. Sie können die Funktion aktivieren, indem Sie sich für den Testzeitraum registrieren und ein Meta-Element mit dem Origin Trial-Token in den HTML- oder HTTP-Header einfügen. Weitere Informationen finden Sie im Beitrag Erste Schritte mit Origin Trials.

Websiteinhaber können das Origin Trial auf ihren Seiten für alle oder nur für eine Teilmenge von Nutzern einbinden. Beachten Sie den Abschnitt zu den Auswirkungen oben, da sich dadurch die Art und Weise ändert, wie Ihre Messwerte erfasst werden. Das gilt insbesondere, wenn Sie diesen Origin Trial für einen großen Teil Ihrer Nutzer aktivieren. CrUX meldet die Messwerte weiterhin auf die bisherige Weise, unabhängig von dieser Einstellung für Soft Navigation. Die Auswirkungen sind also nicht relevant. Außerdem ist zu beachten, dass Origin Trials auch darauf beschränkt sind, experimentelle Funktionen bei maximal 0,5% aller Chrome-Seitenaufrufe als Median über 14 Tage zu aktivieren.Dies sollte jedoch nur bei sehr großen Websites ein Problem darstellen.

Unterstützung der Soft Navigations API erkennen

Mit dem folgenden Code können Sie testen, ob die API unterstützt wird:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

supportedEntryTypes wird bei der ersten Verwendung eingefroren. Wenn die Unterstützung für Soft Navigations dynamisch durch ein Origin-Trial-Token hinzugefügt wird, das in die Seite eingefügt wird, kann es sein, dass der ursprüngliche Wert zurückgegeben wird, bevor diese Funktion aktiviert wurde.

Die folgende Alternative kann in diesem Fall verwendet werden, solange Soft Navigations noch nicht standardmäßig unterstützt wird und sich in diesem Übergangszustand befindet:

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

Wie kann ich Soft Navigations messen?

Sobald der Test für Soft Navigations aktiviert ist, werden die Messwerte wie bei anderen Messwerten über die PerformanceObserver API erfasst. Bei diesen Messwerten sind jedoch einige zusätzliche Aspekte zu berücksichtigen.

Soft Navigations melden

Sie können PerformanceObserver verwenden, um Soft-Navigations zu beobachten. Im Folgenden finden Sie ein Beispiel für einen Code-Snippet, mit dem Soft-Navigationseinträge in der Konsole protokolliert werden. Dazu gehören auch vorherige Soft-Navigationsvorgänge auf dieser Seite, die mit der Option buffered protokolliert wurden:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

Damit können Seitenmesswerte für den gesamten Lebenszyklus für die vorherige Navigation fertiggestellt werden.

Messwerte für die entsprechende URL melden

Wenn eine Soft-Navigation erkannt wird, sollten die Core Web Vitals der vorherigen Seite abgeschlossen und dann für die vorherige URL gemeldet werden. Außerdem sollte die neue URL überwacht werden.

Das Attribut name des entsprechenden soft-navigation-Eintrags enthält die neue URL, für die Messwerte erfasst werden sollen, und navigationId ist der eindeutige Verweis für diese Navigation, da dieselbe URL im Lebenszyklus einer Single-Page-Anwendung mehrmals aufgerufen werden kann. Sie können mit der PerformanceEntry API nachgeschlagen werden:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

Melden Sie die richtige URL für interaction-contentful-paint.

Bei der Berechnung des LCP anhand von interaction-contentful-paint-Einträgen sind zusätzliche Aspekte zu berücksichtigen, da nicht alle interaction-contentful-paint-Einträge mit navigationId zugeordnet und als LCP für die entsprechende URL gemeldet werden sollten:

• Das erste Problem besteht darin, dass interaction-contentful-paint-Einträge möglicherweise vor der Soft-Navigation ausgegeben werden, wenn vor der URL-Aktualisierung ein Paint erfolgt. In diesen Fällen gilt die navigationId für die alte URL. Wenn die URL zuerst aktualisiert wird, wird die Soft Navigation abgeschlossen und in diesem Fall wird der soft-navigation-Eintrag zuerst ausgegeben und der interaction-contentful-paint-Eintrag hat die neue URL.
• Das zweite Problem besteht darin, dass für neuere Interaktionen weiterhin interaction-contentful-paint-Einträge ausgegeben werden, da sich der Umfang dieses Leistungsmesswerts nicht nur auf LCP für Soft Navigations beschränkt. Wir möchten nur die Farben für das Soft-Navigation-Laden für LCP berücksichtigen und nicht die für nachfolgende Interaktionen.

Daher sollte interactionId anstelle von navigationId verwendet werden, um interaction-contentful-paint-Einträge soft-navigation-entries zuzuordnen und die richtige URL zu erhalten. Dadurch werden alle Einträge mit alten navigationIds verarbeitet und alle interaction-contentful-paint-Einträge herausgefiltert, die nicht für LCP berücksichtigt werden sollten.

Außerdem sollten Sie auch den largestInteractionContentfulPaint-Eintrag der soft-navigation-Einträge verarbeiten, um interaction-contentful-paint-Einträge, die vor dem Ausgeben des soft-navigation entries-Ereignisses auftreten, leichter zu verarbeiten.

startTime von Soft-Navigationen abrufen

Alle Leistungszeitangaben, einschließlich derer für Soft Navigations, und die Einträge, die zum Berechnen der Core Web Vitals-Messwerte verwendet werden, werden als Zeit seit der ursprünglichen „harten“ Seitennavigation angegeben. Daher sollte die Startzeit der Soft Navigation von den Zeiten für Messwerte für das Laden von Soft Navigation (z. B. LCP) subtrahiert werden, um sie relativ zu dieser Soft Navigation-Zeit zu erfassen.

Die Startzeit der Navigation kann auf ähnliche Weise abgerufen werden, indem der entsprechende soft-navigation-Eintrag zugeordnet und dessen startTime verwendet wird.

startTime ist der Zeitpunkt der ersten Interaktion (z. B. ein Klick auf eine Schaltfläche), die die Soft-Navigation ausgelöst hat. Das unterscheidet sich etwas von „harten Navigationsvorgängen“, bei denen die „Startzeit“ der Zeitpunkt ist, zu dem die neue Seite im Browser „festgeschrieben“ wird und nachdem ein Teil des Event-Handler-Codes ausgeführt wurde. Die Startzeiten für Soft Navigations umfassen auch den Code des Event-Handlers, da wir ab dem Beginn der Interaktion messen.

Core Web Vitals pro Soft Navigation messen

Um Core Web Vitals zu messen, müssen Sie auf soft-navigation-Einträge achten und die Messwerte zurücksetzen, wenn Sie diese erhalten. FCP kann basierend auf dem presentationTime ausgegeben und LCP auf den largestInteractionContentfulPaint initialisiert werden. INP und CLS sollten wie bei einem Seitenaufbau auf 0 initialisiert werden.

LCP, INP und CLS können dann wie gewohnt gemessen und überwacht werden. Die Ausnahme ist die Verwendung von interaction-contentful-paint für LCP, wenn interactionId übereinstimmt. Mit interactionId und navigationId können die Einträge für eine URL wie bereits erwähnt benannt werden.

Die Zeitangaben werden weiterhin relativ zur ursprünglichen „harten“ Navigationsstartzeit zurückgegeben. Um beispielsweise den LCP für eine Soft Navigation zu berechnen, müssen Sie den interaction-contentful-paint-Zeitpunkt nehmen und die entsprechende Startzeit für die Soft Navigation subtrahieren, wie bereits beschrieben. So erhalten Sie einen Zeitpunkt relativ zur Soft Navigation.

Einige Messwerte wurden bisher während der gesamten Lebensdauer der Seite gemessen. LCP kann sich beispielsweise ändern, bis eine Interaktion erfolgt. CLS und INP können aktualisiert werden, bis die Seite verlassen wird, unabhängig von Interaktionen. Daher sollten die Messwerte der vorherigen Navigation mit jeder neuen Soft Navigation abgeschlossen werden. Das bedeutet, dass die ersten „harten“ Navigationsmesswerte möglicherweise früher als gewöhnlich abgeschlossen werden, wenn Core Web Vitals mit Soft-Navigations gemessen werden.

Wenn Sie mit der Messung der Messwerte für die neue Soft Navigation dieser langlebigen Messwerte beginnen, müssen die Messwerte ebenfalls „zurückgesetzt“ oder „neu initialisiert“ und als neue Messwerte behandelt werden. Es gibt keine Erinnerung an die Werte, die für frühere „Seiten“ festgelegt wurden. Das bedeutet, dass die Informationen dazu, was das „größte“ Rendern, die Interaktion bis zum nächsten Rendern oder die Layoutverschiebung ist, zurückgesetzt werden, damit die Messung von vorn beginnen kann.

Wie soll mit Inhalten umgegangen werden, die bei verschiedenen Navigationsvorgängen gleich bleiben?

Der LCP für Soft-Navigations (berechnet aus interaction-contentful-paint) berücksichtigt nur neue Rendervorgänge und nur Rendervorgänge, die mit der Interaktion zusammenhängen, die die Navigation ausgelöst hat. Das kann zu einem anderen LCP führen, z. B. von einem Kaltstart dieser Soft Navigation zu einem Soft Load.

Nehmen wir als Beispiel eine Seite mit einem großen Bannerbild, das das LCP-Element ist. Der Text darunter ändert sich jedoch bei jeder Soft-Navigation. Beim ersten Laden der Seite wird das Bannerbild als LCP-Element gekennzeichnet und das LCP-Timing darauf basiert. Bei nachfolgenden Soft-Navigations ist der Text darunter das größte Element, das nach der Soft-Navigation gerendert wird, und das neue LCP-Element. Wenn die Seite jedoch mit einem Deeplink in die Soft-Navigation-URL geladen wird, wird das Bannerbild neu gerendert und kann daher als LCP-Element infrage kommen.

Ebenso kann eine Animation einen Teil der Seite fortlaufend aktualisieren, unabhängig von einer Soft Navigation. Alle neuen Renderings, die aufgrund dieser Hintergrundanimation erfolgen, werden für den LCP der neuen Soft Navigation nicht berücksichtigt. Sie können jedoch für den LCP berücksichtigt werden, wenn die Seite über diese URL neu geladen wurde.

Wie diese Beispiele zeigen, kann das LCP-Element für die Soft Navigation unterschiedlich gemeldet werden, je nachdem, wie die Seite geladen wird. Das ist vergleichbar mit dem Laden einer Seite mit einem Ankerlink weiter unten auf der Seite, was zu einem anderen LCP-Element für Hard Navigations führen kann.

TTFB messen

Die Zeit bis zum ersten Byte (TTFB) für einen herkömmlichen Seitenaufruf gibt die Zeit an, die benötigt wird, bis die ersten Bytes der ursprünglichen Anfrage zurückgegeben werden.

Bei einer Soft-Navigation ist das schwieriger. Sollten wir die erste Anfrage für die neue Seite messen? Was passiert, wenn alle Inhalte bereits in der App vorhanden sind und keine zusätzlichen Anfragen gestellt werden? Was passiert, wenn diese Anfrage im Voraus mit einem Prefetch gestellt wird? Was passiert, wenn eine Anfrage nicht mit der Soft Navigation aus Nutzersicht zusammenhängt (z. B. eine Analyseanfrage)?

Eine einfachere Methode besteht darin, für Soft-Navigations TTFB = 0 zu melden, ähnlich wie bei Back-Forward-Cache-Wiederherstellungen. Diese Methode wird von der web-vitals-Bibliothek für Soft-Navigations verwendet und wir empfehlen sie derzeit für diesen Messwert.

Sollten Sie die Core Web Vitals mit beiden Methoden messen?

Während dieses Tests sollten Sie Ihre Core Web Vitals weiterhin auf Grundlage von „harten“ Seitennavigationen messen, da die neue Implementierung möglicherweise Probleme aufweist oder sich ändert, bevor sie endgültig eingeführt wird. Das entspricht auch dem, was CrUX derzeit misst (mehr dazu später).

Zusätzlich sollten Soft Navigations gemessen werden, damit Sie sehen können, wie sie in Zukunft gemessen werden könnten. Außerdem haben Sie so die Möglichkeit, dem Chrome-Team Feedback dazu zu geben, wie diese Implementierung in der Praxis funktioniert. So können Sie und das Chrome-Team die API weiterentwickeln.

Für LCP bedeutet das, dass nur largest-contentful-paint-Einträge für die aktuelle Methode und sowohl largest-contentful-paint- als auch interaction-contentful-paint-Einträge für die neue Methode berücksichtigt werden.

Für CLS und INP bedeutet das, dass diese Messwerte wie bisher über den gesamten Seitenlebenszyklus hinweg gemessen werden und die Zeitachse separat nach Soft-Navigations unterteilt wird, um separate CLS- und INP-Werte für die neue Seite zu messen.

web-vitals-Bibliothek zum Messen der Core Web Vitals für Soft Navigations verwenden

Am einfachsten ist es, die web-vitals-JavaScript-Bibliothek zu verwenden, die experimentelle Unterstützung für Soft Navigations in einem separaten soft-navs branch bietet (das auch auf npm und unpkg verfügbar ist). Das lässt sich so messen (doTraditionalProcessing und doSoftNavProcessing entsprechend ersetzen):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

Die web-vitals-Bibliothek sorgt auch dafür, dass die Messwerte für die richtige URL gemeldet werden (wie bereits erwähnt), da sie sowohl navigationId als auch navigationURL in den an den Callback übergebenen Einträgen enthält.

Die web-vitals-Bibliothek meldet die folgenden Messwerte für Soft Navigations:

Werden diese Änderungen in die Core Web Vitals-Messungen einbezogen?

Wir möchten die Heuristiken bewerten und sehen, ob sie die Nutzerfreundlichkeit genauer widerspiegeln, bevor wir entscheiden, ob sie in die Core Web Vitals-Initiative aufgenommen werden. Das Ziel ist, die Leistung aus der Sicht echter Nutzer besser messen zu können. Wenn das Experiment erfolgreich ist, sollen diese Messwerte in die Core Web Vitals-Messungen aller Tools einbezogen werden.

Wir freuen uns über das Feedback von Webentwicklern zum Test, zu den verwendeten Heuristiken und dazu, ob die Ergebnisse die Nutzerfreundlichkeit besser widerspiegeln. Das GitHub-Repository für Soft Navigation ist der beste Ort, um Feedback zu geben. Einzelne Fehler bei der Chrome-Implementierung sollten jedoch im Chrome-Issue-Tracker gemeldet werden.

Wie werden Soft Navigations im CrUX-Bericht erfasst?

Wie genau Soft Navigations im CrUX-Bericht erfasst werden, wenn dieser Test erfolgreich ist, muss noch festgelegt werden. Es ist nicht unbedingt gegeben, dass sie genauso behandelt werden wie aktuelle „harte“ Navigationsvorgänge.

Auf einigen Webseiten sind Soft Navigations für den Nutzer fast identisch mit vollständigen Seitenaufrufen. Die Verwendung der Single Page Application-Technologie ist nur ein Implementierungsdetail. In anderen Fällen kann es sich eher um das teilweise Laden zusätzlicher Inhalte handeln.

Daher werden diese Soft Navigations möglicherweise separat im CrUX-Bericht aufgeführt oder bei der Berechnung der Core Web Vitals für eine bestimmte Seite oder Gruppe von Seiten gewichtet. Möglicherweise können wir die Soft-Navigation bei Teillast auch vollständig ausschließen, wenn sich die Heuristik weiterentwickelt.

Das Team konzentriert sich auf die heuristische und technische Implementierung, die es uns ermöglicht, den Erfolg dieses Tests zu beurteilen. Daher wurde in diesen Bereichen noch keine Entscheidung getroffen.

Feedback

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

• Feedback zur API sollte als Probleme auf GitHub gemeldet werden.
• Fehler bei der Chromium-Implementierung sollten im Chrome-Issue-Tracker gemeldet werden, sofern es sich nicht um eines der bekannten Probleme handelt.
• Allgemeines Feedback zu Web-Vitals können Sie an web-vitals-feedback@googlegroups.com senden.

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.

Änderungsprotokoll

Da sich diese API in der Testphase befindet, werden daran mehr Änderungen vorgenommen als an stabilen APIs. Weitere Informationen finden Sie im Änderungs-Log für Soft Navigation Heuristics.

Fazit

Das Soft Navigations-Experiment ist ein vielversprechender Ansatz, wie sich die Core Web Vitals-Initiative weiterentwickeln könnte, um ein häufiges Muster im modernen Web zu messen, das in unseren Messwerten fehlt. Dieser Test befindet sich noch in der Anfangsphase und es gibt noch viel zu tun. Es ist jedoch ein wichtiger Schritt, die bisherigen Fortschritte der breiteren Web-Community zur Verfügung zu stellen, damit sie damit experimentieren kann. Das Feedback aus diesem Test ist ein weiterer wichtiger Bestandteil des Tests. Wir empfehlen allen, die sich für diese Entwicklung interessieren, diese Gelegenheit zu nutzen, um die API mitzugestalten und sicherzustellen, dass sie repräsentativ für das ist, was wir damit messen möchten.

Danksagungen

Miniaturansicht von Jordan Madrid auf Unsplash

Diese Arbeit ist eine Fortsetzung der Arbeit, die Yoav Weiss bei Google begonnen hat. Wir danken Yoav für seine Bemühungen bei dieser API.