Fastly ist in Sachen Time to First Byte unschlagbar

Ergänzend zu Blogpost vom 2. November, der sich mit unseren Vorteilen gegenüber dem CDN von Akamai befasste, belegen neue Daten eine 29%ige Verbesserung der TTFB gegenüber dem CDN von Edgio. Schauen wir uns also genauer an, warum diese Metrik auch Rückschlüsse auf die Gesamtperformance bietet.

Wie bereits in unserem früheren Blogpost erwähnt, ist ein direkter Vergleich zwischen CDNs nicht ganz einfach. Es gilt dabei viele grundlegende Fragen zu klären, zum Beispiel, welche Metrik man verwenden sollte, welchen Datensatz man wählen sollte und welche Websites man sich ansehen sollte. Zur Veranschaulichung der Gründe, warum Ihre Website durch den Wechsel zu Fastly schneller (und sicherer!) wird, erläutern wir Ihnen unsere Methodik und Überlegungen.

Sicherstellung einer ausreichenden Datenmenge

Die TTFB ist die einzige verfügbare Metrik, die aus realen Nutzungsdaten hervorgeht und sich direkt dem CDN zuordnen lässt, das bei der Auslieferung einer großen Anzahl von Websites die kürzeste TTFB erzielt hat. Andere Metriken wie der Largest Contentful Paint (LCP) können durch Faktoren wie die clientseitige Ausführung von JavaScript, unzureichende Website-Konfigurationen und die Einbettung von Inhalten Dritter beeinträchtigt werden. Noch komplizierter wird es bei Multi-CDN-Architekturen, bei denen die Domain und das erste Byte über ein bestimmtes CDN ausgeliefert werden, während ein oder mehrere andere CDNs für weitere Aspekte der Inhaltsauslieferung zuständig sein können. Es gibt keine Methode, um Inhalte, die nach dem ersten Byte ausgeliefert werden, analog zur TTFB bestimmten CDNs zuzuordnen.

Dies liegt in der Regel nicht daran, dass die Inhalte einmal von einem CDN und das nächste Mal von einem anderen CDN ausgeliefert werden, sondern vielmehr an der Tatsache, dass große Unternehmen häufig über Multi-CDN-Konfigurationen verfügen, bei denen unterschiedliche CDNs verschiedene Arten von Inhalten ausliefern. So werden Videos beispielsweise von einem CDN bereitgestellt, Bilder von einem anderen und wiederum andere Inhalte von einem dritten CDN. Dieses Multi-CDN-Erlebnis trägt bei jedem Seitenbesuch zur LCP Performance bei und lässt sich nicht in einzelne Komponenten zerlegen.

Um aber ganz auf Nummer sicher zu gehen, sind wir noch einen Schritt weiter gegangen und haben einen Blick auf die LCP-Daten geworfen, um die positive Korrelation zwischen den TTFB-Vorteilen, die wir bei Fastly Kunden gesehen haben, mit der LCP Performance zu bestätigen – und wir hatten Glück! Mehr dazu in Kürze, aber das bedeutet, dass die Performance-Vorteile (29 % schneller als das Edgio CDN) keine Ausreißer waren oder auf Kosten anderer Performance-Merkmale gingen. Tatsächlich brachten diese Vorteile auch signifikante Vorteile bei der LCP Performance mit sich.

Die beste Methode, um dies zu untersuchen, ist unseres Erachtens die Auswertung echter weltweiter Daten von echten Nutzern mit echten Browsern. Und genau das konnten wir dank Googles Chrome User Experience Report (CrUX) und TTFB-Datensatz erreichen.

Warum wir uns auf die Time to First Byte konzentrieren

CrUX 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 diese Daten im Laufe der Zeit von echten Chrome Nutzern auf der ganzen Welt gesammelt werden, ist darauf Verlass, dass sie die realen Erlebnisse beim Besuch von Websites widerspiegeln und nicht synthetischer Natur sind. Diese Praxisdaten spiegeln besser 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 – auch an den Spitzen- und Tiefstpunkten – erhoben werden, sodass sie Aufschluss darüber geben, wie eine Website die Traffic-Last zu verschiedenen Zeiten bewältigt. Wenn Sie Ihr Experiment nicht in einem kontrollierten Rahmen, sondern in freier Wildbahn durchführen, erfahren Sie, wie echte Nutzer Ihre Website 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.

Die TTFB gehört zu den Web Vital Metriken von Google, aber nicht zu den „Core Web Vitals“ für Google selbst, obwohl sie zusammen mit den anderen CrUX Web Vitals Daten erhoben wird. Sie 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 LCP zurück. Eine solide 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 die TTFB-Performance sowie andere wichtige Metriken, die gleichzeitig erfasst werden. Der springende Punkt ist, dass man ihm dennoch viel Aufmerksamkeit schenken sollte, wenn (wie in unserem Fall) andere Metriken nicht verfügbar sind.

Hinweis zu den CrUX Daten:

Der CrUX Datensatz liefert Metriken für die TTFB und den LCP in Form von „P75“-Messungen. Die Zahl, die zurückgegeben wird, ist also der schlechteste Wert für diese Metrik für die obersten 75 % der Nutzer in den letzten 28 Tagen. 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. Zu diesen Faktoren können unter anderem Nutzererlebnisse mit sehr langsamen Verbindungen oder Geräten 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 sie auf Daten aus dem Chrome Browser (und nicht auf Firefox, Safari, Edge oder andere) beschränkt, umfasst aber alle Desktop-Betriebssysteme wie MacOS, Windows und Linux. Des Weiteren ausgeschlossen sind Traffic und Daten aus China.

Wir sind fest davon überzeugt, dass die Aussagekraft der echten Nutzungsdaten von CrUX den Kompromiss wert ist, der durch die fehlende Repräsentation von iOS und Daten aus China entsteht. Außerdem erwarten wir, dass die Performance-Unterschiede auf iOS und in anderen Browsern ähnlich, wenn nicht sogar identisch sind, da es sich bei der TTFB um das erste Bit an Daten handelt, das an den Browser übermittelt wird, und Geräte- und Browsertypen diese Ergebnisse nicht maßgeblich beeinflussen sollten.

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

Warum wir uns für die CrUX Liste entschieden haben

Wie im letzten Blogpost dokumentiert, haben wir für den Akamai TTFB-Test die Fortune 500 Liste als Datensatz verwendet. Bei unserer aktuellen Untersuchung stellte sich jedoch heraus, dass nur ein sehr geringer Prozentsatz der Fortune 500 Unternehmen Edgio für die Auslieferung des ersten Bytes verwendet. Um die Gefahr einer erheblichen Verzerrung der Daten zu vermeiden und eine genaue Übersicht über die beliebtesten Websites zu erhalten, sind wir auf die CrUX Liste umgestiegen. Zunächst haben wir 10.000 der beliebtesten Websites ins Visier genommen, unsere Untersuchungen später aber auf 50.000 ausgeweitet, um eine ausreichend große Edgio Stichprobe zu erhalten und Durchschnittswerte vergleichen zu können. Außerdem haben wir uns für Medianwerte entschieden, um Verzerrungen durch sehr langsame Websites zu vermeiden.

(Weitere Informationen über die CrUX Liste, einschließlich einer Bewertung ihrer Genauigkeit durch Dritte, finden Sie unter https://zakird.com/papers/toplists.pdf)

Wie wir bestimmt haben, welches CDN das erste Byte am schnellsten ausgeliefert hat

Mit unserem internen CDN-Erkennungstool haben wir zwischen dem 1. Dezember 2023 um 6:13 Uhr und dem 4. Dezember 2023 um 10:27 Uhr acht Überprüfungen für jeden Origin-Server durchgeführt. Für jede Erkennung wurde eine Abfrage beim öffentlichen DNS-Server von Google durchgeführt und das CDN ermittelt, indem folgende Inhalte mit einer Konfigurationsdatei verglichen wurde, die bekannte Anbieter und Werte enthielt:

CNAME-Einträge (*.fastly.net, *.systemcdn.net usw.)
Zuordnungen von IP-Adressen zu ASNs

Eine schnellere TTFB mit Fastly bedeutet auch eine schnellere LCP-Performance!

Als Bonusaufgabe haben wir beschlossen, den Zusammenhang zwischen der TTFB-Performance (Fastly vs. Edgio) und der LCP-Performance (Fastly vs. Edgio) zu untersuchen, um sicherzustellen, dass die verbesserte TTFB-Performance für Fastly Kunden auch eine Verbesserung der Performance bei anderen Metriken wie dem LCP bedeutet. Wenn Unternehmen eine Methode zur Verbesserung der TTFB anwenden würden, die auf Kosten des LCP oder der Gesamtladedauer geht, würde sich das hier zeigen. Dasselbe würde gelten, wenn sich die Performance-Vorteile von Fastly auf die TTFB beschränken würden und Fastly beim LCP schlechter abschneiden würde als die Konkurrenz. Erfreulicherweise war unser CDN beim LCP um 22 % schneller als das von Edgio.

Geschwindigkeit zählt

Es hat sich wiederholt gezeigt, dass Verzögerungen sich negativ auf die Loyalität von Onlinebesuchern und weitere Faktoren auswirken können. Vor allem besteht ein erhebliches Risiko für Warenkorbabbrüche und Abwanderung.

Die Geschwindigkeit, mit der Daten an Ihre Leser, Kunden und andere Personen übermittelt werden, kann über eine Interaktion entscheiden. Die gute Nachricht ist, dass das richtige CDN die Auslieferung Ihrer Website erheblich beschleunigen kann, wie die oben genannten Beispiele zeigen.

Geschwindigkeit ist für Fastly seit jeher das A und O, und das soll auch so bleiben. Außerdem würden wir Ihnen gerne die Wettbewerbsvorteile eines Wechsels zu einem modernen CDN erläutern.

Vollständige Ergebnisse

Jede der unten aufgeführten aggregierten Zahlen ist der Median der p75-Scores für alle Origin-Server einer Website auf jedem CDN; die Daten wurden in einem Zeitraum von 28 Tagen von berechtigten Chrome Nutzern erhoben (Fastly: 05.11.2023 - 02.12.2023, Edgio: 07.11.2023 - 04.12.2023)

CrUX Top 50.000 Origins (Domain Provider):

Fastly (1.213 Origins):

TTFB: 554 ms
LCP: 1.994 ms

Edgio (121 Origins):

TTFB: 713 ms (159 ms (29 %) langsamer als Fastly)
LCP: 2.426 ms (432 ms (22 %) langsamer als Fastly)