Glossaire de la méthodologie de recherche Fastly
Méthode 1 de benchmark du KV Store Fastly
Le test de performance du Fastly KV Store est un examen continu et une comparaison de la latence en temps réel de Fastly en ce qui concerne les temps de lecture, d'écriture et de réplication du KV Store
À compter du 23-01-2024, il s’agit du processus d’examen des temps de lecture, d’écriture et de réplication du KV Store de Fastly et de la façon dont nous nous mesurons à notre concurrence.
Une boucle est initiée pour lire continuellement une paire clé-valeur depuis le KV Store jusqu'à ce que la valeur lue corresponde à la taille spécifiée, allant d'un (1) octet à 25 Mo. Cette opération est effectuée à chaque point de présence Fastly (POP) afin de refléter fidèlement le réseau mondial de Fastly.
Les horodatages suivants sont enregistrés : avant et après la première lecture (échec), la deuxième lecture (succès), et la dernière lecture (échec) lorsque la valeur est trouvée.
Après cinq secondes, une paire clé-valeur avec une valeur aléatoire de la taille spécifiée précédemment est écrite.
Après un délai d'attente pouvant aller jusqu'à 60 secondes ou lorsque toutes les réponses sont reçues, nous répétons les étapes 1 à 3 avec une valeur mise à jour, augmentée de +1 octet.
Les étapes 1 à 4 sont répétées dans tous les POP, en modifiant le POP utilisé à l’étape 3.
Répétez les étapes 1 à 5 avec des tailles de valeurs différentes*.
*Pour notre test, nous utilisons des chaînes aléatoires de tailles prédéterminées allant de 1 octet à 25 Mo.
Rapport sur l’expérience utilisateur de Chrome
CrUX, abréviation de Chrome User Experience, est l’ensemble de données officiel du programme Web Vitals de Google, une “initiative de Google visant à fournir des directives unifiées concernant les signaux de qualité essentiels pour offrir une excellente expérience utilisateur sur le web”. En résumé, Google utilise ce programme pour partager ce qu’il considère comme important, comment les données sont mesurées et ce qu’est une “bonne” performance. L’objectif est d’aider les gestionnaires de sites à comprendre ce qu’ils doivent atteindre pour obtenir de Google une meilleure valorisation de leurs performances. Ce gain se traduit par de meilleurs scores de classement sur Google et de meilleures performances SEO (ce qui devrait générer plus de trafic).
Comme les données sont collectées auprès de véritables utilisateurs de Chrome à travers le monde, elles peuvent être considérées comme fiables pour refléter des expériences réelles lors de la visite de sites web, plutôt que des données plus synthétiques. Ces données réelles reflètent clairement la façon dont des éléments tels que le taux de connexion au cache (CHR), la proximité des serveurs, l'optimisation du routage et un équilibrage de charge (load balancing) efficace améliorent les performances du site web, car les données sont collectées dans différentes zones géographiques et à différents moments. Elles sont collectées lors des pics et des creux de trafic, et rendent compte des performances d’un site en matière de gestion de la charge à différents moments. Elles reflètent donc ce qui se passe lorsque vous ne configurez pas l’expérience vous-même, lorsque vous n’avez pas le contrôle, et offrent une représentation fidèle de la façon dont les visiteurs vivent votre site dans des conditions réelles. CrUX offre également l’avantage d’une interface de programmation d’applications (API) facile à utiliser, qui permet d’interroger les données pertinentes à plusieurs reprises sur une période donnée. CrUX est considérée comme une source fiable compte tenu du volume important de données.
Importance du Temps de chargement du premier octet (TTFB), du LCP et de l’INP
Bien qu’elles soient collectées avec les autres données CrUX Web Vitals et qu’elles constituent l’une des métriques Web Vitals de Google, le Temps de chargement du premier octet n’est pas une métrique “Core Web Vital” pour Google. 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. Pour cela, et pour les raisons mentionnées dans la section ci-dessus, Google s’appuie notamment sur le Largest Contentful Paint (LCP). Un faible Temps de chargement du premier octet (TTFB) reste essentiel pour les performances du site, car le TTFB précède le LCP et l’influence directement. En mesurant le LCP, Google prend automatiquement en compte la performance du TTFB ainsi que d’autres indicateurs importants. Il reste néanmoins essentiel de l’examiner lorsque d’autres indicateurs ne sont pas disponibles (comme c’est le cas ici).
Interaction to Next Paint est un nouveau Core Web Vital depuis le 12 mars 2024, remplaçant First Input Delay comme mesure d'interactivité. INP améliore FID en tenant compte du délai d’affichage de toutes les interactions de clic, touches et pression de touches, plutôt que seulement de la première.
“P75” et mises en garde concernant les données CrUX :
Le jeu de données CrUX fournit des indicateurs pour les Web Vitals tels que le TTFB et le LCP, présentés sous forme de mesures “P75”. Cela signifie que la valeur renvoyée est le score le plus bas pour cet indicateur parmi les 75 % d’utilisateurs les plus performants sur une période donnée. Cela permet d'éliminer les scores extrêmement bas et d'obtenir une image plus précise de la performance du site. Les indicateurs Web Vitals éliminent les 25% les plus faibles afin de prendre en compte des éléments sur lesquels le site n’a aucun contrôle. Cela peut inclure des expériences des utilisateurs avec des connexions ou des appareils très lents, les conditions du réseau internet (sur lesquelles Fastly peut agir), ou d’autres problèmes transitoires qui affectent le temps de chargement et qui ne devraient pas pénaliser un 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 couvre une grande diversité d’expériences, les restrictions d’iOS sur la collecte de données dans les applications limitent les données mobiles aux utilisateurs Android de Chrome. Sur les ordinateurs de bureau, Chrome sur les systèmes d’exploitation macOS, Windows et Linux est éligible à la collecte des données CrUX. Chrome n’est pas disponible en Chine et l’expérience des utilisateurs de cette région est sous-représentée.
Nous sommes convaincus que la valeur des données CrUX issues de conditions réelles justifie ces limites. En outre, nous nous attendons à ce que les différences de performance soient similaires sur iOS et dans d’autres navigateurs, voire identiques.
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
Sources de données CrUX :
Le jeu de données CrUX est disponible sur BigQuery et via diverses API, avec quelques différences en ce qui concerne les indicateurs inclus et leur mode d’agrégation. Les API fournissent une mesure “P75” avec une granularité en millisecondes et un histogramme des valeurs rapides, moyennes et lentes pour les 6 indicateurs Web Vitals, agrégés sur la période de collecte des 28 derniers jours. BigQuery fournit une granularité de 100 millisecondes pour la mesure “P75” et pour l’histogramme des indicateurs Web Vitals et d’autres indicateurs de performance. Il fournit également des statistiques indiquant la part des expériences des utilisateurs selon le format d’appareil et la vitesse de connexion, ainsi qu’un classement de popularité approximatif, agrégé par mois.
Méthode 1 de détection de CDN
Nous utilisons notre outil interne de détection de CDN pour effectuer plusieurs détections sur chaque origine, sur une période donnée. Pour chaque détection, nous effectuons une requête au serveur DNS public de Google et détectons le CDN en comparant le contenu suivant à un fichier de configuration recensant les fournisseurs et valeurs connus:
Enregistrements CNAME (*.fastly.net, *.akamai.net, etc.)
Correspondances IP-ASN
Méthode 2 de détection de CDN
HTTP Archive est un jeu de données public qui effectue chaque mois une exploration via WebPageTest de la page d’accueil de chaque serveur d’origine figurant dans la publication mensuelle correspondante du Chrome User Experience Report. Les fournisseurs de CDN sont détectés à l’exécution par WebPageTest pour chaque requête effectuée durant le chargement de la page.
Méthode de détection de CDN 3
HTTP Archive est un jeu de données public qui effectue chaque mois une exploration via WebPageTest d’une ou deux pages de chaque serveur d’origine figurant dans la version mensuelle correspondante du Chrome User Experience Report. WebPageTest enregistre l'adresse IP utilisée pour chaque nom d'hôte demandé lors du chargement de la page, laquelle est associée à son ASN pour déterminer le CDN utilisé.