La vitesse de chargement des sites Web sera un facteur de classement officiel de Google l'année prochaine et comme le processus d'optimisation n'est pas simple, vous devriez commencer dès maintenant.

Pour vous aider, voici un bref résumé des principaux résultats de notre analyse :

Résumé des principaux résultats de vitesse de page

• 29 % des temps de chargement au Royaume-Uni ne sont pas acceptables , selon les attentes de Google : ils sont supérieurs au maximum de 2,5 secondes.
• La tendance , cependant, pointe dans la bonne direction . La proportion de sites Web rapides a augmenté de 2 % ces derniers mois.
• L'accès aux sites Web depuis le Royaume-Uni n'est pas aussi rapide qu'il pourrait l'être . Les leaders européens sont la Suisse, la Suède, la Norvège et l'Allemagne.
• Jimdo montre que les CMS basés sur le cloud peuvent fournir de très bonnes valeurs Core Web Vitals. Mais l'open source peut aussi le faire - Typo3 est seulement un peu plus lent.
• Aucun CMS n'est plus lent que Wix . C'est le porte-cuillère en bois de la catégorie CMS. En dernière position derrière WordPress , cela montre que les solutions basées sur le cloud ne sont pas toujours rapides.
• Lightspeed fournit un système de boutique extrêmement rapide. Shopify n'est que dans la moitié inférieure de la liste. Le module complémentaire WordPress WooCommerce est le système de boutique le plus lent.
• Le langage de programmation n'est pas crucial pour les technologies web : il existe des frameworks rapides en Ruby (on Rails), PHP (Yii & Laravel), Python (Django) et d'autres langages. Seul Angular est vraiment lent.
• AMP ne conduit pas automatiquement à des sites Web rapides . Seulement environ 70% des pages AMP répondent aux normes Core Web Vitals.

Si vous avez plus de temps, voici l'analyse complète avec toutes les données et de nombreuses autres découvertes intéressantes sur les temps de chargement, les systèmes rapides et lents et les connexions derrière eux.

Pourquoi le temps de chargement du site Web est-il important ?

L'expérience utilisateur est l'un des facteurs les plus importants du succès des sites Web. Les temps de chargement sont la base d'une bonne expérience utilisateur car si le visiteur doit attendre (trop) longtemps qu'une page se charge, il sautera et cherchera une autre source.

Dans une étude, Google a découvert qu'une augmentation du temps de chargement d'une à trois secondes entraînait une augmentation de 32 % du taux de rebond . Si le temps de chargement passe à cinq secondes, la probabilité que le visiteur quitte la page augmente jusqu'à 90 %.

Comment les performances du site Web sont-elles mesurées ?

Il existe une variété d'outils et d'approches pour rendre l'expérience utilisateur sur les sites Web mesurable. Avec les Core Web Vitals, Google fournit trois chiffres clés standardisés et comparables. Ces éléments essentiels du Web deviendront également un facteur de classement l'année prochaine (2021), ils auront donc une influence directe sur la position d'une page dans les résultats de Google.

Nous avons déjà montré le contexte, les différentes méthodes de mesure et les moyens d'améliorer les trois principaux éléments vitaux du Web dans un autre article. Voici donc juste un petit rappel :

• Largest Contentful Paint (LCP) - le temps nécessaire au chargement de la plus grande section de contenu. Bon : moins de 2,5 secondes.
• Premier délai d'entrée (FID) - le temps jusqu'à ce que l'utilisateur puisse interagir avec la page. Bon : moins de 0,1 seconde.
• Décalage de mise en page cumulé (CLS) - Un indicateur de combien la mise en page se déplace pendant le chargement. Bon : inférieur à 0,1.

Dans cette analyse, nous avons utilisé la valeur de Largest Contenful Paint ( LCP ), à l'exception des premiers diagrammes qui montrent les trois mesures. Des trois Core Web Vitals, c'est la valeur élémentaire pour mesurer le temps de chargement de la page.

Royaume-Uni – 29 % des sites pas assez rapides

Pour la première étape, nous avons analysé les performances des accès aux sites Web depuis le Royaume-Uni pour les trois chiffres clés de Core Web Vitals . Google a défini trois domaines pour chacun :

• Bon (vert ) si la valeur est conforme aux attentes de Google,
• Besoin d'amélioration (jaune) s'il est au-dessus des attentes, mais pas encore trop éloigné de celles-ci et
• Mauvais (rouge) si la valeur mesurée est bien en dehors des cibles.

Sur cette base, voici les résultats pour le Royaume-Uni basés sur les trois Core Web Vitals.

Avec Largest Contentful Paint (LCP) , 70% de tous les résultats sont déjà bons. Google évalue 12,9 % des résultats comme mauvais. LCP est le chiffre clé des Core Web Vitals, car il reflète le plus directement le temps de chargement réel.

Le First Input Delay (FID ), c'est-à-dire le temps jusqu'à l'interaction, a les meilleures valeurs : 90% des accès sont déjà bons et seulement 2% sont notés comme mauvais par Google. Si vous avez encore du travail à faire ici, vous devrez vous dépêcher pour ne pas être laissé pour compte.

Avec Cumulative Layout Shift (CLS) , le changement de mise en page pendant le processus de chargement, on remarque que les sites Web réussissent ce test (vert) ou échouent complètement (rouge) - il n'y a que quelques cas où seule une amélioration est nécessaire. (Jaune).

Tendance positive : les sites Web deviennent un peu plus rapides chaque mois

Pour comprendre comment les temps de chargement ont changé au cours des derniers mois, la prochaine évaluation montre les changements mensuels pour la plus grande peinture de contenu au cours des derniers mois :

Les progrès ne sont pas rapides, mais il y a une légère tendance positive . Depuis novembre 2019, le nombre de mauvaises mesures a diminué d'environ 2 points de pourcentage et les bonnes mesures sont passées de 73 % à 75 %. La direction est positive : les sites Web deviennent un peu plus rapides chaque mois.

Les tablettes ne sont que de mauvais ordinateurs de bureau

Nous arrivons à l'analyse suivante où nous séparons l'évaluation selon le type d'appareil : ordinateur de bureau, téléphone mobile et tablette. Voici les résultats:

Sans surprise, les sites Web se chargent plus rapidement sur un ordinateur de bureau que sur un téléphone mobile. Une connexion internet souvent filaire et plus de puissance de calcul sont ici déterminantes. La différence entre les ordinateurs de bureau et les téléphones mobiles est cependant moindre que prévu .

La mauvaise performance des tablettes est intéressante. Une explication possible est que les tablettes voient généralement la version de bureau des sites Web à travers leur écran plus grand - mais le matériel des tablettes est plus comparable aux smartphones. Cela conduit à une performance de temps de chargement nettement inférieure.

20e place : l'accès au site Web depuis l'Angleterre doit être amélioré

Les valeurs mesurées par l'utilisateur final pour les Core Web Vitals ne dépendent que partiellement des performances du site Web : la vitesse, le débit et la latence de la connexion Internet des utilisateurs ont également une influence sur le résultat.

En tant qu'opérateur de site, il n'existe aucun moyen d'optimiser la connexion Internet de vos propres visiteurs, mais une analyse des Core Web Vitals pour chaque pays montre très clairement ces différences. Voici l'évaluation d'une sélection de pays :

En Chine et en Corée du Sud , 82 % de tous les sites Web correspondent aux attentes de performance de Google – une valeur supérieure et de loin le leader mondial. Viennent ensuite les pays nordiques (Suède, Norvège, Danemark) mais aussi le Japon et Taïwan.

L' Allemagne occupe la neuvième place dans cette analyse : les trois quarts de toutes les demandes des utilisateurs correspondent déjà aux attentes de vitesse de Google. L' Angleterre est positionnée au numéro 20, ce qui peut refléter la quantité de contenu consommé depuis l'extérieur du pays, notamment depuis les États-Unis, et peut-être depuis des services dans d'autres parties de l'Europe.

Les temps de chargement en Russie et aux États- Unis sont à peu près comparables. Les mauvaises valeurs de la Thaïlande et du Vietnam montrent que l'Asie ne peut pas toujours être assimilée à l'internet rapide.

Kiribati , une nation insulaire du Pacifique, démontre les effets d'un emplacement extrêmement éloigné et d'une connexion Internet par satellite : seulement environ un quart de tous les accès sont déjà bons. Près de 60% des accès sont classés comme mauvais par Google.

CMS : Jimdo le plus rapide, Wix encore plus lent que WordPress

Les systèmes de gestion de contenu ( CMS ) sont l'épine dorsale d'Internet : la plupart des sites Web sont exploités au-dessus du noyau de ces logiciels. Du coiffeur à côté de la PME au site avec plusieurs millions de visiteurs chaque jour.

Nous avons combiné notre base de données de technologies web avec les mesures des Core Web Vitals afin de pouvoir évaluer les vitesses de chargement des systèmes de gestion de contenu les plus utilisés. Passons directement à l'analyse :

Jimdo , le constructeur de sites Web de Hambourg, en Allemagne, offre les meilleures performances pour la plus grande peinture de contenu. Plus de 82 % des accès aux sites Web exécutés sur Jimdo répondent aux attentes de Google en matière de performances.

Typo3 montre que même un CMS auto-hébergé peut également offrir de très bonnes performances, comme le montre la deuxième place dans l'évaluation. Quiconque a déjà eu à développer avec Typo3 se souvient souvent de la complexité avec horreur. Cependant, cela n'affecte pas la vitesse de ce CMS basé sur PHP.

WordPress , de loin le CMS le plus répandu, est loin, loin derrière en avant-dernière position . Environ la moitié de tous les sites Web fonctionnent sur WordPress - mais il y en a aussi beaucoup qui l'utilisent qui accordent peu d'importance aux bons temps de chargement. Google classe environ 20 % des visites sur les sites Web basés sur WordPress comme mauvais et 21 % comme nécessitant des améliorations.

Le fait que WordPress ne porte pas la cuillère en bois dans cette analyse est dû au fournisseur du nom de Wix . Cette solution cloud ne fournit qu'environ la moitié de tous les accès avec un bon temps de chargement. Près d'un quart ont évalué les Core Web Vitals de Google comme mauvais .

Cette mauvaise performance est particulièrement remarquable si l'on considère que le gagnant de cette analyse (Jimdo) et le perdant (Wix) ont les mêmes conditions de départ : des solutions cloud dans lesquelles le fournisseur contrôle l'ensemble du système et peut optimiser chaque partie (mais évidemment ne ne le fais pas toujours).

Systèmes de boutique : Shopify au milieu du terrain, WooCommerce en bas

Dès 2006, Amazon a déterminé que des temps de chargement qui augmentaient de 0,1 seconde entraînaient une réduction de 1 % des ventes. Cela ne s'est pas amélioré au cours des 14 dernières années. De bons temps de chargement sont d'une importance fondamentale pour les boutiques en ligne.

La combinaison de notre base de données technologique et des données sur les temps de chargement aboutit à l'analyse suivante pour tous les systèmes de boutique que nous avons vus assez souvent dans la nature sauvage d'Internet :

Le gagnant, Lightspeed , porte bien son nom. Les domaines utilisant Lightspeed contribuent à la note "bonne" de 93 % pour la plus grande peinture de contenu. Seuls 2 % sont jugés mauvais. Ce sont les meilleurs chiffres que nous avons mesurés dans cette analyse dans toutes les évaluations.

Lightspeed a l'avantage lié au système qu'il s'agit d'une solution cloud. Le fournisseur contrôle l'ensemble du système et peut optimiser toutes les zones pour la vitesse. La solution open source osCommerce montre que de très bons temps de chargement peuvent également être atteints avec des boutiques auto-hébergées avec un très bon 84 %.

L'étoile filante actuelle Shopify n'arrive que dans la moitié inférieure de l'analyse. Bien qu'il utilise en principe la même architecture de base que Lightspeed (entièrement hébergée par le fournisseur lui-même), cet avantage ne se traduit pas par des temps de chargement supérieurs à la moyenne.

L'extension WordPress WooCommerce est loin derrière à la dernière place. Un peu moins de la moitié des boutiques WooCommerce répondent actuellement aux spécifications de Google. Un pourcentage alarmant de 26 % sont en fait mauvais . La solution d'hébergement autonome avec des fournisseurs de masse peu performants est claire ici.

Technologies Web : AMP plus lent que prévu

Cette évaluation traite d'une grande variété de technologies Web : des technologies backend pour la création de sites Web aux bibliothèques JavaScript et CSS pour la conception et l'interaction en passant par Google AMP .

Le tableau suivant répertorie uniquement les technologies dont les usages sont les plus identifiés dans nos données. Les technologies Web moins utilisées ont été laissées de côté. Bien sûr, seuls les sites Web accessibles au public pourraient être évalués. Voici l'analyse :

Ruby on Rails , un framework basé sur Ruby développé par le fondateur de Basecamp, est de loin le leader : près de 85% de tous les sites Web dotés de cette technologie délivrent des sites Web dans les limites fixées par Google pour une bonne note du plus grand Contentful Paint.

Mais les frameworks PHP comme Yii (74%) ou Laravel (73%) offrent également de bons moments. Pour que personne ne se sente en reste : Python est également bien représenté avec le framework Django (75%) et ASP.NET (77%) prend même la deuxième place. Qu'apprenons-nous de cela ? La vitesse ne dépend pas du langage de programmation, mais de l'implémentation.

Il est à noter que l' AMP n'est pas l'une des technologies les plus rapides. Les Accelerated Mobile Pages (AMP) sont un dérivé du HTML principalement poussé par Google. De nombreuses restrictions devraient signifier que les pages AMP se chargent beaucoup plus rapidement sur le téléphone mobile que les pages HTML classiques.

Les résultats ne sont pas probants : moins de 70% des domaines AMP répondent aux exigences de Google. Google l'a apparemment déjà reconnu et léguera également à l'avenir les privilèges AMP dans la boîte Top Stories aux sites qui ont des Core Web Vitals rapides.

AMP ne sera plus nécessaire pour que les histoires soient présentées dans Top Stories sur mobile ; il sera ouvert à n'importe quelle page .

Blog Google Webmaster Central, Évaluer l'expérience de la page pour un meilleur Web

La seule technologie Web qui ne parvient pas à faire en sorte que plus de la moitié de tous les domaines répondent aux exigences de Google est Angular . Ironie du sort, un framework pour applications front-end développé et fourni par Google…

CDN. Les sites rapides utilisent Fastly

Les réseaux de diffusion de contenu (CDN) fournissent des serveurs répartis dans le monde entier afin que le contenu puisse couvrir des chemins de transmission plus courts et donc plus rapides vers le visiteur du site. Outre des spécialistes comme Akamai, les principaux fournisseurs de cloud proposent également des CDN.

Essentiellement, tous les CDN fonctionnent de la même manière. Ils ne peuvent pas non plus modifier les limites physiques de leur architecture. Ainsi, dans l'analyse qui suit, il convient de distinguer entre causalité et corrélation :

On ne peut pas supposer que les CDN plus rapides sont la cause du lead, mais que les opérateurs de sites Web axés sur les performances peuvent se rabattre sur ces CDN.

Les domaines qui s'appuient sur Fastly en tant que CDN se chargent, en moyenne, beaucoup plus rapidement que ceux qui s'appuient sur d'autres fournisseurs. Google arrive en deuxième position, mais Amazon et Microsoft (Azure) ne sont pas loin non plus.

Le fait qu'Akamai se trouve plus loin derrière pourrait avoir quelque chose à voir avec les clients typiques d'Akamai : ce sont des sociétés internationales plutôt grandes qui exploitent souvent des systèmes hérités lents - ce qui n'est pas la meilleure condition préalable pour fournir des sites Web modernes et rapides.

Fireblade , en bas de cette analyse, ne propose pas un CDN classique, mais un pare-feu applicatif web : l'application filtre le trafic Internet des appels potentiellement dangereux et les bloque. Ceux qui doivent se rabattre sur une telle architecture exploitent en moyenne également des applications Web plus anciennes et non optimisées et présentent donc déjà des inconvénients structurels dans cette évaluation.

Contexte : ce que (et comment) nous avons mesuré

La mesure des vitesses de chargement a une longue histoire : de la mesure originale du début de la livraison du HTML pur ( TTFB , Time to first Byte) au First Contentful Paint jusqu'aux trois valeurs mesurées actuelles des Core Web Vitals avec la plus grande peinture de contenu comme métrique centrale a beaucoup changé.

Pour l'analyse, nous avons utilisé la base de calcul officielle des Google Core Web Vitals. Il existe essentiellement deux méthodes de mesure différentes pour cela : les données de laboratoire , c'est-à-dire les valeurs mesurées par vous-même dans vos propres conditions de laboratoire et les données de terrain . Ceux-ci sont mesurés par un panel d'utilisateurs. Nous avons évalué les données de terrain pour cette analyse. Dans SISTRIX, vous pouvez accéder aux données de laboratoire et de terrain. Au total, nous avons analysé les temps de chargement de 18,5 millions de domaines.

À l'exception des trois premières évaluations, qui concernent exclusivement des valeurs mesurées du Royaume-Uni, les analyses restantes incluent des valeurs mesurées du monde entier. Les valeurs des ordinateurs de bureau, mobiles et tablettes y sont également évaluées.

Nous avons combiné ces valeurs mesurées avec la détection de technologie dans SISTRIX afin de pouvoir faire des déclarations sur les solutions logicielles et les piles technologiques. Pour la reconnaissance de la technologie, nous explorons régulièrement de grandes parties d'Internet et comparons les fonctionnalités trouvées ("empreintes digitales") avec notre liste de plus de 1 000 technologies Internet pertinentes. Nous n'avons inclus dans l'analyse finale que les combinaisons technologie-cœur-web-vitales qui se produisent avec un nombre suffisant de domaines pour atteindre une signification statistique.

Conclusion

Google met l'expérience utilisateur sous les projecteurs en faisant de Core Web Vitals un facteur de classement officiel. Dans notre analyse, nous avons pu montrer à quel point la fourchette des valeurs est actuellement large . Selon le logiciel et la technologie utilisés, tout est représenté entre « déjà parfait » et « un tas de travail ».

Comme tant d'autres en SEO, l'amélioration des temps de chargement doit être un processus continu . Ce n'est pas une tâche ponctuelle, mais un processus continu et surveillé. Cela nécessitera une attention régulière et les objectifs devront être ajustés de temps à autre.

L'optimisation des temps de chargement n'est pas une tâche SEO essentielle - et pourtant, le changement aura un impact sur les performances organiques d'un site Web dans les résultats de recherche. Le SEO est encore une fois une fonction transversale qui doit fédérer de nombreux domaines d'une entreprise.

Nous-mêmes avons longtemps négligé les temps de chargement de notre site Web. Depuis quelques semaines nous nous sommes attaqués au sujet et avons constaté combien d'efforts demandent de (très) bonnes valeurs. Et pourtant ça vaut le coup : non seulement Google en est content, mais les vrais utilisateurs en particulier nous en remercient. Par conséquent : ne dormez pas sur le sujet . Il vaut mieux commencer cette année que de la reporter à l'année prochaine.