Experimentieren mit dem Messen der weichen Navigation

Barry Pollard

Yoav Weiss

Update August 2024:Der zweite Ursprungstest für die Soft Navigation endete am 29. Mai. Das Chrome-Team nimmt sich Zeit, das Feedback zum Test zu prüfen und die nächsten Schritte für diese API zu überlegen. 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 entwickelt. Sie sind eine Weiterentwicklung bestehender technischer Messwerte wie DOMContentLoaded oder load, mit denen Zeiträume gemessen wurden, die oft keinen Bezug zur Nutzerwahrnehmung der Seitenleistung hatten. 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. Die Funktion befindet sich noch in der Anfangsphase, aber das Team ist jetzt bereit, die bereits implementierten Funktionen für mehr Websites verfügbar zu machen. So können die Websites Feedback zum bisherigen Ansatz geben.

Was ist eine Softnavigation?

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 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 Leistungszeitpunkt (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:

• Bei einer sanften Navigation werden möglicherweise zusätzliche FP-, FCP- und LCP-Ereignisse noch einmal gesendet. 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 Funktion „Weiche Navigation“ ist in Chrome standardmäßig nicht aktiviert. Sie können sie jedoch explizit aktivieren, um sie auszuprobieren.

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.

Soft Navigationen melden

Sie können mit einem PerformanceObserver die Soft Navigation beobachten. Im folgenden Code-Snippet werden Soft Navigation-Einträge in der Console protokolliert, einschließlich vorheriger Soft Navigations 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 Einträge für Messwerte zur weichen Navigation einbeziehen möchten, müssen Sie includeSoftNavigationObservations: true in den observe-Aufruf Ihres Leistungsbeobachters 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) die Messwerte der vorherigen Seite abgeschlossen werden, wenn eine neue Softnavigation erfolgt. 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?

FP, FCP und LCP für die schrittweise Navigation werden nur für neue Paints 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 sanften Navigation. Beim ersten Laden der Seite wird das Bannerbild als LCP-Element gekennzeichnet und das LCP-Timing wird darauf basierend berechnet. 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 die URL der Softnavigation geladen wird, ist das Bannerbild eine neue Darstellung und kann daher als LCP-Element berücksichtigt werden.

Wie dieses Beispiel zeigt, kann das LCP-Element für die nutzerfreundliche Navigation je nach Seitenladevorgang unterschiedlich gemeldet werden. Ebenso kann das Laden einer Seite mit einem Ankerlink weiter unten auf der Seite zu einem anderen LCP-Element führen.

Wie wird die TTFB gemessen?

Die Zeit bis zum ersten Byte (TTFB) bei einem herkömmlichen Seitenladevorgang gibt an, wie lange es dauert, bis die ersten Bytes 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 des Back-Forward-Cache empfehlen. Dies ist die Methode, die die web-vitals-Bibliothek für die Softnavigation verwendet.

In Zukunft werden wir möglicherweise genauere Möglichkeiten unterstützen, um zu ermitteln, welche Anfrage die Navigationsanfrage der Softnavigation ist. So können wir genauere TTFB-Messungen vornehmen. Das ist aber nicht Teil des aktuellen Tests.

Wie kann ich sowohl die alten als auch die neuen Daten 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.

web-vitals-Bibliothek zum Messen der Core Web Vitals für die Navigation ohne Neuladen verwenden

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 erfasst.
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 endgültig ermittelt werden kann.
CLS	Der größte Zeitraum zwischen den Navigationszeiten. Wie üblich geschieht dies, wenn die Seite im Hintergrund ist, da nur dann der CLS endgültig berechnet werden kann. Wenn es keine Schichten gibt, wird der Wert 0 erfasst.
INP	Die INP zwischen den Navigationszeiten. Wie gewohnt wird dies nach einer Interaktion oder wenn die Seite im Hintergrund geöffnet ist, gemeldet, da nur 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 schrittweise 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 Soft Navigationen in CrUX 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 werden diese Navigationen möglicherweise separat in CrUX erfasst oder bei der Berechnung der Core Web Vitals für eine bestimmte Seite oder Gruppe von Seiten gewichtet. Mit der Weiterentwicklung der Heuristik können wir die Navigation bei teilweisem Laden möglicherweise 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 freuen uns über Feedback zu diesem Test an den folgenden Stellen:

• 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 für die schrittweise Navigation ist ein spannender Ansatz, wie sich die Core Web Vitals-Initiative weiterentwickeln könnte, um ein gängiges Muster im modernen Web zu erfassen, 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