Fastly est plus rapide au niveau du temps au premier octet. Cela fait toute la différence.

Fastly est 43 % plus rapide au niveau du temps du premier octet que le CDN d’Akamai, et 32 % plus rapide que les autres CDN, et voici pourquoi c’est représentatif de la performance globale.

Il est difficile de mesurer les CDN les uns par rapport aux autres. Les questions sont nombreuses : quelle métrique utiliser, quel ensemble de données utiliser, quels sites observer, etc. Mais chez Fastly, nous sommes toujours prêts à relever un défi, et c’est ce que nous avons fait. Les chiffres parlent d’eux-mêmes, mais dans le reste de cet article, nous allons détailler notre méthodologie et notre raisonnement afin que vous constatiez par vous-même que vous serez plus rapide (et mieux protégé !) si votre trafic passe par Fastly.

Pourquoi avons-nous choisi le temps jusqu’au premier octet (Time to First Byte, TTBF)

Le TTFB est la seule métrique disponible dans les données d’utilisation réelles qui peut être directement attribuée au CDN qui l’a fourni sur un grand nombre de sites. D’autres métriques telles que le temps de chargement du contenu d’une page (Largest Contentful Paint, LCP) peuvent être influencées par des éléments tels que l’exécution de JavaScript côté client, de mauvaises configurations de sites web et l’intégration de contenu tiers. Enfin, vous devez commencer à penser aux situations multi-CDN où le domaine et le premier octet peuvent être diffusés par un même CDN, mais où un ou plusieurs autres CDN peuvent être utilisés pour d’autres aspects de la diffusion du contenu. Il n’existe pas de méthode analogue pour attribuer le contenu livré selon le TTFB à des CDN spécifiques de la même manière que nous pouvons le faire pour le premier octet. 

En général, les CDN ne livrent pas le contenu chacun leur tour. Les grandes entreprises (comme celles du Fortune 500 par exemple) ont souvent des configurations multi-CDN où différents types de contenu sont distribués par différents CDN. La vidéo peut provenir d’un CDN, les images d’un autre, et un autre type de contenu d’un troisième. Chaque fois que vous visitez ce site, vous bénéficiez de cette expérience multi-CDN qui contribue à la performance LCP. Il est tout simplement impossible d’en faire abstraction. 

Mais pour être sûrs, nous avons franchi une étape supplémentaire et examiné les données pour confirmer que les avantages que nous avons constatés dans le TTFB pour les clients de Fastly étaient positivement liés à leur performance LCP relative. Et c’était le cas ! Vous trouverez plus d’informations à ce sujet ci-dessous, mais cela signifie que les avantages en termes de performances (32 % supérieures autres CDN et 43 % supérieures au CDN d’Akamai) n’étaient pas aberrants ou aux dépens d’autres caractéristiques de performance. Ces gains étaient également accompagnés d’avantages significatifs en termes de performance LCP. 

Nous pensons que la meilleure façon d’examiner cette question est d’étudier les données collectées auprès d’utilisateurs réels, utilisant des navigateurs réels, partout dans le monde. L’étude du TTFB nous a permis de le faire grâce au rapport sur l’expérience utilisateur Chrome (CrUX) et à l’ensemble de données (dataset) de Google.

Pourquoi avons-nous choisi le dataset CrUX ?

CrUX est le dataset officiel du programme Web Vitals de Google, une « initiative de Google visant à fournir des conseils unifiés pour assurer la qualité des signaux, ce qui est essentiel pour offrir une bonne expérience utilisateur sur le web ». En bref, la société Google gère ce programme pour partager ce qu’elle pense être important, comment elle le mesure, et ce qu’elle juge être une « bonne » performance. Et ce, afin que les gestionnaires de sites sachent ce qu’ils doivent essayer d’atteindre pour que Google reconnaisse l’amélioration de leur performance, ce qui se traduit par de meilleurs scores de classement Google, et une meilleure performance SEO (et donc plus de trafic). 

Comme ces données sont recueillies auprès de véritables utilisateurs de Chrome à travers le monde, elles reflètent des expériences réelles lors de la visite de sites web plutôt que quelque chose de plus synthétique. Elles sont collectées à partir de données d’utilisateurs réels au fil du temps. Ces données réelles reflètent mieux la manière dont des éléments tels que le taux d’accès au cache (CHR), la proximité des serveurs, l’optimisation du routage et l’efficacité de l’équilibrage de charge (load balancing) améliorent la performance des sites web, car elles sont collectées dans différentes zones géographiques et à différents moments (pendant les pics et les creux de trafic) et rendent compte de la performance des sites en matière de gestion de la charge à différents moments. Elles reflètent ce qui se passe lorsque vous ne mettez pas en place l’expérience vous-même (lorsque vous n’avez pas le contrôle) et montrent comment les utilisateurs perçoivent votre site dans le monde réel. CrUX présente également l’avantage de disposer d’une API facile à utiliser qui nous permet d’interroger les données pertinentes de manière répétée sur une période spécifique. C’est en outre une source fiable qui repose sur un énorme volume de données. 

Le TTFB est l’une des métriques Web Vitals de Google, mais pas une métrique « Core Web Vitals » pour Google, même si elle est collectée avec d’autres données CrUX Web Vitals. Cela signifie que cette métrique n’entre pas en compte pour le score de votre site auprès de Google si votre performance TTFB n’est pas comprise dans la plage recommandée. Aussi, Google examine des éléments tels que le LCP pour les raisons susmentionnées, mais un TTFB solide est toujours essentiel pour la performance du site. Le TTFB précède le LCP et affecte donc le LCP. En mesurant le LCP, Google prend en compte la performance du TTFB en même temps que d’autres métriques importantes. Le fait est qu’il est toujours intéressant d’y prêter attention lorsque d’autres métriques ne sont pas disponibles (comme c’est le cas ici). 

Mises en garde concernant les données CrUX :

L’ensemble de données CrUX fournit des temps pour des éléments tels que le TTFB et le LCP en tant que mesures « P75 ». Cela signifie que le nombre renvoyé est la pire valeur de cette métrique pour les 75 % d’utilisateurs les plus performants au cours des 28 derniers jours. Cela permet d’éliminer les scores extrêmement bas et d’obtenir une image plus précise de la performance du site. Les métriques de Web Vitals éliminent les 25 % les plus bas afin de prendre en compte des éléments sur lesquels le site n’a aucun contrôle. Il peut s’agir d’expériences d’utilisateurs ayant des connexions ou des appareils très lents, ou d’autres problèmes transitoires qui ont un impact sur le temps de chargement et qui ne devraient pas influer négativement sur le score de performance. En abandonnant le quartile le plus bas, Google s’assure que cette mesure est une meilleure représentation de la performance réelle du site, et qu’elle n’est pas faussée par des anomalies. 

Ces données ne sont collectées que dans le navigateur Chrome, et non dans iOS. Bien que cela englobe une grande diversité d’expériences, en raison des restrictions d’iOS sur la collecte de données dans les applications, ces données sont limitées aux utilisateurs de Chrome sur les appareils Android pour les données mobiles. Sur les ordinateurs de bureau, les données sont limitées au navigateur Chrome (Firefox, Safari, Edge ou autres étant exclus), mais elles incluent toutes les plateformes de bureau comme MacOS, Windows et Linux. Le trafic et les données provenant de Chine sont également exclus. 

Nous sommes convaincus que la valeur des données d’utilisation réelle de CrUX vaut la peine de perdre la représentation, par exemple, des données d’iOS et de la Chine. En outre, nous nous attendons à ce que les différences de performance soient similaires sur iOS et dans d’autres navigateurs, voire identiques, car le TTFB concerne le premier bit de données vers le navigateur. Les types d’appareils et de navigateurs ne devraient donc pas avoir d’impact significatif sur ces résultats.

Pour plus d’informations, voici la méthodologie de Google pour déterminer quels utilisateurs sont inclus dans les données CrUX : https://developer.chrome.com/docs/crux/methodology/#user-eligibility. 

Pourquoi avons-nous choisi le Fortune 500 ?

Nous savons qu’il est essentiel de représenter les entreprises dans de nombreux secteurs verticaux et industriels. Nous voulions également inclure une représentation des grandes entreprises, des expériences web complexes et une variété de cas d’utilisation pour lesquels une entreprise a besoin de sa présence numérique. Nous avons choisi comme point de départ le Fortune 500, qui représente les 500 plus grandes entreprises américaines en termes de chiffre d’affaires, tous secteurs verticaux et industriels confondus, et qui ont des besoins et des objectifs différents pour leurs sites web. Il s’agit en général de grandes entreprises complexes, dotées d’une présence numérique importante et sophistiquée, pour lesquelles le rôle d’un CDN peut être plus important au quotidien que celui d’un site web personnel ou même d’une entreprise régionale. Pour dresser notre liste de domaines Fortune 500, nous avons extrait une liste à partir de ce site le 17 octobre. Comme la liste originale de Fortune se trouve derrière un paywall et que nous voulions que tout le monde puisse voir ce que nous avons utilisé, nous avons décidé de republier cette liste.

Comment avons-nous déterminé le CDN qui a livré le premier octet ?

Après avoir choisi le Fortune 500 comme point de départ, nous avons utilisé notre outil interne de détection des CDN pour lancer vingt détections sur chaque origine, du 17 octobre 2023 à 23 h 19 au 18 octobre 2023 à 16 h 07. Pour chaque détection, nous avons interrogé le serveur DNS public de Google, effectué une requête HTTP sur l’origine et détecté le CDN en vérifiant le contenu suivant par rapport à un fichier de configuration de fournisseurs et de valeurs connus : 

• En-têtes de réponse HTTP (serveur, X-cache, etc.)

• Enregistrements CNAME (*.fastly.net, *.edgekey.net, etc.)

• Correspondances IP-ASN

Le nom d’hôte d’origine présentait deux origines de site web avec plusieurs CDN. Dans ce cas, même le premier octet peut être livré par différents CDN pour différentes requêtes ; ils ont donc été exclus de l’analyse. Nous avons trouvé 35 origines de site web qui ont dépassé le délai d’attente de 60 secondes en attendant les en-têtes ; elles ont également été exclues. (34 d’entre elles semblaient être desservies par Akamai et l’une d’entre elles n’avait pas de CDN. En les incluant dans l’analyse, l’avantage de Fastly en termes de performance serait passé à 46 % par rapport au CDN d’Akamai et à 34 % par rapport aux autres CDN). 

Un TTFB plus rapide avec Fastly signifie également une performance LCP plus élevée avec Fastly !

En guise de bonus, nous avons décidé d’examiner la relation entre la performance TTFB (Fastly par rapport à Akamai et autres) et la performance LCP (Fastly par rapport à Akamai et autres) pour nous assurer que l’amélioration de la performance TTFB des clients Fastly était révélatrice de l’amélioration de la performance dans d’autres métriques telles que le LCP. Si les entreprises utilisaient une méthode pour améliorer le TTFB au détriment du LCP ou des temps de chargement complets, nous le verrions ici. De même si la supériorité de Fastly en matière de performance se limitait au TTFB avec une performance LCP inférieure à celle de la concurrence. Or, pour le LCP également, Fastly a également gagné par deux chiffres contre Akamai. Akamai était 21 % plus lent que Fastly pour le LCP, et tous les CDN combinés étaient 7 % plus lents que Fastly.

La liste Fortune 500 était trop petite et comportait trop de déploiements multi-CDN pour permettre une vérification efficace des LCP, car on ne peut pas attribuer le score LCP à un seul CDN lorsque plusieurs CDN ont contribué à l’obtenir. On ne peut comparer que des sites avec des « déploiements de site complets » où un seul CDN fournit le domaine et l’ensemble du contenu. Très peu d’entreprises du classement Fortune 500 disposent d’un site complet, c’est pourquoi nous avons décidé d’effectuer des tests sur un dataset plus large. Nous avons examiné la liste des 10 000 premiers sites du CrUX et avons appliqué la même méthode de détection des CDN, en exécutant 20 requêtes de détection de CDN au cours d’une période de 24 heures. Si tous les fournisseurs de domaines et d’actifs proviennent d’un seul CDN, le site est considéré comme utilisant ce CDN pour la diffusion du site complet. Même avec un dataset plus important, nous n’avons pu identifier avec certitude la diffusion de site complet que pour 176 domaines desservis par Fastly, et un peu plus de trois fois plus pour Akamai.

Avec cette liste en main, nous avons ensuite interrogé l’API CrUX pour connaître la performance LCP de ces domaines de diffusion de site complet, et nous avons examiné comment l’avantage de performance TTFB avec Fastly (qui était également représenté dans ces données), était lié au différentiel de performance LCP avec Fastly. Les données ont montré un avantage significatif pour Fastly en termes de performance LCP avec diffusion de site complet : 21 % par rapport au CDN d’Akamai et 7 % par rapport aux autres CDN.

Résultats complets

Chacun des chiffres agrégés ci-dessous est la moyenne des scores p75 pour toutes les origines de site web sous chaque CDN.

Origines de sites web de Fortune 500 (domainProvider) :

Fastly - 25 origines :

• TTFB : 843 ms

Akamai - 116 origines :

• TTFB : 1 208,4 ms (365,4 ms [43 %] plus lent que Fastly)

Tous les CDN sauf Fastly - 354 origines :

• TTFB : 1 111,3 ms (268,3 ms [32 %] plus lent que Fastly)

CrUX - 10 000 principales origines (diffusion de site complet) :

Fastly - 176 origines :

• LCP : 2 274,3 ms

Akamai - 555 origines :

• LCP : 2 757,8 ms (483,5 ms [21 %] plus lent que Fastly)

Tous les CDN sauf Fastly - 5 741 origines :

• LCP : 2 444,7 ms (170,4 ms [7 %] plus lent que Fastly)