Erläuterung der von Fastly verwendeten Research-Methoden

Fastly KV Store Benchmark-Methode 1

Beim Fastly KV Store Benchmark-Test handelt es sich um die laufende Überprüfung und den Vergleich der Latenzzeiten beim Lesen, Schreiben und der Replikation des KV Store in Echtzeit.

Seit dem 23. Januar 2024 wenden wir dieses Verfahren an, um die Lese-, Schreib- und Replikationsdauer von Fastlys KV Store zu untersuchen und zu ermitteln, wie wir im Wettbewerbsvergleich abschneiden.

1. In einer Schleife wird kontinuierlich ein Key-Value-Paar aus dem KV Store ausgelesen, bis der Wert der festgelegten Größe zwischen einem (1) Byte und 25 MB entspricht. Um das gesamte globale Netzwerk von Fastly genau abzubilden, wird dieses Verfahren an jedem einzelnen Point of Presence (POP) von Fastly durchgeführt. 

2. Die folgenden Zeitstempel werden aufgezeichnet: vor und nach dem ersten Lesen (Miss), beim zweiten Lesen (Hit) und beim letzten Lesen (Miss), wenn der gewünschte Wert erreicht wurde.

3. Nach fünf Sekunden wird ein Key-Value-Paar mit einem zufälligen Wert in der zuvor festgelegten Größe geschrieben.

4. Nach einer Wartezeit von bis zu 60 Sekunden oder wenn alle Antworten eingegangen sind, wiederholen wir die ersten drei Schritte mit einem aktualisierten Wert, der um 1 Byte erhöht wird.

5. Die Schritte 1-4 werden an allen POPs wiederholt, wobei der in Schritt 3 verwendete POP variiert.

6. Anschließend wiederholen wir die Schritte 1-5 mit verschieden großen Werten.*

* Für unseren Test verwenden wir zufällig ausgewählte Strings mit einer Größe zwischen 1 Byte und 25 MB. 

Bericht zur User Experience in Chrome

CrUX – kurz für Chrome User Experience – ist der offizielle Datensatz von Googles Web Vitals Programm, einer „Initiative von Google zur Bereitstellung einer einheitlichen Anleitung für Qualitätssignale, die für ein großartiges Nutzererlebnis im Internet unerlässlich sind“. Kurz gesagt, betreibt Google dieses Programm, um Auskunft darüber zu geben, was das Unternehmen für wichtig hält, welche Metriken es zugrunde legt und was es unter „guter“ Performance versteht. So wissen Websitebetreiber, worauf sie achten müssen, um von Google für eine bessere Website-Performance mit einem besseren Ranking und einer besseren SEO-Performance (und damit mehr Traffic) belohnt zu werden. 

Da die Daten von tatsächlichen Chrome Nutzern auf der ganzen Welt gesammelt werden, ist darauf Verlass, dass sie die realen Erlebnisse beim Besuch von Websites widerspiegeln und nicht eher synthetischer Natur sind. Diese Praxisdaten spiegeln stärker wider, wie Dinge wie die Cache-Hitrate (CHR), die Entfernung zum Server, ein optimiertes Routing und ein effizientes Loadbalancing zur Verbesserung der Website-Performance beitragen. Grund dafür ist, dass die Daten an verschiedenen Orten und zu verschiedenen Zeitpunkten erhoben werden. Die Datenerhebung erfolgt bei Traffic-Spitzen und -Flauten und gibt Aufschluss darüber, wie eine Website die Datenlast zu verschiedenen Zeiten bewältigt. Somit spiegelt der Test wider, was passiert, wenn Sie keine Kontrolle über Ihren Traffic haben, und liefert eine genaue Vorstellung davon, wie Besucher Ihre Website in freier Wildbahn erleben. Außerdem hat CrUX den Vorteil, dass es über eine nutzerfreundliche API verfügt, mit der wir die relevanten Daten über einen bestimmten Zeitraum hinweg immer wieder abfragen können, und dass es sich dabei um eine vertrauenswürdige Quelle handelt, die auf umfangreichen Daten basiert.

Deshalb sind TTFB, LCP und INP wichtig:

Obwohl sie zusammen mit den anderen CrUX Web Vitals Daten erhoben wird und den Web Vital Metriken von Google zugerechnet werden kann, gehört die Time to First Byte (TTFB) nicht zu den „Core Web Vitals“ für Google selbst. Es wirkt sich also nicht auf Ihr Google Ranking aus, wenn Ihre TTFB-Performance außerhalb des empfohlenen Fensters liegt. Aus den oben genannten Gründen greift Google dafür auf Metriken wie den Largest Contentful Paint (LCP) zurück. Eine niedrige TTFB ist aber dennoch entscheidend für die Website-Performance, da die TTFB kürzer ist als der LCP und diesen somit beeinflusst. Durch die Messung des LCP berücksichtigt Google automatisch die TTFB-Performance sowie andere wichtige Metriken. Der springende Punkt ist, dass man ihr dennoch viel Aufmerksamkeit schenken sollte, wenn (wie in unserem Fall) andere Metriken nicht verfügbar sind. 

Interaction to Next Paint (INP) ist ein seit 12. März 2024 greifendes Core Web Vital, das den First Input Delay (FID) als Maß für die Interaktivität ablöst. INP verbessert den FID, da sie die Paint-Verzögerung aller Klick-, Tap- und Tastendruck-Interaktionen berücksichtigt anstatt nur der ersten.

„P75“ und Hinweise zu den CrUX Daten:

Der CrUX Datensatz liefert Metriken für Web Vitals wie die TTFB und den LCP in Form von „P75“-Messungen. Die Zahl, die zurückgegeben wird, ist also der niedrigste Wert für diese Metrik unter den obersten 75 % der Nutzer in einem bestimmten Zeitabschnitt. Extrem niedrige Werte werden entfernt, um ein genaueres Bild der Website-Performance zu erhalten. Bei den Web Vitals Metriken werden die untersten 25 % außer Acht gelassen, um Platz für Faktoren zu schaffen, die außerhalb der Kontrolle der Website liegen. Dazu können unter anderem Nutzererlebnisse mit sehr langsamen Verbindungen oder Geräten, Alltagsprobleme des Internets (bei denen Fastly Ihnen behilflich sein kann) oder andere vorübergehende Probleme gehören, die die Ladezeit auf eine Weise beeinflussen, die sich nicht negativ auf die Bewertung der Performance auswirken sollte. Indem das unterste Quartil weggelassen wird, ist für Google sichergestellt, dass die Messung die tatsächliche Performance der Website besser widerspiegelt und nicht durch Ausnahmen verzerrt wird. 

Die Datenerfassung erfolgt ausschließlich in Google Chrome und nicht über iOS. Dies deckt zwar nach wie vor eine Vielzahl von Erlebnissen ab, bedeutet aber auch, dass die Daten aufgrund der Beschränkungen für die Datenerfassung in iOS Apps auf Chrome Nutzer beschränkt sind, die Android Geräte verwenden. Auf Desktop-Geräten ist Chrome auf den Betriebssystemen MacOS, Windows und Linux für die Erfassung von CrUX Daten geeignet. Da Chrome in China nicht verfügbar ist, sind die Erlebnisse der dortigen Nutzer nicht ausreichend repräsentiert. 

Wir sind aber der festen Überzeugung, dass die Aussagekraft der Praxisdaten von CrUX diese Einschränkungen wettmacht. Außerdem ist davon auszugehen, dass die Performance-Unterschiede zwischen iOS und anderen Browsern ähnlich, wenn nicht sogar gleich sind.

Weitere Informationen zu Googles Vorgehensweise bei der Aufnahme von Nutzern in die CrUX Daten finden Sie hier: https://developer.chrome.com/docs/crux/methodology?hl=de#user-eligibility 

CrXU Datenquellen:

Der CrUX Datensatz ist über BigQuery und verschiedene APIs verfügbar, wobei gewisse Unterschiede darin bestehen, welche Metriken enthalten sind und wie sie aggregiert werden. Die APIs liefern eine „P75“-Messung mit Millisekundengenauigkeit sowie ein Histogramm der schnellen, durchschnittlichen und langsamen Werte für die sechs Web Vitals, die über den jüngsten Erfassungszeitraum von 28 Tagen aggregiert wurden. BigQuery bietet hingegen eine Messgenauigkeit von 100 Millisekunden für die „P75“-Messung sowie ein Histogramm für Web Vitals und zusätzliche Performance-Metriken. Darüber hinaus sind Statistiken, die Auskunft über den Anteil der Nutzererlebnisse mit jedem Formfaktor und jeder Verbindungsgeschwindigkeit geben, und ein nach Monat aggregiertes simples Beliebtheitsranking verfügbar.

CDN-Erkennungsmethode 1

Wir nutzen unser internes CDN-Erkennungstool, um über einen bestimmten Zeitraum mehrere Überprüfungen für jeden Origin-Server durchzuführen. Für jede Erkennung wurde eine Abfrage beim öffentlichen DNS-Server von Google gemacht und das CDN ermittelt, indem folgende Inhalte mit einer Konfigurationsdatei verglichen wurde, die bekannte Anbieter und Werte enthielt: 

• CNAME-Einträge (*.fastly.net, *.akamai.net usw.)

• Zuordnungen von IP-Adressen zu ASNs