manuboss
Nous avons analysé 5 millions de pages de bureau et mobiles pour déterminer les facteurs affectant la vitesse de la page.
Premièrement, nous avons établi des points de référence mondiaux pour les métriques de temps de chargement TTFB, Visual Complete et Fully Loaded.
Nous avons ensuite examiné l'impact de la compression d'image, des CDN et de l'hébergement sur la vitesse de chargement du site.
Nos données ont révélé des informations très intéressantes (et surprenantes).
Voici un résumé de nos principales conclusions:
1. Dans notre analyse de 5,2 millions de pages, le La durée moyenne du premier octet (TTFB) sur le bureau est de 1,286 seconde sur le bureau et 2,594 secondes sur le bureau. 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 le mobile.
2. La page Web moyenne prend 87,84% plus long charger sur mobile vs bureau.
3. Lors de la comparaison des principaux CMS les uns contre les autres, Squarespace et Weebly offrent les meilleures performances globales pour les vitesses de page mobiles. Wix et WordPress se sont classés près du bas.
4. Sur le bureau, les CDN ont le plus gros impact sur TTFB. Cependant, sur les appareils mobiles, le nombre de requêtes HTML semble affecter le plus grand nombre de TTFB.
5. La taille globale de la page a un impact significatif sur la vitesse de chargement "Complètement visuel" sur les ordinateurs de bureau et mobiles. Il faut 318% de temps supplémentaire pour charger visuellement les plus grandes pages.. Nous avons également constaté que la compression gzip permet aux images de se charger plus rapidement sur les ordinateurs de bureau et les appareils mobiles.
6. Le poids total de la page est le déterminant n ° 1 de la vitesse de la page entièrement chargée. Le chargement complet des pages claires est 486% plus rapide que les grandes pages.
Sept. Wink et Gatsby sont les frameworks JavaScript les plus rapides. Meteor et Tweenmax sont les plus lents. Le framework le plus rapide est 213% plus rapide que le plus lent.
8. Les pages avec une compression de fichier très basse ou très élevée ont une vitesse de traitement supérieure à la moyenne (mesurée à l'aide de la première peinture contextuelle).
9. Les scripts tiers ralentissent considérablement la vitesse de chargement des pages. Chaque script tiers ajouté à une page augmente le temps de chargement de 34,1 millisecondes.
10. Nous avons constaté que l'utilisation d'images réactives offrait les meilleures performances globales de chargement d'images. L'utilisation de WebP s'est avérée beaucoup moins efficace pour réduire les temps de chargement des images.
11. Les hébergeurs Web GitHub et Weebly ont les performances TTFB globales les plus rapides. Siteground et Wix sont les plus lents parmi les fournisseurs d'hébergement hébergé.
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 ont les temps de TTFB les plus lents.
13 L'utilisation du CDN est corrélée à la performance du taux de transmission inférieur. Cela est probablement dû au fait que certains CDN fonctionnent beaucoup mieux que d'autres.
Points de repère pour les métriques de vitesse de chargement pour les pages clés
Notre première tâche consistait à établir des repères pour les mesures importantes de la vitesse de la page.
Comme vous le savez peut-être, la vitesse de la page se compose de plusieurs étapes distinctes.
Certaines de ces étapes se produisent au niveau du serveur. Et d'autres sont effectuées dans le navigateur de l'utilisateur.
Et pour comprendre la vitesse de chargement des pages, nous avons dû approfondir chacune de ces étapes.
Plus précisément, nous avons déterminé la vitesse moyenne pour:
- TTFB: Temps jusqu'au premier octet de la réponse doc HTML
- StartRender: Quand le rendu commence
- Visual Complete: L'utilisateur peut voir tous les actifs de la page
- Indice de vitesse: À quelle vitesse un utilisateur voit-il une page chargée?
- en charge: Lorsque toutes les ressources de la page (CSS, images, etc.) sont téléchargées
- Complètement chargé: Lorsqu'une page est chargée à 100% dans le navigateur d'un utilisateur
La vitesse moyenne du TTFB est de 1,286 seconde sur le bureau et de 2,594 secondes sur le mobile.
La vitesse moyenne de démarrage du rendu est de 2,834 secondes sur le bureau et de 6,709 secondes sur le mobile.
La vitesse moyenne visuelle totale est de 8,225 secondes sur le bureau et de 21,608 secondes sur le 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.
La vitesse de chargement moyenne est de 8,875 secondes sur le bureau et de 23,608 secondes sur le mobile.
La vitesse de chargement totale moyenne est de 10,3 secondes sur le bureau et de 27,3 secondes sur le mobile.
Clé à emporter: La vitesse de chargement moyenne d'une page Web est de 10,3 secondes sur le bureau et de 27,3 secondes sur le mobile. En moyenne, les pages chargées sur des appareils mobiles sont 87,84% plus longues que sur le bureau.
Weebly et Squarespace ont les meilleures performances de vitesse globale. WordPress a l'un des pires
En ce qui concerne la vitesse de la page, quel CMS est le meilleur?
Pour répondre à cette question, nous avons déterminé le système de gestion de contenu utilisé pour tous les sites de notre jeu de données. Nous avons ensuite comparé les performances TTFB de chaque CMS découvert.
Selon nos données, Weebly et Squarespace sont les mieux placés pour le bureau.
Et pour la vitesse des pages mobiles, Squarespace est n ° 1 … Adobe Experience Manager et Weebly complètent le top 3.
Il est intéressant de noter qu'en termes de vitesse mobile, WordPress n'est que le 14ème meilleur CMS que nous ayons analysé.
Un autre CMS populaire, Wix, a également obtenu une mauvaise note pour la vitesse de chargement des ordinateurs de bureau et mobiles.
Bien que WordPress utilise environ 30% de tous les sites Webclairement pas optimisé pour la vitesse de chargement des pages. Cela ne signifie pas que WordPress est un mauvais CMS. Il présente d’autres avantages (facilité d’utilisation, vaste bibliothèque de plugins et référencement) qui en fait le système de gestion de contenu ultime pour de nombreux propriétaires de sites.
Toutefois, si l’on examine strictement la vitesse de chargement du site Web, il apparaît que les autres systèmes de gestion de contenu ont un avantage distinct par rapport à WordPress.
Clé à emporter: Parmi les principaux systèmes de gestion de contenu, Squarespace et Weebly offrent les meilleures performances en termes de vitesse de transmission des pages mobiles. WordPress et Wix se classent près du bas.
L'utilisation d'un CDN peut aider le bureau de la TTFB. Réduire au minimum les requêtes HTML est essentiel pour TTFB mobile
Nous avons analysé l'impact de différentes fonctionnalités de page sur TTFB (délai jusqu'au premier octet).
Voici ce que nous avons trouvé:
Comme vous pouvez le constater, l’utilisation d’un CDN semble améliorer TTFB pour les ordinateurs de bureau et les appareils mobiles. Cependant, les CDN semblent être plus utiles sur les ordinateurs de bureau que sur les mobiles. Sur les pages chargées via un appareil mobile, le nombre de requêtes HTML avait le plus grand impact sur TTFB.
Bien que nous ayons trouvé une relation entre différentes fonctionnalités de la page et les heures TTFB, les facteurs au niveau de la page ne peuvent ni gagner ni casser la durée TTFB. TTFB est en grande partie déterminé par le temps de réponse du serveur, dont nous parlerons un peu plus tard.
Clé à emporter: L'utilisation d'un CDN et la réduction du nombre de requêtes HTML peuvent accélérer TTFB sur les ordinateurs de bureau et mobiles.
Les pages volumineuses prennent 381% plus de temps à "remplir visuellement" la charge par rapport aux pages plus petites
"Visuellement terminé" correspond au moment où tout le contenu visuel d'une page Web dans le navigateur d'un utilisateur est chargé.
Les scripts et autres ressources peuvent se charger hors écran. Mais du point de vue de l'utilisateur, la page est chargée.
Visuellement complète est une mesure importante de la vitesse de la page, car elle affecte l'expérience subjective de l'utilisateur en ce qui concerne la vitesse ou la lenteur du chargement d'une page.
Tant qu'un utilisateur peut voir et utiliser la page, elle est entièrement chargée … même s'il peut toujours y avoir du chargement et du rendu d'éléments en arrière-plan.
Nous avons constaté que la taille de la page (nombre total d'octets) avait un effet significatif sur les temps de chargement visuel et mobile.
Cependant, la taille de la page est plus grande sur le mobile que sur le bureau.
Sur un ordinateur de bureau, l’utilisation d’un CDN était plus fortement corrélée à une vitesse de chargement plus rapide. La taille de la page vient en deuxième place.
Sur les appareils mobiles, un CDN n'était que le cinquième facteur le plus important.
Par conséquent, si l'amélioration de la vitesse de chargement des téléphones mobiles est une priorité absolue pour moi, je considérerais de tout mettre en œuvre pour réduire la taille de vos pages. Cela peut signifier la suppression de scripts tiers. Ou compresser des images. Les étapes exactes dépendront de votre site. Cependant, il est clair que la vitesse visuelle complète dépend de la taille de HTML.
Clé à emporter: Les CDN peuvent considérablement améliorer la vitesse de traitement des pages visuellement complètes sur les ordinateurs de bureau et les appareils mobiles. Cependant, les CDN ont un impact beaucoup plus important sur le chargement des postes de travail. Pour les appareils mobiles, la taille totale de la page est le facteur le plus important pour les temps de chargement complet.
Le poids total de la page est étroitement lié à la vitesse de la page "entièrement chargée"
Enfin, nous avons examiné les facteurs qui affectent la vitesse de la page "Entièrement chargé".
Comme son nom l'indique, "Complètement chargé" correspond au chargement et au rendu de 100% des éléments d'une page.
En ce qui concerne la vitesse de la page entièrement chargée, la taille totale d'une page est de loin le facteur le plus important sur les ordinateurs de bureau et les mobiles.
Le nombre de demandes joue également un rôle dans la rapidité du chargement complet d'une page.
Ce qui est intéressant avec ces données, c’est qu’il existe beaucoup de chevauchements entre les ordinateurs de bureau et les appareils mobiles. Contrairement à la plupart des autres mesures que nous avons analysées, le même ensemble de variables (c’est-à-dire la taille de la page et le nombre total de requêtes HTML) semble avoir un impact sur les packages de bureau et mobiles Fully Loaded.
Cependant, l'importance de la taille de la page et des requêtes HTML ne devrait pas être une grosse surprise.
La compression d'image, la mise en cache et d'autres étapes réduisent généralement le temps de chargement d'une page. Mais ils ne peuvent aller que si loin. À la fin de la journée, pour qu'une page soit "entièrement chargée", un navigateur doit charger tous les actifs d'une page. Et plus il y a d'actifs à charger, plus le chargement de la page est long.
C'est probablement pour cette raison que les CDN ne semblent pas avoir beaucoup d'impact sur la vitesse de chargement des pages entièrement chargées (3ème en importance globale sur les ordinateurs de bureau, 10ème sur les mobiles). Les NDC peuvent améliorer les temps de chargement des images. Mais ils ne font pas grand chose pour aider avec des scripts tiers et d'autres ressources qui peuvent ralentir les choses.
Clé à emporter: La taille totale influe davantage sur la vitesse de la page entièrement chargée que sur toute autre variable du bureau et du mobile. Les pages volumineuses (> 3,49 Mo) mettent 486% plus de temps à se charger complètement que les pages plus petites (<0,83 Mo).
Wink et Gatsby sont les cadres JavaScript les plus rapides pour les pages Web de taille moyenne.
Quand il s’agit de donner la priorité à ce qu’il faut charger sur une page (et quand), Frameworks JavaScript faire beaucoup de soulever des objets lourds.
C'est pourquoi près de 76% de tous les sites Web utiliser ces cadres pour créer des pages efficaces, sécurisées et normalisées.
Nous avons d’abord rassemblé des données de référence sur la fréquence d’utilisation de chaque framework sur le Web.
React est de loin le framework JS le plus utilisé (25,3% des sites l'utilisent). TweenMax (10,3%) et RequireJS (9,5%) sont également très populaires.
Ensuite, nous voulions savoir quels étaient les meilleurs frameworks JavaScript (4 019 332 octets).
RightJS venait en premier pour les petites pages.
Wink et Gatsby ont eu les meilleurs résultats pour les pages du milieu.
Et pour les grandes pages, Gatsby et Riot ont enregistré les meilleurs temps du FCP.
Cependant, pour les petites pages, Riot s'en sortait beaucoup moins bien (15ème au total).
Clé à emporter: Il n'y a pas de "meilleur" framework JavaScript pour chaque situation. RightJS est votre meilleur choix pour les sites contenant de nombreuses petites pages. Pour les sites Web contenant principalement de grandes pages, Gatsby semble être idéal.
Les pages avec des niveaux de compression faibles ou élevés ont les temps de chargement les plus rapides
La compression des fichiers de page sur un serveur est une arme à double tranchant. D'un côté, La compression de fichier réduit considérablement le poids de la page.
Toutefois, la compression des fichiers avant de les envoyer à partir du serveur nécessite du travail supplémentaire sur le 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 fichier améliore-t-elle vraiment la vitesse de traitement des pages?
Pour répondre à cette question, nous avons classé le Fonds en trois catégories (rapide, moyen, lent):
Rapide: 0-1000ms
Moyenne: 1000ms-2500ms
Lente: <2500ms
Nous avons ensuite comparé la vitesse du FCP et les niveaux de compression entre les petites, moyennes et grandes pages.
Pour les pages plus petites, des niveaux de compression plus bas étaient associés à des temps de chargement FCP plus rapides. Cependant, les temps de chargement augmentent à des niveaux de compression très élevés (90-100%).
Les pages de taille moyenne avaient une distribution similaire:
Les grandes pages avaient une distribution en courbe en cloche inversée encore plus extrême:
Plus précisément, les pages qui compressent entre 60% et 80% de leurs fichiers ont les plus mauvais résultats.
Par conséquent, lorsqu'il s'agit d'améliorer la vitesse de la page, les taux de compression très faibles ou très élevés ont tendance à fonctionner mieux. Les faibles niveaux de compression réduisent le travail requis par le navigateur. De plus, les niveaux de compression élevés compensent la charge de travail pénible du côté client avec une charge utile plus petite.
Clé à emporter: Les pages avec une compression très faible ou très élevée fonctionnent mieux que les pages avec des niveaux de compression modérés.
Les scripts tiers ont un impact négatif sur les temps de chargement
Sans surprise, nous avons constaté que les scripts tiers (tels que Google Analytics, les boutons de partage de réseau et les hôtes vidéo) entraînaient des temps FCP plus lents.
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 en ligne avec les autres (comme ça) qui ont découvert que les scripts tiers avaient un impact considérable sur la vitesse de traitement des pages.
De toute évidence, l'impact dépend du script utilisé. Certains scripts tiers (tels que Hotjar) se chargent assez rapidement. D'autres, y compris Salesforce, sont notoirement lents.
En bref, les scripts tiers entraînent des temps de chargement plus longs. Et plus une page contient de scripts, plus elle a tendance à se charger lentement.
Clé à emporter: Chaque script tiers utilisé sur une page augmente le temps de chargement de la page de 34,1 millisecondes.
Les images réactives semblent améliorer les temps de chargement des pages bien plus que de simplement charger et utiliser WebP
Les images jouent un rôle extrêmement important dans les performances des sites Web pour deux raisons principales:
Tout d'abord, les images prennent une quantité importante de la taille globale d'une page.
Deuxièmement, l'attention de l'utilisateur a tendance à se concentrer sur les images qui apparaissent sur une page. Et si ces images se chargent lentement, cela peut avoir un impact négatif sur l'UX.
Les images pouvant faire ou défaire la vitesse de chargement d’un site, nous avons décidé de comparer les performances de 4 approches différentes de l’optimisation de l’image:
- WebP: Développé par Google, WebP est un format d’image dont la taille peut être inférieure à celle des autres formats de fichier, mais qui offre néanmoins un niveau de qualité d’image similaire.
- Images optimisées: "Images optimisées" fait référence à 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), de la compression d’images et d’autres services Web d’optimisation d’images dans cette catégorie.
- Retarder les images hors écran Lorsque les images situées sous le pli sont chargées lorsqu'un utilisateur fait défiler l'écran jusqu'à ce point de la page. Aussi appelé "chargement paresseux".
- Images sensibles: Lorsque les images s’adaptent dynamiquement à la taille de la fenêtre du navigateur.
Et quand on a comparé ces différentes approches de Scores de vitesse au phare, Images réactives est sorti au sommet.
Nous avons également analysé quelle approche a conduit au plus 100/100 scores de phare. Et les résultats étaient très similaires.
Clé à emporter: Bien que WebP puisse améliorer la compression d’image sur les fichiers PNG et JPEG, très peu de sites ont jusqu’à présent implémenté ce nouveau format d’image.
GitHub et Weebly Hosting a la meilleure performance de TTFB. Siteground et Wix ont le pire
Nous avons comparé les performances en termes de débit de page de grands fournisseurs d'hébergement Web.
Considérant que le temps de réponse du serveur a le plus grand impact sur TTFB, nous avons analysé les performances de différents hôtes sur cette métrique clé.
Plus précisément, nous avons classé TTFB dans 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 le bureau:
Github, Weebly et Acquia ont été les trois principaux acteurs de la technologie de bureau de TTFB. Automattic, Wix et Siteground ont été les plus mal lotis.
Nous avons fait cette même analyse pour TTFB mobile. Voici les résultats:
Comme vous pouvez le constater, Github fonctionne extrêmement bien sur les ordinateurs de bureau et mobiles. Qui, étant donné que Pages Github servir de ressources statiques, ne devrait pas être une surprise. Ce qui signifie que, à bien des égards, Github n’est pas une comparaison 1: 1 avec des hôtes Web "normaux".
Seravo, Netlify et Weebly complètent le top 4. Wix et Automattic figurent en bas de la liste.
Quel est le résultat de cette analyse?
TTFB n'est qu'un des nombreux facteurs à prendre en compte lors du choix d'un hôte. Coûts, disponibilité, support client, fonctionnalités, etc.
Cela dit, en ce qui concerne le temps de chargement rapide des pages sur les ordinateurs de bureau et les appareils mobiles, Github Pages est de loin la meilleure option parmi les principaux hôtes. Les hôtes Wix et Automattic ont tendance à avoir des temps TTFB lents.
Clé à emporter: Parmi les principaux fournisseurs d’hébergement, Github et Weebly se sont mieux compris que sur leurs ordinateurs de bureau. Selon notre analyse, GitHub et Seravo étaient les hôtes mobiles les plus rapides. Il n'y a pas de doute que Github ne contient que des pages statiques, ce qui lui confère un avantage inhérent aux autres hôtes que nous avons analysés.
La Chine, le Japon et l'Allemagne ont pris le temps de charger TTFB les plus rapides
Nous avons comparé les temps de chargement de TTFB pour 11 pays à partir de notre ensemble de données.
Voici une ventilation des vitesses de bureau:
Et mobile:
Clé à emporter: La Chine offre les meilleures performances TTFB pour les ordinateurs de bureau et mobiles. Viennent ensuite le Japon et l'Allemagne avec les vitesses de page supérieures à la moyenne mondiale. La France, le Royaume-Uni, le Canada, les États-Unis et la Russie ont une vitesse moyenne de page. L'Australie, le Brésil et l'Inde ont moins de vitesse inférieure à la moyenne mondiale.
Les pages avec CDN ont des performances pires que celles sans CDN
The découvertes inédites pire que ceux qui n'étaient pas utilisés de CDN.
C'était vrai pour les deux postes de travail:
Et mobile:
Comment cela pourrait-il être?
En théorie, il sera un contenu proche de l'endroit où l'on trouve l'utilisateur, un CDN devrait améliorer la vitesse de transmission des pages.
Cependant, ce n'était pas le cas dans notre analyse.
Nous avons émis l'hypothèse que tous les CDN ne sont pas créés égaux. Dans de nombreux cas, l'utilisation d'un CDN peut être ralentie.
Nous avons analysé les performances des 18 meilleurs fournisseurs de CDN, nous avons découvert une différence de performances considérable.
On a remarqué que le meilleur CDN affichait une performance 3,6 fois supérieure à celle du pire CDN. This aid to explique pourquoi les CDN n'améliorent pas automatiquement les performances.
Pour faciliter la détection des moins performants, nous avons comparé les performances du CDN à la moyenne mondiale.
Nous plaçons ensuite chaque CDN dans l’un des trois compartiments suivants:
- Bon (% fast and% lent lentes
- Moyenne (% fast or% lent lent
- Mauvais (% rapide et% lent lent sont la moyenne de tous les fournisseurs)
Voici un résumé des performances pour chaque fournisseur:
Bureau
Bien: Airee, Amazon Cloudfront, CDN Azure, CacheFly, EdgeCast, Rapidement, Pages GitHub, Google Cloud, KeyCDN, MaxCDN, Netlify
Moyenne: CDN77
Mauvais: Akamai, ArvanCloud, Cloudflare, Fireblade, Incapsula, Sucuri
Mobile
Bien: Airee, Amazon Cloudfront, CDN Azure, CDN77, EdgeCast, Rapidement, Pages GitHub, Google Cloud, KeyCDN, MaxCDN, Netlify
Moyenne: Lame de feu, Incapsula, Sucuri
Mauvais: Akamai, ArvanCloud, Cloudflare
Clé à emporter: L’utilisation d’un CDN n’est pas automatiquement améliorée. Certains CDN bien nettement mieux que d'autres. Par conséquent, il est important d’utiliser un CDN qui fonctionne bien sur les ordinateurs de bureau et les appareils mobiles.
Conclusion
Si vous souhaitez en savoir plus sur cette analyse, cette analyse a été effectuée, n'hésitez pas à consulter nos méthodes d'étude PDF.
Maintenant, j'aimerai avoir de vos nouvelles:
Quelle conclusion de cette étude vous a marqué?
Ou:
Sur quel résultat comptez-vous agir?
Quoi qu'il en soit, faites en moi un commentaire ci-dessous.
