Nous avons analysé 5,2 millions de pages sur ordinateur de bureau et mobile

Et voici ce que cela nous a appris sur la vitesse de chargement…

We Analyzed 5.2 Million Desktop and Mobile Pages. Here’s What We Learned About Page Speed

Librement traduit de l’article original de backlinkeo, https://backlinko.com/page-speed-stats

Nous avons analysé 5 millions de pages bureau et mobile pour découvrir quels facteurs impactaient la vitesse de chargement.

Pour commencer, nous avons établi un benchmark international pour les métriques de temps de chargement du TTFB, Visual Complete et Fully Loaded.

Ensuite, nous avons analysé l’impact de la compression des images, les CDN et l’hébergement sur la vitesse de chargement du site.

Nos données nous ont d’ailleurs permi de faire des découvertes très intéressantes (et surprenantes)…

Voici un résumé de ces découvertes :

1. Dans notre analyse de 5,2 millions de pages, la vitesse moyenne du TTFB (Time To First Byte) sur le bureau est de 2,594 secondes, et de 1,286 seconde sur mobile. Le temps moyen nécessaire au chargement complet d’une page Web est de 10,3 secondes sur le bureau et de 27,3 secondes sur mobile.

2. En moyenne, une page web met 87,84 % plus de temps à charger sur mobile que sur le bureau.

3. Squarespace et Weebly offrent les meilleures performances globales en matière de vitesse de chargement des pages mobiles. Wix et WordPress se retrouvent par contre en bas de notre classement.

4. Sur le bureau, les CDN ont l’impact le plus sort sur le TTFB. Cependant, sur les appareils mobiles, c’est le nombre de requêtes HTML qui semble affecter le plus le TTFB.

5. La taille globale de la page a un impact significatif sur la vitesse de chargement visuel sur les ordinateurs de bureau et sur mobile. Le chargement visuel des pages plus volumineuses prend 318 % plus de temps que celui des pages plus petites. Nous avons également constaté que la compression gzip permettait de charger les images plus rapidement, à la fois sur les ordinateurs de bureau et les appareils mobiles.

6. Le poids total de la page est le premier facteur déterminant de la rapidité de chargement « Fully Loaded ». Les pages plus légères chargent complètement à une vitesse 486 % plus rapide que les pages plus lourdes.

7. Les frameworks Javascript les plus rapides sont Wink et Gatsby. Meteor et Tweenmax sont les plus lents. La différence de rapidité de chargement entre les deux est de 213 %.

8. Les pages avec une compression très faible ou très importante (mesurée via First Contextual Paint) enregistrent des performances de vitesse de chargement au-dessus de la moyenne.

9. Les scripts tiers ralentissent considérablement la vitesse de chargement des pages. Chaque script tiers augmente le temps de chargement de 34,1 millisecondes.

10. Nous avons découvert qu’utiliser des images responsives permettait d’améliorer les performances de chargement. L’utilisation de WebP était par contre nettement moins efficace pour réduire le temps de chargement des images.

11. Les hébergeurs GitHub et Weebly ont les performances TTFB les plus rapides que nous ayons pu observer. A l’inverse, Siteground et Wix sont parmi les fournisseurs d’hébergement les plus lents que nous ayons analysé.

12. La Chine, le Japon et l’Allemagne ont les temps de chargement TTFB les plus rapides. L’Australie, l’Inde et le Brésil les plus lents.

13. L’utilisation de CDN était corrélée à une performance de vitesse de transmission inférieure. Cela est probablement dû au fait que certains CDN sont nettement plus performants que d’autres.

Benchmarks des métriques clés de vitesse de chargement des pages

Notre première tâche consistait à établir des benchmarks des mesures clés de vitesse de chargement des pages.

Comme vous le savez certainement déjà, la vitesse de la page se compose de plusieurs étapes distinctes.

Stages of web page loading

Certaines de ces étapes se produisent au niveau du serveur. Les autres au sein du navigateur de l’internaute.

Et pour bien saisir la vitesse de chargement d’une page, nous devions décomposer précisément chacune de ces étapes.

Pour être plus précis, nous avons établi la vitesse moyenne pour :

  • TTFB : temps du premier octet de la réponse HTML ;
  • StartRender : quand l’affichage commence ;
  • Visual Complete : l’utilisateur peut voir tous les éléments de la page ;
  • Indice de vitesse : la rapidité avec laquelle un utilisateur voit le chargement d’une page ;
  • onLoad: lorsque toutes les ressources de la page (CSS, images, etc.) sont téléchargées
  • Fully Loaded : lorsqu’une page est chargée à 100 % dans le navigateur de l’utilisateur

La vitesse moyenne du TTFB est de 1,286 secondes sur un ordinateur de bureau et de 2,594 secondes sur mobile.

Mean TTFB speed on desktop and mobile

La vitesse moyenne du Start Render est de 2.834 secondes sur le bureau et de 6.709 secondes sur mobile.

Mean start render speed on desktop and mobile

Et la vitesse moyenne du Visual Complete est de 8,225 secondes sur le bureau est de 21,608 secondes sur mobile.

Mean visual complete speed on desktop and mobile

La vitesse moyenne de l’indice de vitesse est de 4,782 secondes sur le bureau et de 11,455 secondes sur le mobile.

Mean speed index speed on desktop and mobile

Et la vitesse moyenne de chargement (onLoad) est de 8,875 secondes sur le bureau et de 23,608 secondes sur mobile.

Mean onload speed on desktop and mobile

Pour finir, la vitesse moyenne de chargement total (Fully Loaded) est de 10,3 secondes sur le bureau et de 27,3 secondes sur mobile.

Mean fully loaded speed on desktop and mobile

À retenir : la vitesse moyenne de chargement d’une page Web est de 10,3 secondes sur le bureau et de 27,3 secondes sur mobile. En moyenne, le chargement de pages Web sur les appareils mobiles est 87,84 % plus long que sur un ordinateur de bureau.

Weebly and Squarespace sont les hébergeurs les plus performants en matière de vitesse de chargement. WordPress est le plus lent à charger les pages Web

En matière de rapidité de chargement, quel est le meilleur CMS ?

Pour répondre à cette question, nous avons établi quel était le CMS de chacun des sites de notre base de donnée. Nous avons ensuite comparé chacune de leurs performance pour le TTFB.

En se basant sur nos données, Weebly et Squarespace sont les plus rapides sur les ordinateurs de bureau.

CMS page speed performance rankings (Desktop)

Et pour les mobiles, on retrouve Squarespace en tête du classement, puis Adobe Experience Manager et Weebly.

CMS page speed performance rankings (Mobile)

Ce qu’il est intéressant de retenir est que, en matière de vitesse sur mobile, WordPress n’est qu’à la 14e place des CMS que nous avons analysé.

WordPress ranks #14th among CMSs for mobile page speed

Un autre hébergeur populaire, Wix, se retrouve également en bas de notre classement pour la vitesse de chargement sur mobile.

Wix ranks near the bottom for desktop and mobile page speed

Et donc même si WordPress héberge presque 30 % de tous les sites web, il n’est clairement pas optimisé pour accélérer la vitesse de chargement des pages. Cela ne veut pas dire que WordPress soit un mauvais fournisseur d’hébergement. Il présente en effet d’autres avantages (comme la facilité d’utilisation, un choix impressionnant de plugins et de bons outils pour optimiser sa SEO).

Cependant, lorsque l’on s’en tient strictement à la vitesse de chargement des pages, on observe que d’autres CMS sont nettement plus performants que WordPress.

A retenir : parmi les CMS les plus populaires, Squarespace et Weebly sont les plus performants en matière de vitesse de chargement des pages. WordPress et Wix sont quant à eux en bas de notre classement.

L’utilisation d’un CDN peut améliorer le TTFB sur les ordinateurs de bureau. Réduire au minimum les demandes HTML est essentiel pour le TTFB sur les appareils mobiles

Nous avons analysé l’impact de plusieurs caractéristiques de page web sur le TTFB (temps de chargement du premier octet).

Voici ce que nous avons découvert :

Factors that impact desktop and mobile TTFB

Comme vous pouvez le constater, l’utilisation d’un CDN semble améliorer le TTFB pour les ordinateurs de bureau et les appareils mobiles. Cependant, ils ont un impact plus important sur les premiers que sur les seconds. Sur les pages chargées sur un appareil mobile, le facteur le plus prégnant est le nombre de requêtes HTML.

Bien que nous ayons observé l’impact de ces caractéristiques sur le TTFB, ce dernier est relativement faible. Le TTFB est en grande partie déterminé par le temps de réponse du serveur, un sujet que nous aborderons un peu plus tard.

A retenir : l’utilisation d’un CDN et la réduction du nombre de requêtes HTML peuvent accélérer le TTFB sur les ordinateurs de bureau et les appareils mobiles.

Les pages volumineuses prennent 381 % plus de temps pour charger visuellement que les pages « légères »

Le “Visual Complete ” est le stade auquel l’ensemble du contenu visuel d’une page web s’affiche dans le navigateur de l’internaute.

Visually complete

Il est aussi possible que les scripts et d’autres ressources se chargent hors écran. Mais du point de vue de l’utilisateur, la page sera entièrement chargée.

Le Visual Complete est une mesure importante de la vitesse d’une page car elle affecte l’expérience subjective d’un utilisateur sur la rapidité ou la lenteur du chargement d’une page.

Tant qu’il peut voir et utiliser la page, l’internaute considèrera qu’elle est entièrement chargée…même si certains éléments peuvent être encore en cours de chargement en arrière-plan.

Nos tests nous ont permi d’établir que la taille de la page (le total d’octets) avait un impact significatif sur les vitesses de chargement visuel sur les ordinateurs de bureau et les mobiles.

Factors that impact Visually Complete on desktop and mobile

Cependant, la taille de la page est plus importante sur mobile que sur le bureau.

Sur un ordinateur de bureau, l’utilisation d’un CDN a été plus fortement corrélée à une rapidité du chargement visuel. La taille de la page n’était cependant pas loin derrière.

Sur les appareils mobiles, le CDN n’était que le 5e facteur le plus prégnant.

Donc si votre priorité est d’améliorer la vitesse de chargement de votre page sur mobile, mieux vaut faire tout votre possible pour en réduire la taille. Cela signifie supprimer les scripts tiers. Ou compresser les images. La stratégie à appliquer dépendra en général de votre site. Cependant, et en matière de vitesse de chargement visuel, c’est la taille (HTML) qui compte.

A retenir : le CDN peut améliorer de manière significative le temps de chargement visuel d’une page sur les ordinateurs de bureau et les mobiles. Cependant, son impact est nettement plus important sur les ordinateurs de bureau. Pour les mobile, c’est la taille de la page qui impactera le plus le temps de chargement visuel.

Le poids total d’une page est étroitement lié à la rapidité de chargement total des pages web

Pour finir, nous avons cherché les facteurs impactant la vitesse de chargement total (ou Fully Loaded).

Comme son nom l’indique, le stade “Fully Loaded” correspond au chargement et à l’affichage à 100% des éléments d’une page.

En matière de vitesse de chargement total, la taille d’une page est de loin le facteur le plus important sur les ordinateurs de bureau et les mobiles.

Factors that impact Fully Loaded on desktop and mobile

Le nombre de demandes joue également un rôle important dans la rapidité du chargement complet d’une page.

Ce qui est intéressant avec ces données (et contrairement aux autres mesures que nous avons pu analyser) c’est que les facteurs impactants sont globalement les mêmes pour les ordinateurs de bureau et les appareils mobiles (à savoir la taille de la page et le nombre total de requêtes HTML).

Néanmoins, l’importance de la taille de la page et des requêtes HTML ne devrait pas être une grosse surprise.

La compression d’images, la mise en cache ainsi que d’autres étapes vont considérablement réduire le temps de chargement d’une page web. Mais leur impact reste minime. En réalité, pour qu’une page soit «entièrement chargée», le navigateur devra charger tous les éléments actifs. Et donc plus il y a d’actifs à charger, plus le temps de chargement de la page sera long.

C’est probablement pour cette raison que les CDN ne semblent pas avoir beaucoup d’impact sur la vitesse de chargement total des pages web (il n’atteint que la troisième place pour les ordinateurs de bureau, et la 10ème pour les mobiles). Les CDN peuvent accélérer le temps de chargement des images, mais ils ne peuvent pas faire grand chose en ce qui concerne les scripts tiers et les autres ressources pouvant ralentir le chargement d’une page.

À retenir : la taille totale d’une page affecte sa vitesse de chargement total bien plus que toute autre caractéristique, à la fois sur bureau et mobile. Les pages volumineuses (plus de 3,49 Mo) mettent 486 % plus de temps à se charger complètement que les pages plus petites (moins de 0,83 Mo).

Wink et Gatsby sont les framework JavaScript les plus rapides pour les pages web de taille moyenne

Lorsqu’il s’agit de définir les éléments à charger en priorité sur une page (et à quel moment), ce sont les cadres JavaScript qui vont prendre en charge de nombreuses tâches.

C’est pourquoi près de 76 % des sites Web utilisent ces cadres pour améliorer le temps de chargement et la sécurité de leurs pages.

Nous avons commencé par rassembler des benchmarks sur la fréquence d’utilisation de chaque framework.

JavaScript framework usage

React est de loin le framework JavaScript le plus utilisé (25,3 % des sites web l’utilisent). TweenMax (10,3 %) et RequireJS (9,5 %) sont également populaires

Nous avons ensuite voulu savoir quels frameworks JavaScript étaient les plus performants sur les pages web de taille petite (<1 264 374 octets) et moyenne (1 264 374 et 4 019 332 octets) ainsi que sur les pages plus volumineuses (> 4 019 332 octets).

Pour les petites pages, RightJS est arrivé en tête.

Impact of JavaScript framework on FCP, page weight < 1,264,374 bytes

Wink et Gatsby ont obtenu les meilleurs résultats pour les pages de taille moyenne.

Impact of JavaScript framework on FCP, page weight between 1,264,374-4,019,332 bytes

Et pour les pages volumineuses, ce sont Gatsby et Riot qui ont enregistré les temps de FCP les plus rapides.

Impact of JavaScript framework on FCP, page weight > 4,019,332 bytes

Globalement, le choix d’un framework JavaScript peut avoir un impact significatif sur les délais du FCP. D’ailleurs, pour les pages de taille moyenne, le meilleur framework Javascript (en l’occurrence Wink) a enregistré une vitesse de chargement 213 % plus rapide que le framework le plus lent (Meteor).

Bien que les scripts les plus et les moins performants puissent se chevaucher (c’est le cas, par exemple, des cadres Gatsby et RightJS qui figurent dans le top 5 pour les trois catégories de taille de page), il semble que certains cadres JavaScript fonctionnent mieux sur certaines tailles que d’autres.

Par exemple, Riot est un excellent cadre pour les grandes pages (le 2nd).

Riot is good for large pages

Par contre, pour les petites pages, Riot s’en sort nettement moins bien (15ème au total).

Riot is not good for small pages

À retenir : il n’existe pas de «meilleur» cadre JavaScript pour tous les formats de page. RightJS est le plus performant pour les sites contenant de nombreuses pages de petite taille. Mais pour les sites Web contenant principalement des pages volumineuses, Gatsby sera plus indiqué.

Les pages avec des niveaux de compression faible ou élevé ont les temps de chargement les plus rapides

Compresser les fichiers d’une page sur un serveur est une épée à double tranchant. D’un côté, cela permet de réduire significativement son poids total.

Cependant, compresser des fichiers avant de les envoyer à partir du serveur nécessite un travail supplémentaire de la part du navigateur, car le client doit décompresser les fichiers avant de les restituer.

Dans le cadre de cette analyse, nous avons tenté de répondre à la question suivante : la compression de fichiers améliore-t-elle réellement la vitesse de traitement des pages web ?

Pour répondre à cette question, nous avons classé le FCP en trois catégories distinctes (rapide, moyen, lent) :

  • Rapide : 0-1000ms
  • Moyen : 1000ms-2500ms
  • Lente : <2500ms

Nous avons ensuite comparé la vitesse du FCP et les niveaux de compression entre les pages de petite, moyenne et grande taille.

Pour les petites pages, des niveaux de compression plus faibles se traduisent par des temps de chargement FCP plus rapides. Cependant, les temps de chargement augmentent à des niveaux de compression très élevés (90-100 %).

Impact of compression on FCP, page weight < 880,337 bytes

Les pages de taille moyenne ont une distribution similaire :

Impact of compression on FCP, page weight 880,337-3,625,927 bytes

La distribution des pages de grande taille forme une courbe en cloche inversée encore plus marquée :

Impact of compression on FCP, page weight > 3,625,927 bytes

Bien que la répartition exacte entre les tailles de page diffère, la conclusion est claire : les pages avec les niveaux de compression les plus faibles ou les plus élevés chargent le plus rapidement.

En fait, on peut même constater une baisse des performances FCP pour les pages compressant modérément leurs fichiers.

Dip in FCP performance for pages that compress a moderate amount of files

Pour être plus précis, les pages qui compressent entre 60 % et 80 % de leurs fichiers sont les moins performantes.

Par conséquent, et en ce qui concerne l’amélioration de la vitesse d’une page, les taux de compression très faibles ou très élevés ont tendance à mieux fonctionner. Les faibles niveaux de compression réduisent le travail du navigateur. Et des niveaux élevés de compression compensent la charge de travail du client avec une charge utile plus faible.

A retenir : les pages ayant un niveau de compression très faible ou très élevé chargent plus rapidement que les pages avec des niveaux de compression modérés.

Les scripts tiers ont un impact négatif sur les temps de chargement

Nous avons également constaté, sans surprise, que les scripts tiers (tels que Google Analytics, les boutons de partage sur les réseaux sociaux et les vidéos) ralentissaient le temps de chargement FCP .

Third-party scripts negatively impact page load times

En fait, nous avons constaté que chaque script tiers augmente le temps de chargement d’une page de 34,1 millisecondes.

Nos résultats sont d’ailleurs les mêmes que ceux (comme celui-ci) ayant établit que les scripts tiers avaient un impact considérable sur la vitesse de traitement des pages.

De toute évidence, l’impact dépendra du script utilisé. Certains scripts tiers (tels que Hotjar) chargent assez rapidement. D’autres, dont Salesforce, sont notoirement beaucoup plus lents.

En bref, les scripts tiers entraînent des temps de chargement plus longs. Et plus une page en contient, plus elle aura tendance à charger lentement.

A retenir : Chaque script tiers utilisé sur une page augmente son temps de chargement de 34,1 millisecondes.

Les images responsive semblent améliorer les temps de chargement des pages plus que le « Lazy loading » et l’utilisation dû format WebP

Les images jouent un rôle extrêmement important dans les performances d’un site Web pour deux raisons principales :

Pour commencer, les images occupent une part non négligeable de la taille globale d’une page.

Deuxièmement, l’attention de l’utilisateur a tendance à se concentrer sur les images. Et si elles se chargent trop lentement, cela peut avoir un impact négatif sur son expérience.

Les images ayant un impact énorme sur la vitesse de chargement d’un site, nous avons décidé de comparer les performances de 4 stratégies d’optimisation des images différentes :

  • WebP: Développé par Google, WebP est un format d’image généralement plus petit, mais qui permet d’obtenir un niveau de qualité d’image similaire à celui de fichiers plus lourds.
  • Les images optimisées : Les «images optimisées» désignent différentes versions d’une image, en fonction du périphérique de l’utilisateur, de son emplacement, etc. Nous avons inclus l’utilisation d’un réseau de distribution de contenu (CDN), la compression d’image et d’autres services Web d’optimisation d’images dans cette catégorie.
  • Différer les images hors écran : quand les images situées sous le curseur de l’utilisateur se chargent lorsqu’il fait défiler la page jusqu’à leur emplacement. C’est ce que l’on appelle également le « Lazy loading » ou «chargement paresseux».
  • Les images responsive : elles s’adaptent de manière dynamique à la taille de la fenêtre du navigateur.

Lorsque nous avons comparé ces différentes approches en matière de vitesse de chargement sur Lighthouse, ce sont les images responsive qui se sont imposées

Responsive images are correlated with best lighthouse speed score

Nous avons également analysé quelle approche avaient obtenu les meilleurs scores sur Lighthouse. Et les résultats étaient très similaires.

Responsive images are correlated with a higher % of 100/100 lighthouse speed scores

A retenir : bien que le format WebP puisse améliorer la compression d’une image par rapport au format PNG et JPEG, très peu de sites l’ont à ce jour implémenté.

GitHub et Weebly Hosting obtiennent la meilleure performance de TTFB. Siteground et Wix se retrouvent en bas de notre classement

Nous avons comparé les performances de débit de page des principaux fournisseurs d’hébergement Web.

Considérant que le temps de réponse du serveur a l’impact le plus important sur le TTFB, nous avons analysé les performances de différents hôtes sur cette métrique clé.

Plus précisément, nous avons classé le TTFB en trois catégories (Rapide, Moyen, Lent). Et nous avons examiné le pourcentage d’apparition de chaque hôte dans chaque catégorie.

Voici les performances TTFB de chaque fournisseur d’hébergement Web sur les ordinateurs de bureau :

TTFB performance among major web hosting providers (Desktop)

Github, Weebly et Acquia sont les trois hébergeurs les plus performants en matière de TTFB sur les ordinateurs de bureau. Automattic, Wix et Siteground sont quant à eux les moins performants sur cette métrique.

Nous avons effectué la même analyse pour le TTFB sur mobile. Voici les résultats :

TTFB performance among major web hosting providers (Mobile)

Comme vous pouvez le constater, Github performe extrêmement bien à la fois sur les ordinateurs de bureau et les mobiles. Cela ne devrait donc pas vous surprendre d’apprendre que les pages Github ne servent que les ressources statiques. Ce qui signifie qu’il est impossible, à bien des égards, de comparer Github aux hébergeurs dits « normaux ».

Seravo, Netlify et Weebly complètent le top 4. Wix et Automattic arrivent quant à eux en bas de la liste.

Quel est le résultat de cette analyse?

Le TTFB n’est qu’un des nombreux facteurs à prendre en compte lorsque l’on choisit un hébergeur pour son site web. Le coût, la disponibilité, le service client, les fonctionnalités, entrent également en considération.

Cela dit, pour ce qui est du temps de chargement des pages sur les ordinateurs de bureau et les mobiles, Github est de loin la meilleure option. Wix et Automattic ont tendance à avoir des TTFB nettement plus lents.

A retenir : parmi les principaux fournisseurs d’hébergement, Github et Weebly ont obtenu les meilleurs résultats sur les ordinateurs de bureau. D’après notre analyse, GitHub et Seravo étaient les hébergeurs mobiles les plus rapides. Cependant, il convient de noter que Github ne délivre que des pages statiques, ce qui lui confère un avantage considérable par rapport aux autres hébergeurs que nous avons pu analyser.

La Chine, le Japon et l’Allemagne ont les temps de chargement TTFB les plus rapides

En nous appuyant sur notre base de données, nous avons comparé les temps de chargement du TTFB de 11 pays.

Voici les résultats pour la vitesse de chargement sur un ordinateur de bureau :

TTFB load times by country (Desktop)

Et les appareils mobiles :

TTFB load times by country (Mobile)

A retenir : La Chine offre les meilleures performances TTFB pour les ordinateurs de bureau et les mobiles. Suivent le Japon et l’Allemagne avec des vitesses de chargement supérieures à la moyenne mondiale. La France, le Royaume-Uni, le Canada, les États-Unis et la Russie ont une vitesse moyenne. L’Australie, le Brésil et l’Inde sont les pays dans lesquels le temps de chargement est inférieur à la moyenne mondiale.

Les pages avec des CDN sont moins performantes que celles sans

L’une de nos découvertes les plus surprenantes a été d’apprendre que les pages avec des CDN étaient en réalité bien moins performantes que celles qui n’en contenaient aucun.

Ce qui est vrai à la fois pour les ordinateurs de bureau :

Use of CDN correlates with worse desktop page speed

Et les appareils mobiles :

Use of CDN correlates with worse mobile page speed

Comment cela est-il possible ?

En théorie, et parce qu’il fournit un contenu proche de l’endroit où se trouve l’utilisateur, le CDN devrait améliorer la vitesse de chargement d’une page web.

How a CDN works

Cependant, ce n’a pas été le cas dans notre analyse.

Nous avons émis l’hypothèse que tous les CDN ne se valent pas. Dans de nombreux cas, l’utilisation d’un CDN mal optimisé peut avoir l’effet inverse et ralentir le chargement d’une page.

Et lorsque nous avons analysé les performances des 18 meilleurs fournisseurs de CDN, nous avons pu constater une différence de performances considérable.

Page speed performance among major CDNs

Pour être plus précis, nous avons constaté que (sur le bureau), le meilleur CDN affichait une performance 3,6 fois supérieure à celle du CDN le moins performant. Ce qui permet de comprendre pourquoi les CDN n’améliorent pas automatiquement les performances d’un site web.

Pour faciliter la détection des CDN les moins performants, nous avons comparé leurs performances à la moyenne mondiale.

Page speed performance among major CDNs compared to the average

Nous avons ensuite classé chaque CDN dans l’une des trois catégories suivantes :

  • Bon (les pourcentages de rapidité et de lenteur sont meilleurs que la moyenne de tous les fournisseurs) ;
  • Moyen (les pourcentages de rapidité et de lenteur sont équivalents à la moyenne de tous les fournisseurs) ;
  • Mauvais (les pourcentages de rapidité et de lenteurs sont en-dessous de la moyenne de tous les fournisseurs)

Voici un résumé des performances pour chaque fournisseur:

Pour les ordinateurs de bureau

  • Bon : Airee, Amazon Cloudfront, Azure CDN, CacheFly, EdgeCast, Fastly, GitHub Pages, Google Cloud, KeyCDN, MaxCDN, Netlify
  • Moyen: CDN77
  • Mauvais: Akamai, ArvanCloud, Cloudflare, Fireblade, Incapsula, Sucuri

Pour les appareils mobiles

  • Bon : Airee, Amazon Cloudfront, Azure CDN, CacheFly, EdgeCast, Fastly, GitHub Pages, Google Cloud, KeyCDN, MaxCDN, Netlify
  • Moyen : Fireblade, Incapsula, Sucuri
  • Mauvais : Akamai, ArvanCloud, Cloudflare

À retenir : l’utilisation d’un CDN n’améliorera pas automatiquement les performances de vitesse d’une page. Certains CDN sont nettement plus performants que d’autres. Par conséquent, il est important d’utiliser un CDN qui soit performant sur les ordinateurs de bureau et les appareils mobiles.

Est-ce que cet article vous a plu ?

Cliquez pour voter

Résultat de l'article / 5. Nombre de vote

pas encore de vote, soyez le premier

As you found this post useful...

Follow us on social media!