Johannes Beus

(Auteur)

Publié le : 17.09.2020

• Retour à la vue d'ensemble

La vitesse de chargement des sites web sera un facteur de référencement en SERP officiel de Google l’année prochaine et comme le processus d’optimisation n’est pas simple, vous devriez commencer à vous y mettre dès maintenant.

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

Résumé des principales conclusions sur la vitesse de lecture des pages

• 30% des temps de chargement en France ne sont pas acceptables, selon les attentes de Google : ils sont supérieurs au maximum de 2,5 secondes.
• La tendance, cependant, stagne. La proportion de sites web rapides a augmenté de 0,8% au cours des derniers mois.
• L’accès aux sites web en France n’est pas aussi rapide qu’il pourrait l’être. Les pays européens les plus rapides sont la Suisse, la Suède, la Norvège et l’Allemagne.
• Jimdo montre que les CMS basés sur le cloud peuvent offrir de très bonnes valeurs concernant les Core Web Vitals. Mais les solutions Open Source peuvent également y parvenir – seul Typo3 est un peu plus lent.
• Aucun CMS n’est plus lent que Wix : la lanterne rouge de la catégorie des CMS, même derrière WordPress, montre de façon impressionnante que le cloud n’est pas rapide par lui-même.
• Lightspeed offre un système de boutique extrêmement rapide. Shopify n’est que dans la moitié inférieure de la liste. Le module complémentaire de 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 cadres de travail rapides en Ruby (on Rails), PHP (Yii & Laravel), Python (Django) et d’autres langages. Seul Angular est vraiment lent.
• L’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 conclusions intéressantes sur les temps de chargement, les systèmes rapides et lents et les connexions qui se cachent derrière.

Pourquoi le temps de chargement d’un site web est-il important ?

L’expérience de l’utilisateur (le fameux UX) est l’un des facteurs les plus importants permettant le succès des sites web. Le temps de chargement est la base d’une bonne expérience utilisateur car si le visiteur doit attendre (trop) longtemps le chargement d’une page, il la sautera et en cherchera une autre.

Dans une étude, Google a constaté qu’une augmentation du temps de chargement de une à trois secondes entraîne 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 la performance des sites web est-elle mesurée ?

Il existe toute une série d’outils et d’approches pour rendre mesurable l’expérience de l’utilisateur sur les sites web. Avec les « Core Web Vitals », Google fournit trois chiffres clés normalisés et comparables. Ces « Core Web Vitals » deviendront également un facteur de classement en SERP 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é dans un autre article le contexte, les différentes méthodes de mesure et les moyens d’améliorer les trois Core web Vitals. Voici donc 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.
• First Input Delay (FID) – le temps avant que l’utilisateur puisse interagir avec la page. Bon : moins de 0,1 seconde.
• Cumulative Layout Shift (CLS) – Indicateur de l’ampleur du décalage de la mise en page pendant le chargement. Bon : moins de 0,1.

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

France : 30% des sites ne sont pas assez rapides

Pour la première étape, nous avons analysé les performances des accès aux sites web à partir, ici dans le cas de la France pour les trois chiffres clés de Core Web Vitals. Google a défini trois domaines pour chacun d’entre eux :

• Bon (vert) si la valeur est conforme aux attentes de Google,
• A améliorer (jaune) si elle est supérieure aux attentes, mais ne s’en écarte pas encore trop et
• Mauvais (rouge) si la valeur mesurée est bien en dehors des objectifs.

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

Avec la plus Largest Contentful Paint (LCP), 70 % des résultats sont déjà bons. Google estime que 13,73 % des résultats sont mauvais. LCP est le KPI vraiement clé du 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 avant l’interaction, montre de meilleures chiffres : 88 % des accès sont déjà bons et seulement 2 % sont considéré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 le Cumulative Layout Shift (CLS), durant le décalage de chargement des éléments de mise en page pendant le processus, on remarque que les sites web réussissent guère mieux ce test (vert)que le LCP ou bien l’échouent complètement (rouge) – il n’y a que quelques cas où seule une amélioration est nécessaire 4% (jaune).

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

Pour comprendre comment ont changé les temps de chargement au cours des derniers mois, nous montrons les changements mensuels du Largest Contentful Paintla 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 ont légèrement diminué d’environ 1,5 points de pourcentage (15,18% à 13,73%) et les bonnes mesures ont à peine augmenté de 69,16% à 69,34%. La direction est à peine positive : les sites web ne deviennent qu’à peine 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 portable et tablette. Voici les résultats :

Il n’est pas surprenant que les sites web se chargent plus rapidement sur un ordinateur de bureau que sur un téléphone portable. Une connexion Internet souvent filaire et une puissance de calcul plus importante sont ici décisives. La différence entre un ordinateur de bureau et un téléphone portable est cependant moins importante que prévu.

La faible 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 contenu dans les tablettes est plus comparable à celui des smartphones. Cela se traduit par un temps de chargement nettement moins performant.

23ème place : L’accès aux sites webs depuis la France 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’y a pas moyen d’optimiser la connexion Internet de ses 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 répondent aux attentes de Google en matière de performances – une valeur de premier ordre et de loin les leaders mondiaux. 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 des demandes des utilisateurs correspondent déjà aux attentes de Google en matière de vitesse. L’Angleterre se situe à la 20e place, ce qui peut refléter la quantité de contenu consommé en dehors du pays, notamment aux États-Unis, et peut-être à partir de services situés 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 pour la Thaïlande et le 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’une situation extrêmement éloignée et d’une connexion à l’internet par satellite : seul un quart environ de tous les accès sont déjà bons. Près de 60 % des accès sont jugés 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 de l’internet : la plupart des sites web sont exploités sur la base de ces logiciels. Du salon de coiffure d’à côté à la PME en passant par le site avec plusieurs millions de visiteurs chaque jour.

Nous avons combiné notre base de données sur les technologies du web avec les mesures du 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 créateur de sites web de Hambourg, en Allemagne, offre la meilleure performance pour le KPI de Largest Contentful Paint. Plus de 82% des accès aux sites web fonctionnant 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 fournir de très bonnes performances, comme le montre la deuxième place de 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, très loin en avant dernière position. Environ la moitié des sites web fonctionnent sous WordPress – mais nombreux sont ceux qui l’utilisent et qui accordent peu d’importance à un bon temps de chargement. Google classe environ 20 % des visites de sites web basés sur WordPress comme mauvaises, et 21 % comme devant être améliorées.

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 de cloud computing ne fournit qu’environ la moitié des accès avec un bon temps de chargement. Près d’un quart des critères de Site Core Web Vitals établit par Google était 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 en optimiser chaque partie (mais ne le fait évidemment pas toujours).

CMS pour magasins en ligne : Shopify au milieu du classement, WooCommerce en fond

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. Cette situation ne s’est pas améliorée 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 technologiques et des données sur les temps de chargement donne lieu à l’analyse suivante pour tous les systèmes de boutiques que nous avons assez souvent vus dans le désert ouvert de l’internet :

Le gagnant, Lightspeed, est à la hauteur de son nom. Les domaines qui utilisent Lightspeed contribuent à la « bonne » note de 93 % sur le Largest Contentful Paint. Seuls 2 % sont considérés comme mauvais. Ce sont les meilleurs chiffres que nous avons mesurés dans cette analyse, toutes évaluations confondues.

Lightspeed présente l’avantage, lié au système, d’être une solution de cloud computing. Le fournisseur contrôle l’ensemble du système et peut optimiser la vitesse de tous les domaines. La solution open source osCommerce montre que de très bons temps de chargement qui peuvent également être obtenus grâce à des boutiques auto-hébergées atteignant un très bon 84%.

L’actuelle étoile montante Shopify n’entre 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é par le fournisseur lui-même), cet avantage n’est pas converti en 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 % est en fait mauvais. La solution d’hébergement autogérée avec des fournisseurs de masse peu performants est claire ici.

Web technologies: AMP plus lent qu’attendu

Cette évaluation porte sur une grande variété de technologies web : des technologies de base pour la création de sites web aux bibliothèques JavaScript et CSS pour la conception et l’interaction, en passant par l’AMP de Google.

Le tableau suivant n’énumère que les technologies dont les utilisations les plus identifiées figurent dans nos données. Les technologies web moins utilisées ont été laissées de côté. Bien entendu, seuls les sites web accessibles au public ont pu être évalués. Voici l’analyse :

Ruby on Rails, un framework basé sur Ruby et développé par le fondateur de Basecamp, est de loin le leader : près de 85% des sites web utilisant cette technologie livrent des sites dans les limites fixées par Google pour une bonne note sur le critère Largest Contentful Paint.

Mais les frameworks PHP comme Yii (74 %) ou Laravel (73 %) offrent également de bons résultats. Pour que personne ne se sente exclu : Python est également bien représenté avec le framework Django (75 %) et ASP.NET (77 %) arrive même en deuxième position. Qu’est-ce que cela nous apprend ? La rapidité ne dépend pas du langage de programmation, mais de l’implémentation.

Il est à noter que l’AMP n’est pas une des technologies les plus rapides. Les pages mobiles accélérées (AMP) sont un dérivé du HTML principalement poussé par Google. De nombreuses restrictions devraient faire que les pages AMP se chargent beaucoup plus rapidement sur le téléphone portable que les pages HTML classiques.

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

L’AMP ne sera plus nécessaire pour que les histoires soient présentées dans Top Stories sur mobile ; elle sera ouverte à toutes les pages.

Google Webmaster Central Blog, Evaluating page experience for a better web

La seule technologie web qui ne parvient pas à faire en sorte que plus de la moitié des domaines répondent aux exigences de Google est Angular. Ironiquement, un framework pour les applications frontales développé et fourni par Google …

CDN : Les sites rapides utilisent Fastly

Les réseaux de diffusion de contenu ou Content Delivery Networks (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 pour le visiteur du site. Outre des spécialistes comme Akamai, les principaux fournisseurs de services dans le Cloud proposent également des CDN.

En substance, tous les CDN fonctionnent de manière similaire. Ils ne peuvent pas non plus modifier les limites physiques de leur architecture. Par conséquent, dans l’analyse qui suit, il convient de faire une distinction entre la causalité et la corrélation :

On ne peut pas supposer que les CDN plus rapides sont la raison de l’avantage obtenu, mais qu’on remarque que les opérateurs de sites web axés sur ces CDN ont les performances suivantes :

Les domaines qui s’appuient sur Fastly comme 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 derrière non plus.

Le fait qu’Akamai se trouve plus loin derrière pourrait avoir un rapport avec les clients typiques d’Akamai : il s’agit de grandes entreprises internationales qui exploitent souvent des systèmes lents et hérités – ce qui n’est pas la meilleure condition préalable à la diffusion de sites web modernes et rapides.

Fireblade, au bas de cette analyse, n’offre pas un CDN classique, mais un pare-feu d’application web : l’application filtre le trafic Internet pour les appels potentiellement dangereux et les bloque. Ceux qui doivent se rabattre sur une telle architecture exploiteront également, en moyenne, 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 nous avons mesuré (et comment)

La mesure des vitesses de chargement a une longue histoire : de la mesure initiale du début de la livraison du HTML pur (TTFB, Time to first Byte) à jusqu’au First Contentful Paint, en passant par les trois valeurs mesurées actuelles du Core Web Vitals avec Largest Contentful Paint comme métrique centrale, la mesure a beaucoup changé.

Pour l’analyse, nous avons utilisé la base de calcul officielle de Google Core Web Vitals. Pour cela, il existe essentiellement deux méthodes de mesure différentes : 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. Celles-ci sont mesurées par un panel d’utilisateurs. Pour cette analyse, nous avons évalué les données de terrain. Dans SISTRIX, vous pouvez accéder à la fois aux données de laboratoire et aux données 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 portent exclusivement sur des valeurs mesurées en France, les autres analyses comprennent des valeurs mesurées dans le monde entier. Les valeurs des ordinateurs de bureau, des téléphones portables et des tablettes y sont également évaluées.

Nous avons combiné ces valeurs mesurées avec la détection de la technologie dans SISTRIX afin de pouvoir faire des déclarations sur les solutions logicielles et technologiques. Pour la reconnaissance des technologies, nous parcourons régulièrement de grandes parties de l’Internet et comparons les caractéristiques trouvées (« empreintes digitales » ou « fingerprints ») avec notre liste de plus de 1 000 technologies Internet pertinentes. Nous n’avons inclus dans l’analyse finale que les combinaisons de technologie et de Core Web Vitals qui se produisent avec un nombre suffisant de domaines pour obtenir une signification statistique.

Conclusion

Google met l’expérience utilisateur sous les projecteurs en faisant de Core Web Vitals un critère de référencement officiel en SERP. Dans notre analyse, nous avons pu montrer l’étendue de l’éventail des valeurs actuelles. Selon le logiciel et la technologie utilisés, tout est représenté entre « déjà parfait » et « énormément de travail ».

Comme dans le cas du SEO classique, l’amélioration des temps de chargement doit être un processus continu. Il ne s’agit pas d’une tâche ponctuelle, mais d’un processus continu et contrôlé. Il faudra lui accorder une attention régulière et les objectifs devront être ajustés de temps en temps.

L’optimisation des temps de chargement n’est pas une tâche essentielle en matière de référencement – et pourtant le changement aura un impact sur la performance organique d’un site web dans les résultats de recherche. Le référencement est une fois de plus une fonction transversale qui doit rassembler de nombreux domaines d’une entreprise.

Nous avons nous-mêmes négligé les temps de chargement de notre site web pendant longtemps. Ces dernières semaines, nous avons abordé le sujet et nous avons remarqué combien d’efforts il est nécessaire pour obtenir de (très) bonnes valeurs. Et pourtant, cela en vaut la peine : non seulement Google en est satisfait, mais les véritables utilisateurs nous en remercient. Par conséquent : ne vous endormez pas sur le sujet. Il vaut mieux commencer cette année que de le reporter à l’année prochaine.