Fastly beschleunigt Ihre Time to First Byte. Und zwar deutlich.

CDNs miteinander zu vergleichen ist nicht leicht und wirft viele wichtige Fragen auf, zum Beispiel, welche Metriken und welcher Datensatz verwendet werden sollte und auf welche Websites man sich konzentrieren sollte. Aber weil wir von Fastly immer für eine Herausforderung zu haben sind, haben wir uns dazu entschlossen, dennoch einen CDN-Vergleich anzustellen. Die Zahlen sprechen für sich selbst, aber im weiteren Verlauf dieses Blogposts erläutern wir Ihnen unsere Methodik und Argumente, damit auch Sie sich davon überzeugen können, dass Ihr Traffic bei Fastly schneller (und sicherer!) ist.

Warum wir uns auf die Time to First Byte konzentrieren

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 (wie die Fortune 500 Unternehmen) häufig über Multi-CDN-Konfigurationen verfügen, bei denen verschiedene Arten von Inhalten von unterschiedlichen CDNs ausgeliefert werden. 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 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 (32 % schneller als andere CDNs und 43 % schneller als das Akamai 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 für CrUX als Datensatz entschieden haben

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. Die TTFB lässt sich noch vor dem LCP erfassen und beeinflusst diesen. 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 Zeitangaben 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 auf Fortune 500 Unternehmen konzentrieren

Wir wissen, wie wichtig es ist, Unternehmen aus vielen verschiedenen Bereichen und Branchen mit einzubeziehen. Außerdem wollten wir, dass auch große Unternehmen, komplizierte Weberlebnisse und eine Vielzahl von Anwendungsfällen, die Unternehmen mit ihrer digitalen Präsenz abdecken möchten, vertreten sind. Als Ausgangspunkt dienten uns die Fortune 500, die 500 umsatzstärksten Unternehmen der USA aus allen Wirtschaftszweigen und Sektoren, die allesamt unterschiedliche Anforderungen und Ziele für ihre Websites haben. Dabei handelt es sich in der Regel um große und komplexe Unternehmen mit großen und komplexen digitalen Präsenzen, bei denen ein CDN im Tagesgeschäft oft eine wichtigere Rolle spielt als bei einer privaten Website oder einem regionalen Unternehmen. Um eine Übersicht über die Fortune 500 Domains zu erhalten, haben wir am 17. Oktober 2023 eine Liste von dieser Website heruntergeladen. Die Originalliste von Fortune befindet sich hinter einer Paywall. Wir wollten aber, dass jeder sehen kann, welche Daten wir verwendet haben. Daher haben wir uns für diese Neuveröffentlichung der Liste entschieden.

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

Nachdem wir uns für die Fortune 500 als Ausgangspunkt entschieden hatten, verwendeten wir unser internes CDN-Erkennungstool, um für jeden Origin-Server zwischen dem 17. Oktober 2023 um 23:19 Uhr und dem 18. Oktober 2023 um 16:07 Uhr zwanzig Erkennungen durchzuführen. Für jede Erkennung wurde eine Abfrage beim öffentlichen DNS-Server von Google durchgeführt, eine HTTP-Anfrage an den Origin-Server gestellt und das CDN ermittelt, indem folgende Inhalte mit einer Konfigurationsdatei verglichen wurde, die bekannte Anbieter und Werte enthielt: 

• HTTP-Antwort-Header (Server, X-Cache usw.)

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

• Zuordnungen von IP-Adressen zu ASNs

Wir sind auf zwei Origin-Server mit mehreren CDNs für den Origin-Hostnamen gestoßen. Bei dieser Konstellation kann sogar das erste Byte bei verschiedenen Anfragen von verschiedenen CDNs ausgeliefert werden, weshalb diese Origins von der Analyse ausgeschlossen wurden. Außerdem haben wir 35 Websites gefunden und ausgeschlossen, die beim Warten auf Header den Timeout von 60 Sekunden überschritten. (Hinweis: 34 dieser Websites wurden offenbar über Akamai ausgeliefert und eine Website besaß gar kein CDN. Wenn wir diese in die Analyse einbezogen hätten, wäre der Performance-Vorteil von Fastly auf 46 % gegenüber dem Akamai CDN und 34 % gegenüber anderen CDNs gestiegen). 

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

Als Bonusaufgabe haben wir beschlossen, den Zusammenhang zwischen der TTFB-Performance (Fastly vs. Akamai und andere) und der LCP-Performance (Fastly vs. Akamai und andere) 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. Doch auch beim LCP waren wir Akamai im zweistelligen Prozentbereich überlegen. Hier war Akamai 21 % langsamer als Fastly, und alle CDNs zusammen waren 7 % langsamer als Fastly.

Die Fortune 500 Liste war zu kurz und enthielt zu viele Multi-CDN-Implementierungen, um den LCP effektiv zu überprüfen. Der LCP Wert lässt sich nämlich nicht einem einzelnen CDN zuordnen, wenn mehrere CDNs daran beteiligt waren. Man kann nur Websites mit „Full Site Deployments“ vergleichen, bei denen ein einziges CDN die Domain und den gesamten Inhalt ausliefert. Nur sehr wenige Fortune 500 Unternehmen nutzten Full Site Delivery. Deshalb beschlossen wir, den Test mit einem größeren Datensatz durchzuführen. Wir haben uns die Liste mit den 10.000 besten Websites von CrUX angesehen und dieselbe CDN-Erkennungsmethode angewendet, haben also 20 CDN-Erkennungsanfragen über einen Zeitraum von 24 Stunden durchgeführt. Wenn alle Domain- und Asset-Anfragen für eine Website von einem einzigen CDN beantwortet wurden, wurde dieses CDN mit dem Label „Full Site Delivery“ gekennzeichnet. Selbst mit dem größeren Datensatz konnten wir nur bei 176 Domains, die von Fastly ausgeliefert wurden, mit Sicherheit eine Full Site Delivery feststellen. Bei Akamai waren es knapp dreimal so viele.

Anhand dieser Liste haben wir dann Queries nach der LCP Performance dieser Full Site Delivery Domains an die CrUX API gesendet und untersucht, wie der (ebenfalls aus diesen Daten ersichtliche) Performance-Vorteil bei der TTFB mit Fastly mit dem Performance-Unterschied beim LCP mit Fastly zusammenhing. Aus den Daten ergab sich ein signifikanter Performance-Vorteil beim LCP mit Fastlys Full Site Delivery von 21 % im Vergleich zum Akamai CDN und ein 7-prozentiger Vorteil für Fastly im Vergleich zu anderen CDNs.

Vollständige Ergebnisse

Jeder der unten aufgeführten zusammengefassten Werte ist der mittlere P75-Score für alle Websites, die über das jeweilige CDN ausgeliefert wurden.

Origin-Server von Fortune 500 Websites (domainProvider):

Fastly (25 Origins):

• TTFB: 843,0 ms

Akamai (116 Origins):

• TTFB: 1.208,4 ms (365,4 ms (43 %) langsamer als Fastly)

Alle CDNs außer Fastly (354 Origins):

• TTFB: 1111,3 ms (268,3 ms (32 %) langsamer als Fastly)

CrUX Top 10.000 Origins (Full Site Delivery):

Fastly (176 Origins):

• LCP: 2.274,3 ms

Akamai (555 Origins):

• LCP: 2.757,8 ms (483,5 ms (21 %) langsamer als Fastly)

Alle CDNs außer Fastly (5.741 Origins):

• LCP: 2.444,7 ms (170,4 ms (7 %) langsamer als Fastly)