Soft-Navigationen messen

Barry Pollard

Michal Mocny

Veröffentlicht: 1. Februar 2023, letzte Aktualisierung: 20. September 2026

Seit ihrer Einführung wird mit der Core Web Vitals-Initiative versucht, die tatsächliche Nutzerfreundlichkeit einer Website zu messen, anstatt die technischen Details hinter der Erstellung oder dem Laden einer Website zu berücksichtigen. Die drei Core Web Vitals-Messwerte wurden als nutzerorientierte Messwerte entwickelt. Sie sind eine Weiterentwicklung bestehender technischer Messwerte wie DOMContentLoaded oder load, die Zeiten gemessen haben, die oft nichts damit zu tun hatten, wie Nutzer die Leistung der Seite wahrgenommen haben. Daher sollte die Technologie, die zum Erstellen der Website verwendet wird, keinen Einfluss auf die Bewertung haben, sofern die Website eine gute Leistung erbringt.

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

Viele JavaScript-Frameworks verwenden dieses Modell, aber jedes auf eine andere Weise. Da dies außerhalb dessen liegt, was der Browser herkömmlicherweise als „Seite“ versteht, war die Messung schon immer schwierig: Wo ist die Grenze zwischen einer Interaktion auf der aktuellen Seite und einer Interaktion, die als neue Seite betrachtet wird?

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

Wir haben den Vorschlag basierend auf dem Feedback von Entwicklern mehrfach verbessert und zwei neue Performance APIs eingeführt, um dieses Problem ab Chrome 151 zu beheben. Außerdem haben wir die Messwerte für die weiche Navigation im Chrome User Experience Report (CrUX) als experimentelle Messwerte verfügbar gemacht.

Was ist eine weiche 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 Paint.

Bei einigen Websites kann diese Definition zu falsch positiven Ergebnissen führen (Nutzer würden nicht wirklich davon ausgehen, dass eine „Navigation“ stattgefunden hat) oder zu falsch negativen Ergebnissen (Nutzer gehen davon aus, dass eine „Navigation“ stattgefunden hat, obwohl diese Kriterien nicht erfüllt sind). Wir freuen uns über Feedback im Repository für die Spezifikation von Soft Navigations.

DevTools-Unterstützung für Soft-Navigationen

Wir haben die Unterstützung für Soft Navigations im Leistungsbereich der Entwicklertools in der Ansicht Live-Messwerte und in der Trace-Ansicht mit Unterstützung für Statistiken und Markierungen hinzugefügt:

Wie implementiert Chrome weiche Navigationen für Webentwickler?

Sobald die Funktion für weiche Navigation aktiviert ist (mehr dazu im nächsten Abschnitt), ändert sich die Art und Weise, wie Chrome einige Leistungsmesswerte meldet:

• Nach jeder erkannten weichen Navigation wird ein soft-navigation-PerformanceTiming-Ereignis ausgegeben.
• Dieser soft-navigation-Eintrag enthält einen navigationId, die neue URL im Attribut name sowie einen interactionId der initiierenden Interaktion.
• Nach Interaktionen, die zu einem Contentful Paint führen, werden ein oder mehrere interaction-contentful-paint-Einträge ausgegeben. Dieser enthält einen largestContentfulPaint-Eintrag, mit dem der Largest Contentful Paint (LCP) für Soft Navigations gemessen werden kann.
• Das Attribut navigationId wird jedem der Leistungstimings (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event und layout-shift) hinzugefügt. Dies entspricht dem Navigationseintrag, unter dem das Ereignis ausgegeben wurde. Wenn diese Einträge Soft Navigations umfassen, können sie je nachdem, wann der Eintrag ausgegeben wurde, die vorherige oder nächste navigationId enthalten. Weitere Informationen dazu findest du im Abschnitt Messwerte für die entsprechende URL melden.
• Die soft-navigation enthält eine getLargestInteractionContentfulPaint()-Funktion, um den größten interaction-contentful-paint-Eintrag für diese Navigation abzurufen. Dieser kann dann als anfänglicher LCP für diese Navigation verwendet und aktualisiert werden, wenn weitere interaction-contentful-paint-Einträge für diese Interaktion beobachtet werden. Hinweis: Dadurch wird das Attribut largestInteractionContentfulPaint ersetzt, das in früheren Ursprungstests verfügbar war.
• Möglicherweise sind einige interaction-contentful-paint-Einträge vor der Soft-Navigation aufgetreten, wenn die URL erst nach diesen Paint-Ereignissen aktualisiert wird. In diesen Fällen wird durch die Funktion getLargestInteractionContentfulPaint() vermieden, dass nach Abschluss einer Soft-Navigation alte Einträge zwischengespeichert und noch einmal geprüft werden müssen. Der von getLargestInteractionContentfulPaint() zurückgegebene Eintrag ist eine exakte Kopie des größten interaction-contentful-paint-Eintrags zum Zeitpunkt der Ausgabe. Dieser Eintrag hat möglicherweise die vorherige navigationId verwendet, da das Rendering zu diesem Zeitpunkt stattfand. Diese Renderings sollten jedoch mit der 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 den Soft Navigations interactionId entsprechen, um diese auszuschließen, und auch nur auf largestContentfulPaint-Eigenschaften innerhalb dieser.

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 von Soft-Navigations in Chrome?

Hier sind einige der Änderungen, die Websiteinhaber nach der Aktivierung dieser Funktion berücksichtigen müssen:

• Durch das Monitoring der soft-navigation-Einträge können die Leistungseinträge in die einzelnen „Navigationen“ aufgeteilt werden.
• Die CLS- und INP-Messwerte können bereits nach Belieben aufgeteilt werden, anstatt über die Dauer des gesamten Seitenlebenszyklus gemessen zu werden. Die Funktion „Soft Navigation“ bietet jedoch ein standardisiertes Maß dafür, wann dies geschieht, unabhängig von der zugrunde liegenden Technologie.
• Der Eintrag largest-contentful-paint wird bei einer Interaktion abgeschlossen, die zum Starten einer Soft-Navigation erforderlich ist. Er kann daher nur zur Messung des LCP der ersten „Hard“-Navigation verwendet werden. Das bedeutet, dass sich nichts daran ändert, wann Soft Navigations gemessen werden. Der LCP für den ersten Seitenaufbau (Hard Navigation) kann also wie gewohnt gemessen werden.
• Der neue interaction-contentful-paint-Eintrag, der bei Interaktionen ausgegeben wird, kann verwendet werden, um den LCP für Soft Navigations zu messen. Dazu wird die darin enthaltene largestContentfulPaint-Property herangezogen. Es gibt jedoch einige Überlegungen zur Verwendung dieses Eintrags, die wir in diesem Artikel besprechen werden.
• Beachten Sie, dass diese Funktion für die weiche Navigation nicht von allen Nutzern unterstützt wird, insbesondere nicht von Nutzern, die andere Browser oder Chrome-Versionen vor 151 verwenden. Beachten Sie, dass einige Nutzer möglicherweise keine Messwerte für die weiche Navigation melden, auch wenn sie Core Web Vitals-Messwerte melden.

Fragen Sie Ihren RUM-Anbieter, ob er die Messung der Core Web Vitals per Soft-Navigation unterstützt. Viele planen, diesen neuen Standard zu testen, und werden die oben genannten Überlegungen berücksichtigen. In der Zwischenzeit erlauben einige Anbieter auch eingeschränkte Messungen von Leistungsmesswerten auf der Grundlage ihrer eigenen Heuristik.

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

Wie aktiviere ich weiche Navigationen in Chrome?

Die Funktion für weiche Navigation ist ab Chrome 151 standardmäßig aktiviert.

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
}

Oder alternativ:

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

Wie kann ich weiche Navigationen messen?

Sofern unterstützt, können die Messwerte wie andere Messwerte auch über die PerformanceObserver API gemeldet werden. Bei diesen Messwerten sind jedoch einige zusätzliche Aspekte zu berücksichtigen.

Soft-Navigationen melden

Sie können einen PerformanceObserver verwenden, um Soft-Navigationen zu beobachten. Im folgenden Code-Snippet werden Soft-Navigationseinträge in der Konsole protokolliert, einschließlich früherer Soft-Navigationen auf dieser Seite mit der Option buffered:

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

Damit können die Messwerte für die gesamte Lebensdauer der Seite für die vorherige Navigation abgeschlossen werden.

Messwerte für die entsprechende URL melden

Wenn eine weiche Navigation erkannt wird, sollten die Core Web Vitals der vorherigen Seite abgeschlossen und dann für die vorherige URL gemeldet werden. Außerdem sollte ein neues Monitoring für die neue URL gestartet werden.

Das Attribut name des entsprechenden soft-navigation-Eintrags enthält die neue URL, für die Berichtsmesswerte erfasst werden sollen. navigationId ist die eindeutige Referenz für diese Navigation, da dieselbe URL während der Lebensdauer einer Single-Page-Anwendung mehrmals aufgerufen werden kann.

Dieser sollte als jeder soft-navigation-Eintrag festgelegt und zum Melden von Messwerten verwendet werden, bis der nächste soft-navigation-Eintrag empfangen wird.

Richtige URL für interaction-contentful-paint melden

Bei der Berechnung des LCP aus interaction-contentful-paint-Einträgen sind zusätzliche Überlegungen erforderlich, da nicht alle interaction-contentful-paint-Einträge mit dem navigationId zugeordnet und als LCP für diese URL gemeldet werden sollten:

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

Daher sollte die interactionId anstelle der navigationId verwendet werden, um interaction-contentful-paint-Einträge der 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 den LCP berücksichtigt werden sollten.

Außerdem sollten Sie zuerst die Funktion getLargestInteractionContentfulPaint() der soft-navigation-Einträge verarbeiten, um interaction-contentful-paint-Einträge zu verarbeiten, die vor der Ausgabe von soft-navigation entries aufgetreten sind.

startTime der Soft-Navigationen abrufen

Alle Leistungsmesswerte, einschließlich derer für Soft-Navigations, und die Einträge, die zur Berechnung der Core Web Vitals-Messwerte verwendet werden, werden als Zeit ab der ersten „Hard“-Seitennavigation angegeben. Daher sollte die Startzeit der weichen Navigation von den Ladezeitmesswerten der weichen Navigation (z. B. LCP) abgezogen werden, um sie stattdessen relativ zu dieser Zeit der weichen Navigation zu melden.

Die Startzeit der Navigation kann auf ähnliche Weise ermittelt werden, indem sie dem entsprechenden 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 weiche Navigation initiiert hat. Dies unterscheidet sich etwas von „harten Navigationen“, bei denen die „Startzeit“ der Zeitpunkt ist, an dem die neue Seite an den Browser „übergeben“ wird und nachdem ein Teil des Event-Handler-Codes ausgeführt wurde. Die Startzeiten für die weiche Navigation umfassen auch diesen Event-Handler-Code, da wir ab der Startzeit der Interaktion messen.

Core Web Vitals pro Soft Navigation messen

Wenn Sie die Core Web Vitals messen möchten, müssen Sie auf soft-navigation-Einträge warten und die Messwerte zurücksetzen, wenn Sie diese erhalten. Der FCP kann basierend auf dem presentationTime-Eintrag ausgegeben und der LCP kann auf den getLargestInteractionContentfulPaint()-Eintrag 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. Eine Ausnahme ist die Verwendung von interaction-contentful-paint für LCP, sofern die interactionId-Werte übereinstimmen. Mit dem interactionId können die Einträge für eine URL benannt werden, wie oben beschrieben.

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

Einige Messwerte wurden bisher während der gesamten 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, unabhängig von Interaktionen. Daher sollten die Messwerte der vorherigen Navigation abgeschlossen werden, wenn eine neue weiche Navigation erfolgt. Das bedeutet, dass die anfänglichen „harten“ Navigationsmesswerte möglicherweise früher als üblich abgeschlossen werden, wenn Core Web Vitals mit Soft-Navigationen gemessen werden.

Wenn Sie mit der Messung der Messwerte für die neue Soft-Navigation dieser langlebigen Messwerte beginnen, müssen die Messwerte „zurückgesetzt“ oder „neu initialisiert“ und als neue Messwerte behandelt werden, ohne dass die Werte für vorherige „Seiten“ gespeichert werden. Das heißt, die Definition des „größten“ Paint, der Interaction to Next Paint oder der Layoutverschiebung wird zurückgesetzt, damit die Messung von vorn beginnen kann.

Wie sollte mit Inhalten umgegangen werden, die sich zwischen Navigationsschritten nicht ändern?

Der LCP für Soft Navigations (berechnet ab interaction-contentful-paint) misst nur neue Darstellungen und nur Darstellungen, die mit der Interaktion verknüpft sind, die die Navigation ausgelöst hat. Dies kann dazu führen, dass der LCP bei einem kalten Laden dieser weichen Navigation anders ist als bei einem weichen Laden.

Nehmen wir zum Beispiel eine Seite mit einem großen Bannerbild, das das LCP-Element ist, aber der Text darunter ändert sich bei jeder Soft-Navigation. Beim ersten Laden der Seite wird das Bannerbild als LCP-Element gekennzeichnet und die LCP-Zeit darauf basiert. Bei nachfolgenden Soft Navigations ist der Text darunter das größte Element, das nach der Soft Navigation dargestellt wird, und wird zum neuen LCP-Element. Wenn die Seite jedoch mit einem Deeplink zur URL der weichen Navigation geladen wird, wird das Bannerbild neu gerendert und kann daher als LCP-Element betrachtet werden.

Ebenso kann eine Animation einen Teil der Seite kontinuierlich aktualisieren, unabhängig von einer Soft-Navigation. Neue Darstellungen aufgrund dieser Hintergrundanimation 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 weiche Navigation je nach Art des Seitenaufrufs unterschiedlich gemeldet werden. Das ist vergleichbar mit dem Laden einer Seite mit einem Ankerlink weiter unten auf der Seite, was bei harten Navigationen zu einem anderen LCP-Element führen kann.

Wie wird die TTFB gemessen?

Time to First Byte (TTFB) für einen herkömmlichen Seitenaufbau stellt die Zeit dar, die die ersten Bytes der ursprünglichen Anfrage benötigen, um zurückgegeben zu werden.

Bei einer weichen Navigation ist das eine schwierigere Frage. Sollten wir die erste Anfrage für die neue Seite messen? Was ist, wenn alle Inhalte bereits in der App vorhanden sind und keine zusätzlichen Anfragen gestellt werden? Was ist, wenn diese Anfrage im Voraus mit einem Prefetch gestellt wird? Was ist, wenn eine Anfrage aus Nutzersicht nichts mit der weichen Navigation zu tun hat (z. B. eine Analyseanfrage)?

Eine einfachere Methode besteht darin, für weiche Navigationen eine TTFB von 0 zu melden, ähnlich wie wir es für die Wiederherstellung aus dem Back-Forward-Cache empfehlen. Diese Methode wird von der web-vitals-Bibliothek für weiche Navigationen verwendet und ist die Methode, die wir derzeit für diesen Messwert empfehlen.

Sollten Sie die Core Web Vitals mit beiden Methoden messen?

Diese neuen APIs sind zwar auf Chromium-basierte Browser beschränkt, aber Websites können beide Arten von Navigationen messen, indem sie die Daten nach Soft-Navigationen und Hard-Navigationen aufteilen. So wäre ein Vergleich zwischen Browsern und historischen Trends möglich.

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

Für CLS und INP bedeutet dies, dass diese Werte wie bisher über den gesamten Lebenszyklus der Seite gemessen werden und die Zeitachse separat nach Soft Navigations aufgeteilt wird, um separate CLS- und INP-Werte für die neue Seite zu messen.

Die Messwerte müssten dann zweimal übertragen und für die Analyse gespeichert werden.

Verwenden Sie die web-vitals-Bibliothek, um die Core Web Vitals für Soft Navigations zu messen.

Am einfachsten lassen sich alle Nuancen berücksichtigen, wenn Sie die JavaScript-Bibliothek web-vitals verwenden, die ab Version 6.0.0 Soft Navigations unterstützt. Dies kann so gemessen werden (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 erfasst werden, wie bereits erwähnt, da sie sowohl die navigationId als auch eine navigationURL in den Einträgen enthalten, die für den Callback bereitgestellt werden.

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

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

Das oberste Ziel ist es, eine Möglichkeit zu bieten, die Leistung besser zu messen, wie sie von echten Nutzern erlebt wird. Ja, das Ziel ist es, diese in die Core Web Vitals-Messungen aufzunehmen, die von allen Tools nach der Einführung der API angezeigt werden.

Wie werden weiche Navigationen im CrUX gemeldet?

Wir haben experimentelle Versionen der Core Web Vitals-Messwerte in CrUX eingeführt. Damit werden die CLS- und INP-Werte für die „harte Navigation“ nach der ersten weichen Navigation beendet. Außerdem werden zusätzliche LCP-, CLS- und INP-Messungen für jede weiche Navigation einbezogen. Wir planen, diese experimentellen Messwerte im Mai 2027 zu stabilen Messwerten zu machen. Weitere Informationen finden Sie im Blogpost Experimentelle Messwerte für die weiche Navigation jetzt in CrUX verfügbar.

Wie werden weiche Navigationen in anderen Browsern gehandhabt?

In Browsern, die die API nicht unterstützen, lassen sich weiche Navigationen nur schwer programmatisch erkennen. Genau deshalb haben wir diese API entwickelt.

Mit der Navigation API können Sie URL-Änderungen überwachen, um den INP nach URL aufzuschlüsseln (und ähnlich den CLS, obwohl dieser derzeit nur in Chromium verfügbar ist und daher ohnehin nicht gemessen wird). Die Paint-Messwerte (FCP und LCP) werden dabei jedoch nicht berücksichtigt, da sie nur geschätzt werden können.

Gleichzeitig sind wir der Meinung, dass die von dieser API angebotenen Informationen zu wertvoll sind, um sie zu ignorieren, sowohl bei der Messung des Timings von Soft Navigations als auch bei der Zuordnung der Messwerte zur richtigen Navigation. Wir empfehlen, diese neue API zu verwenden, auch wenn sie derzeit nicht von allen Browsern unterstützt wird. Wie bei der Einführung der Core Web Vitals werden die identifizierten Probleme und die Lösungen zur Leistungsverbesserung wahrscheinlich alle Browser betreffen, auch wenn die Sichtbarkeit vorerst auf Chromium-basierte Browser beschränkt ist.

Wir werden den Standardisierungsprozess weiter vorantreiben und mit anderen Browseranbietern zusammenarbeiten, um die Bedeutung dieser API zu verdeutlichen.

Feedback

Wir freuen uns über Feedback zu dieser API an den folgenden Stellen:

• Feedback zur API sollte als Problem auf GitHub gemeldet werden.
• Fehler in der Chromium-Implementierung sollten im Issue Tracker von Chrome 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 Orten und werden die Probleme an beiden Orten gerne sichten und an die richtige Stelle weiterleiten.

Änderungsprotokoll

Während der Entwicklung dieser API wurden mehr Änderungen daran vorgenommen als an stabilen APIs. Weitere Informationen finden Sie im Änderungsprotokoll für weiche Navigation.

Fazit

Die Funktion „Soft Navigations“ ist ein interessanter Ansatz, wie sich die Core Web Vitals-Initiative weiterentwickeln könnte, um ein gängiges Muster im modernen Web zu messen, das in unseren Messwerten fehlt. Wir haben umfangreiches Feedback von der Web-Community erhalten und sind vom Potenzial dieser API überzeugt.

Danksagungen

Miniaturansicht von Jordan Madrid auf Unsplash

Diese Arbeit ist eine Fortsetzung der Arbeit, die Yoav Weiss während seiner Zeit bei Google begonnen hat. Wir danken Yoav für seine Arbeit an dieser API.