Experimentieren mit dem Messen der weichen Navigation

Barry Pollard

Yoav Weiss

Aktualisierung im April 2024:Der Ursprungspfad für die sanfte Navigation endet am 29. Mai. Das Chrome-Team wird sich dann Zeit nehmen, das Testfeedback zu prüfen und die nächsten Schritte für diese API zu erwägen. Wir möchten einige Genauigkeitsprobleme beheben und gehen davon aus, dass ein weiterer Ursprungstest erforderlich ist, bevor die Funktion fortgesetzt werden kann. In der Zwischenzeit können Entwickler die Funktion weiter ausprobieren, indem sie chrome://flags/#enable-experimental-web-platform-features aktivieren.

Seit ihrer Einführung hat die Core Web Vitals-Initiative das Ziel verfolgt, die tatsächliche Nutzerfreundlichkeit einer Website zu messen. Es geht nicht darum, technische Details dazu zu erfassen, wie eine Website erstellt oder geladen wird. Die drei Core Web Vitals-Messwerte wurden als nutzerbezogene Messwerte erstellt – eine Weiterentwicklung gegenüber bestehenden technischen Messwerten wie DOMContentLoaded oder load, bei denen Zeitmessungen gemessen wurden, die oft keinen Bezug dazu hatten, wie die Nutzer die Leistung der Seite wahrgenommen haben. Aus diesem Grund sollte die beim Erstellen der Website verwendete Technologie sich nicht auf die Bewertung auswirken, durch die eine gute Leistung der Website gewährleistet wird.

Die Realität ist immer etwas kniffliger und die beliebte Architektur für Single-Page-Anwendungen wurde noch nie vollständig durch die Core Web Vitals-Messwerte unterstützt. Anstatt verschiedene, einzelne Webseiten zu laden, während der Nutzer durch die Website navigiert, verwenden diese Webanwendungen sogenannte „weiche Navigationen“, bei denen der Seiteninhalt durch JavaScript geändert wird. In diesen Anwendungen wird die Illusion einer konventionellen Webseitenarchitektur beibehalten, indem die URL geändert und vorherige URLs im Browserverlauf übertragen werden, damit die Zurück- und Vorwärts-Schaltflächen so funktionieren, wie es der Nutzer erwarten würde.

Dieses Modell wird von vielen JavaScript-Frameworks verwendet, aber alle auf unterschiedliche Weise. Da dies außerhalb dessen liegt, was der Browser normalerweise als „Seite“ versteht, war es immer schwierig, dies zu messen: Wo muss die Grenze zwischen einer Interaktion auf der aktuellen Seite und einer neuen Seite gezogen werden?

Das Chrome-Team beschäftigt sich bereits seit einiger Zeit mit dieser Herausforderung und möchte nun standardisieren, was eine „Soft-Navigation“ ist und wie die Core Web Vitals gemessen werden können – ähnlich wie bei Websites, die in der konventionellen mehrseitigen Architektur (MPA) implementiert sind. Das Team befindet sich noch in einem frühen Stadium, ist nun aber in der Lage, die bereits implementierten Elemente auf größere Websites zum Experimentieren zur Verfügung zu stellen. So können Websites Feedback zum bisherigen Ansatz geben.

Was ist eine „weiche Navigation“?

Wir haben die weiche Navigation folgendermaßen definiert:

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

Bei einigen Websites können diese Heuristiken falsch-positive Ergebnisse zur Folge haben, d. h. Nutzer würden eine Navigation nicht als stattgefunden erachten, oder falsch-negative Ergebnisse, bei denen der Nutzer der Ansicht ist, dass eine Navigation stattfand, obwohl diese Kriterien nicht erfüllt wurden. Wir freuen uns über Feedback im Repository für Spezifikationen für die Soft Navigation zu den Heuristiken.

Wie implementiert Chrome die Soft Navigation?

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

• Das Ereignis soft-navigation PerformanceTiming wird ausgegeben, nachdem jede Soft Navigation erkannt wurde.
• Die Performance API bietet Zugriff auf einen soft-navigation-Timing-Eintrag, wie vom soft-navigation-PerformanceTiming-Ereignis ausgegeben.
• Die Messwerte First Paint (FP), First Contentful Paint (FCP) und Largest Contentful Paint (LCP) werden zurückgesetzt und beim nächsten entsprechenden Mal wieder ausgegeben. Hinweis: FP und FCP sind noch nicht implementiert.
• Jedem Leistungszeitraum (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. Dadurch können Cumulative Layout Shift (CLS) und Interaction to Next Paint (INP) berechnet werden.

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

Welche Auswirkungen hat die Aktivierung der sanften Navigation in Chrome?

Websiteinhaber müssen nach der Aktivierung dieser Funktion unter anderem folgende Änderungen berücksichtigen:

• Für die sanfte Navigation können zusätzliche FP-, FCP- und LCP-Ereignisse ausgegeben werden. Im Bericht zur Nutzererfahrung in Chrome werden diese zusätzlichen Werte ignoriert. Sie können sich aber auf die Überwachung der echten Nutzermesswerte auf Ihrer Website auswirken. Fragen Sie Ihren RUM-Anbieter, wenn Sie Bedenken haben, ob dies Auswirkungen auf diese Messungen hat. Weitere Informationen finden Sie im Abschnitt zum Messen von Core Web Vitals für die sanfte Navigation.
• Das neue (und optionale) Attribut navigationID in Ihren Leistungseinträgen muss möglicherweise im Anwendungscode mit diesen Einträgen berücksichtigt werden.
• Dieser neue Modus wird nur in 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 anderen Browsern verfügbar. Außerdem haben nicht alle Nutzer ein Upgrade auf die neueste Version der Chromium-basierten Browser durchgeführt. Beachten Sie daher, dass einige Nutzer möglicherweise keine Messwerte für die Softnavigation melden.
• Es handelt sich um eine neue experimentelle Funktion, die nicht standardmäßig aktiviert ist. Daher sollten Websites diese Funktion testen, um sicherzustellen, dass es keine anderen unbeabsichtigten Nebeneffekte gibt.

Weitere Informationen zum Messen der Messwerte für die „weiche Navigation“ finden Sie im Abschnitt Core Web Vitals-Daten für die Navigation zwischen zwei Seiten messen.

Wie aktiviere ich die sanfte Navigation in Chrome?

Die sanfte Navigation ist in Chrome nicht standardmäßig aktiviert. In Chrome 110 können Sie jedoch experimentieren, indem Sie diese Funktion explizit aktivieren.

Entwickler können die 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.

Für eine Website, die diese Funktion für alle Besucher aktivieren möchte, um die Auswirkungen zu sehen, gibt es einen Ursprungstest, der über Chrome 117 ausgeführt wird. Registrieren Sie sich dazu für den Test und fügen Sie ein Meta-Element mit dem Ursprungstesttoken in den HTML- oder HTTP-Header ein. Weitere Informationen finden Sie im Beitrag Erste Schritte mit Ursprungstests.

Websiteinhaber können den Ursprungstest für alle oder nur für einen Teil der Nutzer auf ihren Seiten einfügen. Informieren Sie sich im vorhergehenden Abschnitt mit den Auswirkungen darüber, wie sich dies auf die Berichterstellung für Ihre Messwerte auswirkt, insbesondere wenn Sie diesen Ursprungstest für einen großen Teil Ihrer Nutzer aktivieren. Beachten Sie, dass CrUX die Messwerte unabhängig von dieser Einstellung für die weiche Navigation weiterhin wie gewohnt meldet, und ist von diesen Auswirkungen nicht betroffen. Ursprungstests sind ebenfalls auf die Aktivierung experimenteller Funktionen bei maximal 0, 5% aller Chrome-Seitenladevorgänge im Medianwert von 14 Tagen beschränkt.Dies sollte jedoch nur bei sehr großen Websites ein Problem sein.

Wie kann ich „Soft Navigation“ messen?

Sobald der Test für die sanfte Navigation aktiviert ist, werden Berichte zu den Messwerten wie gewohnt über die PerformanceObserver API erstellt. Bei diesen Messwerten sind jedoch einige zusätzliche Punkte zu berücksichtigen.

Hinweis: FP und FCP werden derzeit nicht für die sanfte Navigation gemeldet.

Leichte Navigationen melden

Sie können einen PerformanceObserver verwenden, um sanfte Navigationen zu beobachten. Im Folgenden finden Sie ein Beispiel-Code-Snippet, mit dem Einträge der vorläufigen Navigation in der Konsole protokolliert werden – einschließlich vorheriger Navigationen auf dieser Seite mit der Option buffered:

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

Damit lassen sich Messwerte für die gesamte Seite für die vorherige Navigation fertigstellen.

Messwerte für die entsprechende URL melden

Da sanfte Navigationen erst nach ihrer Ausführung sichtbar sind, müssen einige Messwerte anhand dieses Ereignisses finalisiert und dann für die vorherige URL gemeldet werden, da die aktuelle URL nun der aktualisierten URL für die neue Seite entspricht.

Das navigationId-Attribut des entsprechenden PerformanceEntry kann verwendet werden, um das Ereignis der richtigen URL zuzuordnen. Sie können dies mit der PerformanceEntry API nachschlagen:

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;

Mit diesem pageUrl werden die Messwerte für die richtige URL erfasst und nicht für die aktuelle URL, die möglicherweise in der Vergangenheit verwendet wurde.

startTime der sanften 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 die Zeit der ersten Interaktion (z. B. Klicken auf eine Schaltfläche), durch die die sanfte Navigation ausgelöst wurde.

Alle Zeitangaben für die Leistung, auch die für die sanfte Navigation, werden ab der anfänglichen Zeit für die Seitennavigation als Zeit erfasst. Daher ist die Startzeit der sanften Navigation erforderlich, um die Lademesswerte für die Ladegeschwindigkeit (z. B. LCP) im Verhältnis zu dieser Zeit zu bestimmen.

Core Web Vitals pro sanfter Navigation messen

Wenn Sie Messwerteinträge für die Soft Navigation einschließen 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});

Zusätzlich zur Aktivierung der Funktion „Soft Navigation“ in Chrome wird das zusätzliche Flag includeSoftNavigationObservations für die Methode observe benötigt. Mit dieser ausdrücklichen Zustimmung auf Ebene des Leistungsbeobachters soll sichergestellt werden, dass bestehende Leistungsbeobachter nicht von diesen zusätzlichen Einträgen überrascht werden, da bei der Messung von Core Web Vitals für die sanfte Navigation weitere Aspekte berücksichtigt werden müssen.

Timings werden weiterhin in Bezug auf den ursprünglichen Beginn der Navigation zurückgegeben. Wenn Sie also den LCP beispielsweise für eine „weiche Navigation“ berechnen möchten, müssen Sie anhand des LCP-Timings die Startzeit der entsprechenden Navigation wie zuvor beschrieben subtrahieren. 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 bisher über die gesamte Lebensdauer der Seite hinweg gemessen. Der LCP beispielsweise kann sich ändern, bis eine Interaktion erfolgt. CLS und INP können aktualisiert werden, bis die Seite verlassen wird. Daher muss für jede „Navigation“ (einschließlich der ursprünglichen Navigation) möglicherweise die Messwerte der vorherigen Seite bei jeder neuen Softnavigation abgeschlossen werden. Das bedeutet, dass die anfänglichen Messwerte zur „harten“ Navigation möglicherweise früher als üblich fertiggestellt werden können.

Wenn Sie mit der Messung der Messwerte für die neue weiche Navigation dieser langlebigen Messwerte beginnen, müssen die Messwerte „zurückgesetzt“ oder „neu initialisiert“ und als neue Messwerte behandelt werden. Die Werte, die für vorherige „Seiten“ festgelegt wurden, müssen nicht gespeichert werden.

Wie sollten Inhalte behandelt werden, die sich zwischen den Navigationen unterscheiden?

FP, FCP und LCP bei der weichen Navigation messen nur neue Farben. Dies kann zu einem anderen LCP führen, z. B. von einem Kaltladevorgang bei dieser sanften Navigation zu einem sanften Laden.

Angenommen, eine Seite enthält ein großes Bannerbild, das das LCP-Element ist, aber der Text darunter ändert sich mit jeder weichen Navigation. Beim anfänglichen 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 angezeigt wird, und das neue LCP-Element. Wenn jedoch eine neue Seite mit einem Deeplink in der URL für die weiche Navigation geladen wird, wird das Bannerbild neu gezeichnet und kann als LCP-Element betrachtet werden.

Wie in diesem Beispiel gezeigt, kann das LCP-Element für die weiche Navigation je nach Ladeart der Seite unterschiedlich erfasst werden – so, wie wenn das Laden einer Seite mit einem Ankerlink weiter unten auf der Seite zu einem anderen LCP-Element führen kann.

Wie wird TTFB gemessen?

Time to First Byte (TTFB) für einen herkömmlichen Seitenaufbau gibt an, wie lange die ersten Bytes der ursprünglichen Anfrage zurückgegeben wurden.

Bei einer sanften Navigation ist das eine kniffligere Frage. Sollen wir die erste Anfrage messen, die für die neue Seite gestellt wurde? Was passiert, wenn alle Inhalte bereits in der App vorhanden sind und es keine weiteren Anfragen gibt? Was passiert, wenn diese Anfrage im Voraus mit einem Prefetch erfolgt? Was passiert, wenn eine Anfrage aus Nutzerperspektive, die sich nicht auf die Soft Navigation bezieht, beispielsweise eine Analyseanfrage ist?

Eine einfachere Methode ist die Meldung der TTFB von 0 für die weiche Navigation – ähnlich wie wir es für die Wiederherstellung des Back-Forward-Cache empfehlen. Dies ist die Methode, die derzeit von der web-vitals-Bibliothek für die sanfte Navigation verwendet wird.

In Zukunft werden wir möglicherweise genauere Möglichkeiten unterstützen, um zu ermitteln, welche Anfrage die „Navigationsanfrage“ der Soft Navigation ist, und so genauere TTFB-Messungen durchführen können. Das ist jedoch nicht im aktuellen Test enthalten.

Wie lassen sich alte und neue Daten messen?

Während dieses Tests wird empfohlen, die Core Web Vitals weiterhin wie gewohnt zu messen – basierend auf „schweren“ Seitennavigationen, die mit dem übereinstimmen, was von CrUX gemessen und als offizieller Datensatz der Core Web Vitals-Initiative gemeldet wird.

Zusätzlich sollte die „leichte Navigation“ gemessen werden, damit Sie nachvollziehen können, wie diese in Zukunft gemessen werden könnten. So haben Sie die Möglichkeit, dem Chrome-Team Feedback zur Funktionsweise dieser Implementierung in der Praxis zu geben. Dies wird Ihnen und dem Chrome-Team dabei helfen, die API für die Zukunft zu optimieren.

Wenn Sie beides messen möchten, müssen Sie sich der neuen Ereignisse bewusst sein, die im Modus „Soft Navigation“ ausgelöst werden können (z. B. mehrere FCP- und zusätzliche LCP-Ereignisse), und diese entsprechend verarbeiten, indem Sie diese Messwerte zum richtigen Zeitpunkt fertigstellen und zukünftige Ereignisse ignorieren, die nur für die sanfte Navigation gelten.

Core Web Vitals für die sanfte Navigation mithilfe der web-vitals-Bibliothek messen

Die einfachste Möglichkeit, alle Nuancen zu berücksichtigen, ist die Verwendung der JavaScript-Bibliothek web-vitals, die experimentelle Unterstützung für weiche Navigationen in einem separaten soft-navs branch bietet (auch verfügbar für npm und unpkg). Dies kann folgendermaßen gemessen werden (wobei doTraditionalProcessing und doSoftNavProcessing jeweils ersetzt werden):

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

Sorgen Sie dafür, dass die Messwerte wie zuvor erwähnt für die richtige URL gemeldet werden.

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

Messwert	Details
TTFB	Wird als „0“ ausgegeben.
FCP	Derzeit wird von der web-vitals-Bibliothek nur die erste FCP für die Seite gemeldet.
LCP	Die Zeit des nächstgrößten Contentful Paint, bezogen auf die Startzeit der Soft Navigation. Vorhandene Farben aus der vorherigen Navigation werden nicht berücksichtigt. Daher ist der LCP >= 0. Wie gewohnt wird dies bei einer Interaktion oder im Hintergrund der Seite gemeldet, da der LCP nur dann endgültig festgelegt werden kann.
CLS	Das größte Zeitfenster für den Wechsel zwischen den Navigationszeiten. Wie immer gilt dies, wenn die Seite im Hintergrund ausgeführt wird, da die CLS nur dann fertiggestellt werden kann. Wenn keine Verschiebungen vorhanden sind, wird ein Wert von 0 gemeldet.
INP	Die INP zwischen den Navigationszeiten. Wie gewohnt wird dies bei einer Interaktion gemeldet, oder wenn die Seite im Hintergrund ausgeführt wird, da die INP nur dann fertiggestellt werden kann. Wenn keine Interaktionen vorhanden sind, wird kein Wert von „0“ erfasst.

Warnung:Die web-vitals-Implementierung befindet sich in der Entwicklung und kann sich ändern, wenn neue Änderungen für diesen Zweig veröffentlicht werden. Derzeit wird FCP bei der sanften Navigation nicht unterstützt, da dies mehr grundlegende Arbeit in Chrome erfordert. Wenn Sie die JavaScript-Bibliothek web-vitals verwenden, sollten Sie dies beachten, wenn Sie diese Bibliothek auf Produktionswebsites verwenden möchten. Sie sollten eine lokale Kopie erstellen, diese Version testen und den Zweig auf Änderungen überwachen.

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

Genau das ist ein Experiment für die weiche Navigation. Wir möchten die Heuristik bewerten, um festzustellen, ob sie die Nutzererfahrung genauer widerspiegelt, bevor wir eine Entscheidung über die Aufnahme in die Core Web Vitals-Initiative treffen. Wir freuen uns sehr über dieses Experiment, können jedoch keine Garantien dafür geben, ob oder wann die aktuellen Messungen ersetzt werden.

Wir freuen uns über Feedback von Webentwicklern zum Experiment, zu den verwendeten Heuristiken und darüber, ob es die Erfahrung Ihrer Meinung nach besser widerspiegelt. Das GitHub-Repository für die Soft Navigation ist der beste Ort, um Feedback zu geben. Einzelne Fehler bei der Implementierung von Chrome sollten jedoch im Chrome Issue Tracker gemeldet werden.

Wie wird „Soft Navigation“ in CrUX gemeldet?

Wie genau „Soft Navigation“ in CrUX erfasst wird und ob dieser Test erfolgreich sein sollte, steht noch nicht fest. Es ist nicht unbedingt notwendig, dass sie wie aktuelle "harte" Navigationen behandelt werden.

Auf einigen Webseiten ist die sanfte Navigation fast identisch mit dem Laden ganzer Seiten, was die Nutzer betrifft, und die Verwendung der Single-Page-Application-Technologie ist nur ein Implementierungsdetail. In anderen ähneln sie eher einem Teilladevorgang von zusätzlichem Inhalt.

Daher entscheiden wir uns, diese weichen Navigationen in CrUX separat zu melden 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 unter Umständen auch vollständig ausschließen.

Derzeit konzentriert sich das Team auf die heuristische und technische Umsetzung, die es uns ermöglichen, den Erfolg dieses Tests zu beurteilen. Daher wurde keine Entscheidung zu diesen Fronten getroffen.

Feedback

Wir bitten um Feedback zu diesem Test an den folgenden Stellen:

• Heuristik und Standardisierung der weichen Navigation:
• Probleme bei der Chrome-Implementierung dieser Heuristiken.
• Allgemeines Feedback zu Web Vitals erhältst du unter [e-mail].

Änderungsprotokoll

Da sich diese API in der Testphase befindet, gibt es eine Reihe von Änderungen, mehr als bei stabilen APIs. Weitere Informationen finden Sie im Änderungsprotokoll der Heuristiken für die sanfte Navigation.

Fazit

Das Experiment der sanften Navigation ist ein spannender Ansatz für die Entwicklung der Core Web Vitals-Initiative, um ein gemeinsames Muster im modernen Web zu messen, das derzeit in unseren Messwerten fehlt. Obwohl sich dieses Experiment noch in den Anfängen befindet und es noch viel zu tun gibt, ist es ein wichtiger Schritt, die bisherigen Fortschritte der breiteren Web-Community zugänglich zu machen. Das Einholen des Feedbacks aus diesem Test ist ein weiterer wichtiger Teil des Tests. Daher empfehlen wir allen, die an dieser Entwicklung interessiert sind, diese Gelegenheit zu nutzen, die API so zu gestalten, dass sie repräsentativ für das ist, was wir mit diesen Daten messen können.

Danksagungen

Thumbnail-Bild von Jordan Madrid auf Unsplash