Experimentieren mit dem Messen der weichen Navigation

Barry Pollard

Yoav Weiss

Seit der Einführung der Core Web Vitals-Initiative geht es darum, die tatsächliche Nutzererfahrung einer Website zu messen, und nicht die technischen Details, wie eine Website erstellt oder geladen wird. Die drei Core Web Vitals-Messwerte wurden als nutzerorientierte Messwerte erstellt. Das ist eine Weiterentwicklung bestehender technischer Messwerte wie DOMContentLoaded oder load, bei denen Zeitangaben ermittelt wurden, die oft keinen Bezug dazu hatten, wie Nutzer die Leistung der Seite wahrgenommen haben. Aus diesem Grund sollte sich die für die Erstellung der Website verwendete Technologie nicht auf die Bewertung auswirken, sofern die Website eine gute Leistung erzielt.

Die Realität ist immer etwas kniffliger als das Ideal. Außerdem wurde die beliebte Single-Page-Anwendungsarchitektur nie vollständig von den Core Web Vitals-Messwerten unterstützt. Anstatt beim Navigieren durch den Nutzer verschiedene einzelne Webseiten zu laden, nutzen diese Webanwendungen sogenannte weiche Navigationen, bei denen der Seiteninhalt stattdessen durch JavaScript geändert wird. In diesen Anwendungen wird der Eindruck einer konventionellen Webseitenarchitektur beibehalten, indem die URL geändert und vorherige URLs im Browserverlauf verschoben werden, damit die Zurück- und Weiter-Schaltflächen erwartungsgemäß funktionieren.

Viele JavaScript-Frameworks verwenden dieses Modell, aber jedes auf unterschiedliche Weise. Da dies nicht dem entspricht, was der Browser normalerweise als „Seite“ bezeichnet, war es immer schwierig, dies zu messen: Wo muss die Grenze zwischen einer Interaktion auf der aktuellen Seite und der Betrachtung als neue Seite betrachtet werden?

Das Chrome-Team befasst sich bereits seit einiger Zeit mit dieser Herausforderung und arbeitet daran, eine Definition dafür zu standardisieren, was eine „weiche Navigation“ ist und wie die Core Web Vitals dafür gemessen werden können. Die Messung erfolgt auf ähnliche Weise wie für Websites, die in der konventionellen Mehrseitenarchitektur (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 für den Nutzer sichtbaren Änderung der URL 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 (die Nutzer würden eine „Navigation“ eigentlich nicht als solches betrachten) oder zu falsch negativen Ergebnissen (der Nutzer glaubt, dass eine „Navigation“ erfolgt ist, obwohl er diese Kriterien nicht erfüllt). Wir freuen uns über Feedback zur Heuristik im Repository für Spezifikationen für die weiche Navigation.

Wie implementiert Chrome die weiche Navigation?

Sobald die Heuristik der weichen Navigation aktiviert ist (mehr dazu im nächsten Abschnitt), ändert Chrome die Berichterstellung für einige Leistungsmesswerte:

• Das soft-navigation-Ereignis PerformanceTiming wird ausgegeben, nachdem jede sanfte Navigation erkannt wurde.
• Die Performance API bietet Zugriff auf einen soft-navigation-Zeiteintrag, der durch das soft-navigation-PerformanceTiming-Ereignis ausgegeben wurde.
• Die Messwerte First Paint (FP), First Contentful Paint (FCP) und Largest Contentful Paint (LCP) werden zurückgesetzt und beim nächsten Mal wieder ausgegeben. Hinweis: FP und FCP sind nicht implementiert.
• Das Attribut navigationId wird jeder Leistungszeit (first-paint, first-contentful-paint, largest-contentful-paint, first-input-delay, event und layout-shift) hinzugefügt, die dem Navigationseintrag entspricht, auf den sich das Ereignis bezieht. Dadurch 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.

Welche Auswirkungen hat die Aktivierung der weichen Navigation in Chrome?

Nach der Aktivierung dieser Funktion müssen Websiteinhaber folgende Änderungen berücksichtigen:

• Für die weiche Navigation können weitere FP-, FCP- und LCP-Ereignisse ausgegeben werden. Im Bericht zur Nutzererfahrung in Chrome werden diese zusätzlichen Werte ignoriert. Das kann sich aber auf die Analyse der Echtzeitdaten (Real User Measurement, RUM) auf Ihrer Website auswirken. Wende dich an deinen RUM-Anbieter, wenn du Bedenken hast, ob sich das auf diese Messungen auswirken wird. Weitere Informationen finden Sie im Abschnitt zur Messung von Core Web Vitals für eine weiche Navigation.
• Das neue (und optionale) Attribut navigationID in Ihren Leistungseinträgen muss möglicherweise anhand dieser Einträge in Ihrem Anwendungscode berücksichtigt werden.
• Dieser neue Modus wird nur von Chromium-basierten Browsern unterstützt. Während viele der neueren Messwerte nur in Chromium-basierten Browsern verfügbar sind, sind einige (FCP, LCP) auch in den anderen Browsern verfügbar. Möglicherweise haben nicht alle Nutzer ein Upgrade auf die neueste Version der Chromium-basierten Browser ausgeführt. Beachten Sie daher, dass einige Nutzer unter Umständen keine Messwerte für die weiche Navigation melden.
• Es handelt sich um eine neue experimentelle Funktion, die nicht standardmäßig aktiviert ist. Websites sollten diese Funktion testen, um sicherzustellen, dass keine anderen unbeabsichtigten Nebeneffekte auftreten.

Weitere Informationen zum Messen der Messwerte für die weiche Navigation finden Sie im Abschnitt Core Web Vitals für die weiche Navigation messen.

Wie aktiviere ich die weiche 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 unter chrome://flags/#enable-experimental-web-platform-features aktivieren oder beim Starten von Chrome das Befehlszeilenargument --enable-experimental-web-platform-features verwenden.

Wie kann ich eine weiche Navigation messen?

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

Soft Navigationen melden

Sie können PerformanceObserver verwenden, um weiche Navigationen zu 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 });

Dies kann verwendet werden, um die Seitenmesswerte für das gesamte Leben für die vorherige Navigation zu finalisieren.

Melden Sie die Messwerte für die entsprechende URL.

Da weiche Navigationen erst im Nachhinein sichtbar sind, müssen einige Messwerte für dieses Ereignis finalisiert und dann für die vorherige URL erfasst werden, da die aktuelle URL nun die aktualisierte URL für die neue Seite darstellt.

Das navigationId-Attribut der entsprechenden PerformanceEntry kann verwendet werden, um das Ereignis der richtigen URL zuzuordnen. Dies kann 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;

Diese pageUrl sollte verwendet werden, um die Messwerte für die richtige URL und nicht für die aktuelle URL zu melden, die möglicherweise in der Vergangenheit verwendet wurde.

startTime von weichen 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 gibt den Zeitpunkt der ersten Interaktion an (z. B. das Klicken auf eine Schaltfläche), mit der die weiche Navigation initiiert wurde.

Alle Leistungsstatistiken, einschließlich jener für weiche Navigationen, werden als Zeit ab dem anfänglichen „schwierigen“ Zeitraum angegeben. Seitennavigationszeit. Daher wird die Startzeit der weichen Navigation benötigt, um die Zeiten des Lademesswerts für die weiche Navigation (z. B. LCP) im Verhältnis zu dieser Zeit zu ermitteln.

Core Web Vitals für weiche 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 Flag includeSoftNavigationObservations für die Methode observe wird zusätzlich zur Aktivierung der Funktion „Softnavigation“ in Chrome benötigt. Diese ausdrückliche Aktivierung auf Ebene des Leistungsbeobachters soll bestehende Leistungsbeobachter von diesen zusätzlichen Einträgen nicht überrascht werden, da bei der Messung von Core Web Vitals für weiche Navigationen einige zusätzliche Aspekte berücksichtigt werden müssen.

Timings werden weiterhin in Bezug auf die ursprüngliche "schwer"-Angabe zurückgegeben. Startzeit der Navigation. Um den LCP-Wert für eine weiche Navigation beispielsweise zu berechnen, müssen Sie das LCP-Timing messen und die entsprechende Startzeit der weichen Navigation abziehen, wie oben detailliert beschrieben, um ein Timing relativ zur weichen Navigation zu erhalten. Zum 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 Lebensdauer der Seite gemessen: Der LCP kann sich beispielsweise ändern, bis eine Interaktion stattfindet. CLS und INP können aktualisiert werden, bis die Seite verlassen wird. Daher ist jede "Navigation" (einschließlich der ursprünglichen Navigation) müssen die Messwerte der vorherigen Seite möglicherweise fertig gestellt werden, wenn bei jeder neuen sanften Navigation eine neue verwendet wird. Das bedeutet, dass die anfängliche Navigationsmetriken möglicherweise früher als üblich fertiggestellt werden.

Gleichermaßen müssen die Messwerte zurückgesetzt werden, wenn Sie damit beginnen, die Messwerte für die neue sanfte Navigation dieser langlebigen Messwerte zu messen. oder „neu initialisiert“ und als neue Messwerte behandelt werden, ohne dass sich die Werte, die für vorherige „Seiten“ festgelegt wurden, mehr merken.

Wie sollten Inhalte behandelt werden, die zwischen den einzelnen Aufrufen gleich bleiben?

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

Nehmen wir zum Beispiel eine Seite mit einem großen Bannerbild, das das LCP-Element ist, bei dem sich der Text darunter jedoch mit jeder sanften Navigation ändert. Beim ersten Seitenaufbau wird das Bannerbild als LCP-Element gekennzeichnet und das LCP-Timing darauf basiert. Bei nachfolgenden weichen Navigationen wird der Text darunter als größtes Element nach der weichen Navigation dargestellt und ist 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 herkömmlichen Seitenaufbau gibt an, wie lange die ersten Byte der ursprünglichen Anfrage zurückgegeben werden.

Für eine weiche Navigation ist dies eine schwierigere Frage. Sollten wir die erste Anfrage für die neue Seite analysieren? Was passiert, wenn alle Inhalte bereits in der App vorhanden sind und es keine zusätzlichen Anfragen gibt? Was passiert, wenn diese Anfrage im Voraus über einen Prefetch gesendet wird? Was passiert, wenn eine Anfrage, die sich nicht auf die weiche Navigation aus Sicht des Nutzers bezieht (z. B. eine Analyseanfrage),?

Eine einfachere Methode ist, die TTFB von 0 für weiche Navigationen zu melden, ähnlich wie wir für Wiederherstellungen im Back-Forward-Cache empfehlen. Das ist die Methode, die von der web-vitals-Bibliothek für weiche Navigationen verwendet wird.

In Zukunft werden möglicherweise genauere Methoden unterstützt, um zu ermitteln, welche Anfrage die „Navigationsanfrage“ der Soft Navigation ist. und genauere TTFB-Messungen erhalten. Aber das ist nicht Teil des aktuellen Tests.

Wie lassen sich alte und neue Erkenntnisse messen?

Während des Tests empfehlen wir, die Core Web Vitals weiterhin auf die aktuelle Weise zu messen, basierend auf der Bewertung „schwer“. Seitennavigationen, die dem entsprechen, was von CrUX als offizielles Dataset der Core Web Vitals-Initiative gemessen und in Berichten ausgewertet wird.

Zusätzlich sollten Sie die weichen Navigationen messen, damit Sie sehen, wie sie in Zukunft gemessen werden könnten. Außerdem haben Sie die Möglichkeit, dem Chrome-Team Feedback zur Funktionsweise der Implementierung zu geben. Dies hilft Ihnen und dem Chrome-Team dabei, die API in Zukunft zu gestalten.

Wenn Sie beides messen möchten, müssen Sie die neuen Ereignisse kennen, die im Modus für die weiche Navigation ausgegeben werden können (z. B. mehrere FCP- und zusätzliche LCP-Ereignisse), und diese Ereignisse entsprechend verarbeiten, indem Sie diese Messwerte zum richtigen Zeitpunkt fertigstellen und zukünftige Ereignisse ignorieren, die nur bei der sanften Navigation auftreten.

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

Die einfachste Möglichkeit, alle Nuancen zu berücksichtigen, ist die Verwendung der web-vitals-JavaScript-Bibliothek, die experimentelle Unterstützung für weiche Navigationen in einem separaten soft-navs branch bietet (die auch auf npm und unpkg verfügbar ist). Dies kann folgendermaßen gemessen werden (ersetzen Sie doTraditionalProcessing und doSoftNavProcessing je 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});

Prüfen Sie, ob die Messwerte wie oben beschrieben für die richtige URL gemeldet werden.

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

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

Dieser Test mit weicher Navigation ist genau das – ein Test. Wir möchten die Heuristiken bewerten, um zu sehen, ob sie die Nutzererfahrung genauer widerspiegeln, bevor wir entscheiden, ob sie in die Core Web Vitals-Initiative integriert werden. Wir freuen uns sehr über diesen Test, können aber nicht garantieren, dass die aktuellen Messungen dadurch ersetzt werden.

Wir schätzen die Feedback zum Test, die verwendeten Heuristiken und ob es deiner Meinung nach die Erfahrung genauer widerspiegelt. Der beste Ort für dieses Feedback ist das GitHub-Repository für die Softnavigation. Einzelne Fehler bei der Implementierung von Chrome sollten jedoch im Chrome Issue Tracker gemeldet werden.

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

Wie genau weiche Navigationen in CrUX erfasst werden, sollte dieser Test erfolgreich sein, steht noch nicht fest. Es ist nicht unbedingt gegeben, dass sie wie die aktuellen „schwer“ behandelt werden. behandelt werden.

Auf einigen Webseiten ist die weiche Navigation in Bezug auf den Nutzer fast mit dem Laden ganzer Seiten identisch. Die Verwendung der Single-Page-Anwendungstechnologie ist nur ein Implementierungsdetail. In anderen ähneln sie möglicherweise eher einer teilweisen Ladung 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 Umsetzung, sodass wir den Erfolg dieses Tests beurteilen können. Daher wurde noch keine Entscheidung getroffen.

Feedback

Wir freuen uns über Feedback zu diesem Test:

• Heuristik und Standardisierung der weichen Navigation:
• Probleme bei der Chrome-Implementierung dieser Heuristiken.
• Allgemeines Feedback zu Web Vitals findest du unter web-vitals-feedback@googlegrouops.com.

Änderungsprotokoll

Da sich diese API noch in der Testphase befindet, gibt es eine Reihe von Änderungen. Dies gilt mehr als bei stabilen APIs. Weitere Informationen finden Sie im Änderungsprotokoll zu Soft Navigation Heuristik.

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. Dieses Experiment steht noch am Anfang und es gibt noch viel zu tun. Es ist ein wichtiger Schritt, die bisherigen Fortschritte der breiteren Web-Community zum Experimentieren zur Verfügung zu stellen. Das Sammeln von Feedback zu diesem Test ist ein weiterer wichtiger Teil des Tests. Daher empfehlen wir allen, die an dieser Entwicklung interessiert sind, diese Gelegenheit, die API zu gestalten, damit sie für die Ergebnisse repräsentativ ist, die wir damit messen können.

Danksagungen

Miniaturansicht von Jordan Madrid auf Unsplash