Experimentieren mit dem Messen der weichen Navigation

Barry Pollard

Yoav Weiss

Aktualisierung im August 2024:Der zweite Ursprungspfad der Softnavigation endete am 29. Mai. Das Chrome-Team nimmt sich Zeit, um das Feedback zum Test zu prüfen und die nächsten Schritte für diese API zu erwägen. Wir möchten einige Probleme mit der Genauigkeit beheben und sind der Meinung, dass noch ein weiterer Test erforderlich ist, bevor die Funktion weiter entwickelt werden kann. In der Zwischenzeit können Entwickler die Funktion weiterhin testen, indem sie chrome://flags/#enable-experimental-web-platform-features aktivieren.

Seit ihrer Einführung hat sich die Core Web Vitals-Initiative darauf konzentriert, die tatsächliche Nutzerfreundlichkeit einer Website zu messen, anstatt technische Details zur Erstellung oder zum Laden einer Website. Die drei Core Web Vitals-Messwerte wurden als nutzerorientierte Messwerte erstellt. Sie stehen im Vergleich zu vorhandenen technischen Messwerten wie DOMContentLoaded oder load, mit denen Zeitangaben ermittelt wurden, die oft keinen Bezug dazu hatten, wie Nutzer die Leistung der Seite wahrgenommen haben. Daher sollte die für die Website verwendete Technologie die Bewertung nicht beeinflussen, sofern die Website eine gute Leistung erbringt.

Die Realität ist immer etwas komplizierter als das Ideal. Die beliebte Single-Page-Application-Architektur wurde nie vollständig von den Core Web Vitals-Messwerten unterstützt. Anstatt beim Navigieren auf der Website separate, einzelne Webseiten zu laden, verwenden diese Webanwendungen sogenannte „weiche Navigationen“, bei denen der Seiteninhalt stattdessen durch JavaScript geändert wird. In diesen Anwendungen wird der Anschein einer herkömmlichen Webseitenarchitektur aufrechterhalten, indem die URL geändert und vorherige URLs in den Browserverlauf aufgenommen werden, damit die Schaltflächen „Zurück“ und „Vorwärts“ wie erwartet funktionieren.

Viele JavaScript-Frameworks verwenden dieses Modell, aber jedes auf unterschiedliche Weise. Da dies nicht zu dem gehört, was der Browser traditionell als „Seite“ versteht, war die Messung immer schwierig: Wo wird die Grenze zwischen einer Interaktion auf der aktuellen Seite und der Betrachtung als neue Seite gezogen?

Das Chrome-Team beschäftigt sich schon seit einiger Zeit mit dieser Herausforderung und möchte eine Definition für „Soft Navigation“ und dafür, wie die Core Web Vitals gemessen werden können, standardisieren – ähnlich wie bei Websites, die in der herkömmlichen mehrseitigen Architektur (Multi-Page Architecture, MPA) implementiert sind. Das Team befindet sich noch in der Anfangsphase und ist nun bereit, die bereits implementierten Websites allgemein zum Experimentieren zur Verfügung zu stellen. So können die Websites Feedback zum bisherigen Ansatz geben.

Was ist eine weiche Navigation?

Wir haben uns die folgende Definition einer weichen Navigation ausgedacht:

• Die Navigation wird durch eine Nutzeraktion initiiert.
• Die Navigation führt zu einer sichtbaren URL-Änderung für den Nutzer und zu einer Änderung des Verlaufs.
• Die Navigation führt zu einer DOM-Änderung.

Bei einigen Websites können diese Heuristiken zu falsch positiven Ergebnissen führen (Nutzer würden eine Navigation nicht wirklich als erfolgt betrachten) oder zu falsch negativen Ergebnissen (Nutzer würden eine Navigation als erfolgt betrachten, obwohl diese Kriterien nicht erfüllt sind). Wir freuen uns über Feedback zu den Heuristiken im Repository der Spezifikation für die Softnavigation.

Wie werden Soft Navigationen in Chrome implementiert?

Sobald die Heuristiken für die sanfte Navigation aktiviert sind (mehr dazu im nächsten Abschnitt), ändert Chrome die Art und Weise, wie einige Leistungsmesswerte erfasst werden:

• Nach jeder erkannten weichen Navigation wird ein soft-navigation PerformanceTiming-Ereignis ausgegeben.
• Die Leistungs-API bietet Zugriff auf einen soft-navigation-Zeiteintrag, der vom Ereignis soft-navigation PerformanceTiming gesendet wurde.
• Die Messwerte First Paint (FP), First Contentful Paint (FCP) und Largest Contentful Paint (LCP) werden zurückgesetzt und bei den nächsten entsprechenden Vorkommnissen noch einmal gesendet. Hinweis: FP und FCP sind nicht implementiert.
• Jedem der Leistungszeitpunkte (first-paint, first-contentful-paint, largest-contentful-paint, first-input-delay, event und layout-shift) wird ein navigationId-Attribut hinzugefügt, das dem Navigationseintrag entspricht, mit dem das Ereignis verknüpft war. So können Cumulative Layout Shift (CLS) und Interaction to Next Paint (INP) berechnet werden.

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

Was sind die Auswirkungen der Aktivierung der weichen Navigation in Chrome?

Im Folgenden finden Sie einige der Änderungen, die Websiteinhaber nach der Aktivierung dieser Funktion berücksichtigen müssen:

• Für die weiche Navigation können weitere FP-, FCP- und LCP-Ereignisse ausgegeben werden. Diese zusätzlichen Werte werden im Bericht zur Nutzererfahrung in Chrome (Chrome User Experience, CrUX) ignoriert. Dies kann sich jedoch auf die Real User Measurement (RUM)-Überwachung Ihrer Website auswirken. Wenden Sie sich an Ihren RUM-Anbieter, wenn Sie Bedenken haben, ob sich dies auf diese Messungen auswirkt. Weitere Informationen finden Sie im Abschnitt zum Messen der Core Web Vitals für die schrittweise Navigation.
• Das neue (und optionale) Attribut navigationID in Ihren Leistungseinträgen muss möglicherweise in Ihrem Anwendungscode berücksichtigt werden.
• Dieser neue Modus wird nur von Chromium-basierten Browsern unterstützt. Viele der neueren Messwerte sind nur in Chromium-basierten Browsern verfügbar, einige (FCP, LCP) aber auch in anderen Browsern. Außerdem haben nicht alle Nutzer auf die neueste Version der Chromium-basierten Browser umgestellt. Daher werden für einige Nutzer möglicherweise keine Messwerte für die Softnavigation erfasst.
• Da es sich um eine experimentelle Funktion handelt, die nicht standardmäßig aktiviert ist, sollten Websites diese Funktion testen, um sicherzustellen, dass es keine anderen unbeabsichtigten Nebenwirkungen gibt.

Weitere Informationen zum Erfassen der Messwerte für die weich navigierten Seiten finden Sie im Abschnitt Core Web Vitals nach weich navigierten Seiten erfassen.

Wie aktiviere ich die weich fließende Navigation in Chrome?

Die weiche Navigation ist in Chrome nicht standardmäßig aktiviert. Sie können sie aber testen, indem Sie diese Funktion explizit aktivieren.

Entwickler können diese Funktion aktivieren, indem sie das Flag Experimental Web Platform features (Experimentelle Webplattform-Funktionen) unter chrome://flags/#enable-experimental-web-platform-features aktivieren oder das Befehlszeilenargument --enable-experimental-web-platform-features beim Starten von Chrome verwenden.

Wie kann ich die Aufrufe von Seiten mithilfe von Soft Navigation erfassen?

Sobald der Test für die schrittweise Navigation aktiviert ist, werden die Messwerte wie gewohnt über die PerformanceObserver API erfasst. Bei diesen Messwerten müssen jedoch einige zusätzliche Aspekte berücksichtigt werden.

Hinweis: FP und FCP werden für die Softnavigation noch nicht erfasst.

Navigationen mit geringer Interaktion melden

Sie können mit einem PerformanceObserver die Soft Navigation beobachten. Das folgende Beispiel-Code-Snippet protokolliert Einträge für die weiche Navigation in der Konsole – einschließlich vorheriger sanfter Navigationen auf dieser Seite mit der Option buffered:

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

So können Sie die Messwerte für die gesamte Lebensdauer der Seite für die vorherige Navigation abschließen.

Messwerte für die entsprechende URL erfassen

Da die Navigationen nur nach dem Ereignis sichtbar sind, müssen einige Messwerte nach diesem Ereignis abgeschlossen und dann für die vorherige URL erfasst werden, da die aktuelle URL jetzt die aktualisierte URL für die neue Seite enthält.

Mit dem navigationId-Attribut des entsprechenden PerformanceEntry können Sie das Ereignis wieder mit der richtigen URL verknüpfen. Diese Informationen können mit der PerformanceEntry API abgerufen 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;

Dieser pageUrl sollte verwendet werden, um die Messwerte anhand der richtigen URL zu erfassen, nicht anhand der aktuellen URL, die in der Vergangenheit verwendet wurde.

startTime von Soft-Navigationen abrufen

Die Startzeit der Navigation kann auf ähnliche Weise abgerufen werden:

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

startTime ist der Zeitpunkt der ersten Interaktion (z. B. ein Klick auf eine Schaltfläche), durch die die Softnavigation gestartet wurde.

Alle Leistungszeiträume, einschließlich derer für die „weiche“ Navigation, werden als Zeit seit der ursprünglichen „harten“ Seitennavigation angegeben. Daher ist der Beginn der weichen Navigation erforderlich, um die Ladezeiten der weichen Navigation (z. B. LCP) relativ zu dieser Zeit zu erfassen.

Core Web Vitals nach Soft Navigation messen

Wenn Sie Messwerteinträge für die weiche Navigation einschließen möchten, müssen Sie includeSoftNavigationObservations: true in den observe-Aufruf Ihres Performance Beobachters aufnehmen.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

Das zusätzliche includeSoftNavigationObservations-Flag für die observe-Methode ist zusätzlich zur Aktivierung der Funktion für die sanfte Navigation in Chrome erforderlich. Diese explizite Aktivierung auf Ebene des Leistungsbeobachters soll dafür sorgen, dass bestehende Leistungsbeobachter nicht von diesen zusätzlichen Einträgen überrascht werden, da bei der Messung der Core Web Vitals für die schrittweise Navigation einige zusätzliche Aspekte berücksichtigt werden müssen.

Die Zeitangaben werden weiterhin in Bezug auf den ursprünglichen „harten“ Navigationsstart zurückgegeben. Wenn Sie beispielsweise den LCP für eine nutzerfreundliche Navigation berechnen möchten, müssen Sie den LCP-Zeitpunkt nehmen und den entsprechenden Beginn der nutzerfreundlichen Navigation wie bereits beschrieben abziehen, um einen Zeitwert relativ zur nutzerfreundlichen Navigation zu erhalten. Beispiel für LCP:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

Einige Messwerte wurden traditionell während der gesamten Lebensdauer der Seite erfasst. Der LCP kann sich beispielsweise ändern, bis eine Interaktion erfolgt. CLS und INP können aktualisiert werden, bis die Seite verlassen wird. Daher müssen bei jeder Navigation (einschließlich der ursprünglichen Navigation) bei jeder neuen sanften Navigation die Messwerte der vorherigen Seite fertiggestellt werden. Das bedeutet, dass die ersten „harten“ Navigationsmesswerte möglicherweise früher als üblich fertiggestellt werden.

Wenn Sie die Messwerte für die neue Softnavigation dieser langlebigen Messwerte erfassen möchten, müssen sie ebenfalls zurückgesetzt oder neu initialisiert und als neue Messwerte behandelt werden. Die Werte, die für die vorherigen „Seiten“ festgelegt wurden, werden nicht berücksichtigt.

Wie sollten Inhalte behandelt werden, die zwischen Navigationen gleich bleiben?

Mit FP, FCP und LCP werden bei weicher Navigation nur neue Farben gemessen. Das kann zu einem anderen LCP führen, z. B. von einem kalten Laden dieser Navigation zu einem weichen Laden.

Angenommen, eine Seite enthält ein großes Bannerbild, das das LCP-Element ist, der Text darunter ändert sich jedoch bei jeder weichen Navigation. Beim ersten Seitenaufbau wird das Bannerbild als LCP-Element gekennzeichnet und das LCP-Timing darauf basiert. Bei nachfolgenden weichen Navigationen ist der Text darunter das größte Element, das nach der weichen Navigation dargestellt wird, und das neue LCP-Element. Wenn jedoch eine neue Seite mit einem Deeplink in der URL für die weiche Navigation geladen wird, erhält das Bannerbild eine neue Farbe und kann daher als LCP-Element betrachtet werden.

Wie dieses Beispiel zeigt, kann das LCP-Element für die weiche Navigation je nachdem, wie die Seite geladen wird, unterschiedlich gemeldet werden. Ähnlich wie das Laden einer Seite mit einem Ankerlink weiter unten auf der Seite zu einem anderen LCP-Element führen kann.

Wie wird die TTFB gemessen?

Time to First Byte (TTFB) für einen konventionellen Seitenaufbau gibt an, wie lange die ersten Byte der ursprünglichen Anfrage zurückgegeben werden.

Bei einer Softnavigation ist diese Frage etwas kniffliger. Sollten wir die erste Anfrage für die neue Seite erfassen? Was ist, wenn alle Inhalte bereits in der App vorhanden sind und es keine zusätzlichen Anfragen gibt? Was ist, wenn diese Anfrage im Voraus mit einem Prefetch erfolgt? Was ist, wenn eine Anfrage aus Sicht des Nutzers nichts mit der Softnavigation zu tun hat (z. B. eine Analyseanfrage)?

Eine einfachere Methode besteht darin, für die weichen Navigationen einen TTFB von 0 anzugeben, ähnlich wie wir es für die Wiederherstellung aus dem Back-Forward-Cache empfehlen. Dies ist die Methode, die die web-vitals-Bibliothek für die sanfte Navigation verwendet.

Zukünftig unterstützen wir möglicherweise genauere Methoden, um zu ermitteln, welche Anfrage die „Navigationsanfrage“ der weichen Navigation ist. Dann können wir genauere TTFB-Messungen haben. Das ist aber nicht Teil des aktuellen Tests.

Wie lassen sich alte und neue Erkenntnisse messen?

Während dieses Tests wird empfohlen, die Core Web Vitals weiterhin auf die aktuelle Weise zu messen, basierend auf „harten“ Seitennavigationen, damit sie mit den Daten übereinstimmen, die in CrUX als offizieller Datensatz der Core Web Vitals-Initiative erfasst und erfasst werden.

Soft Navigations sollten zusätzlich dazu gemessen werden, damit Sie sehen können, wie diese in Zukunft gemessen werden könnten, und damit Sie dem Chrome-Team Feedback dazu geben können, wie diese Implementierung in der Praxis funktioniert. So können Sie und das Chrome-Team die API in Zukunft gemeinsam weiterentwickeln.

Wenn Sie beide Messwerte erfassen möchten, müssen Sie die neuen Ereignisse kennen, die im Modus für die sanfte Navigation ausgegeben werden können (z. B. mehrere FCP- und zusätzliche LCP-Ereignisse). Sie müssen diese Ereignisse dann entsprechend verarbeiten, indem Sie diese Messwerte zum richtigen Zeitpunkt finalisieren und zukünftige Ereignisse ignorieren, die sich nur auf die sanfte Navigation beziehen.

Mit der web-vitals-Bibliothek Core Web Vitals für weiche Navigation messen

Am einfachsten ist es, die web-vitals-JavaScript-Bibliothek zu verwenden, die experimentelle Unterstützung für die sanfte Navigation in einer separaten soft-navs branch bietet (auch bei npm und unpkg verfügbar). Das kann so gemessen werden (ersetzen Sie doTraditionalProcessing und doSoftNavProcessing nach Bedarf):

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

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});

Achten Sie darauf, dass die Messwerte wie bereits erwähnt für die richtige URL erfasst werden.

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

Messwert	Details
TTFB	Wird als „0“ gemeldet.
FCP	Es wird nur der erste FCP für die Seite gemeldet.
LCP	Die Zeit des nächsten Largest Contentful Paint, bezogen auf den Beginn der weichen Navigation. Vorhandene Farben aus der vorherigen Navigation werden nicht berücksichtigt. Daher ist der LCP mindestens 0. Wie gewohnt wird dies nach einer Interaktion oder wenn die Seite im Hintergrund geöffnet ist, erfasst, da nur dann der LCP abgeschlossen werden kann.
CLS	Der größte Zeitraum zwischen den Navigationszeiten. Wie immer ist dies der Fall, wenn die Seite im Hintergrund ausgeführt wird, da erst dann der CLS abgeschlossen werden kann. Wenn es keine Schichten gibt, wird der Wert 0 erfasst.
INP	Die INP zwischen den Navigationszeiten. Dies wird wie gewohnt bei einer Interaktion oder wenn die Seite im Hintergrund ausgeführt wird, da erst dann der INP abgeschlossen werden kann. Wenn keine Interaktionen stattfinden, wird kein Wert „0“ erfasst.

Warnung: Die web-vitals-Implementierung befindet sich in aktiver Entwicklung und kann sich ändern, da neue Änderungen in diesem Branch veröffentlicht werden. FCP wird bei der Softnavigation nicht unterstützt, da dies mehr grundlegende Arbeit in Chrome erfordert. Nutzer der web-vitals-JavaScript-Bibliothek sollten sich dessen bewusst sein, wenn sie diese Bibliothek auf Produktionswebsites verwenden möchten. Sie sollten eine lokale Kopie erstellen, diese Version testen und den Branch auf Änderungen beobachten.

Werden diese Änderungen Teil der Core Web Vitals-Messungen?

Dieser Test zur nutzerfreundlichen Navigation ist genau das: ein Test. Wir möchten die Heuristiken bewerten und prüfen, ob sie die Nutzerfreundlichkeit genauer widerspiegeln, bevor wir eine Entscheidung darüber treffen, ob sie in die Core Web Vitals-Initiative aufgenommen werden. Wir freuen uns sehr auf diesen Test, können aber nicht garantieren, ob und wann die aktuellen Messungen ersetzt werden.

Wir freuen uns über Feedback von Webentwicklern zum Test, zu den verwendeten Heuristiken und dazu, ob Sie der Meinung sind, dass die Ergebnisse die Realität besser widerspiegeln. Das GitHub-Repository für die stufenlose Navigation ist der beste Ort, um dieses Feedback zu geben. Einzelne Fehler bei der Implementierung in Chrome sollten jedoch im Chrome-Problem-Tracker gemeldet werden.

Wie werden weiche Navigationen in Chrome zur Nutzererfahrung in Chrome erfasst?

Wie genau Soft Navigationen in CrUX erfasst werden, sollte dieser Test erfolgreich sein, ist noch nicht festgelegt. Es ist nicht unbedingt selbstverständlich, dass sie genauso behandelt werden wie aktuelle „harte“ Navigationen.

Auf einigen Webseiten sind die Soft-Navigationen für den Nutzer fast identisch mit dem Laden der gesamten Seite. Die Verwendung der Single-Page-Application-Technologie ist nur ein Implementierungsdetail. In anderen Fällen ähneln sie eher einer teilweisen Auslieferung zusätzlicher Inhalte.

Daher behalten wir uns vor, diese weichen Navigationen in CrUX gesondert zu erfassen oder sie bei der Berechnung der Core Web Vitals für eine bestimmte Seite oder Gruppe von Seiten zu gewichten. Im Zuge der Weiterentwicklung der Heuristik können wir die weiche Navigation bei Teillast möglicherweise auch vollständig ausschließen.

Das Team konzentriert sich auf die heuristische und technische Implementierung, anhand derer wir den Erfolg dieses Tests beurteilen können. In diesen Bereichen wurde noch keine Entscheidung getroffen.

Feedback

Wir suchen an den folgenden Stellen aktiv nach Feedback zu diesem Test:

• Die Heuristiken und Standardisierung der weichen Navigation
• Probleme bei der Chrome-Implementierung dieser Heuristiken.
• Allgemeines Feedback zu Web Vitals an [e-mail].

Änderungsprotokoll

Da diese API sich in der Testphase befindet, wird sie häufiger geändert als stabile APIs. Weitere Informationen finden Sie im Änderungslog für die Heuristiken zur weichen Navigation.

Fazit

Der Test mit weicher Navigation ist ein spannender Ansatz, der die Core Web Vitals-Initiative weiterentwickeln könnte, um ein gängiges 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 Web-Community zur Verfügung zu stellen, damit sie damit experimentieren kann. Das Feedback aus diesem Test ist ein weiterer wichtiger Teil des Tests. Wir empfehlen allen, die an dieser Entwicklung interessiert sind, diese Gelegenheit zu nutzen, um die API mitzugestalten und dafür zu sorgen, dass sie repräsentativ für das ist, was wir damit messen möchten.

Danksagungen

Miniaturansicht von Jordan Madrid auf Unsplash