Avec tous les outils d’évaluation de la vitesse de chargement et avec les Core Web Vitals de Google, nous avons tous la certitude qu’un site web doit charger rapidement pour bien performer en SEO. Mais est-ce vraiment le cas?
La réponse est que ça dépend de ce qu’on entend par vitesse et on doit s’entendre sur une unité de mesure la plus précise possible.
Quelle est la philosophie à adopter pour analyser la relation entre la vitesse de chargement d’un site web et les résultats SEO?
La réponse à cette question par rapport à la vitesse du site web semble évidente mais chez SEO Espion, nous avons comme philosophie que le SEO sans data, ce ne sont que des croyances ou des opinions. Alors pour répondre à cette importante question, il a fallut:
- Vérifier et/ou clarifier certains concepts par rapport à la vitesse de chargement du contenu d’une page de site web.
- Réfléchir à certains concepts par rapport à la vitesse de chargement d’une page de site web en se posant des questions à savoir si la réponse est logique.
- Faire des tests ou s’appuyer sur les tests de certains collègues SEO par rapport à la relation entre la vitesse de chargement d’un site internet et les résultats naturels de référencement sur Google.
Pourquoi est-ce que Google a introduit les Core Web Vitals par rapport à la vitesse de chargement de son site web?
En 2021, Google a lancé les “Core Web Vitals” qui pourraient être traduits par le terme “Signaux Web Essentiels” qui sont 3 aspects d’un outil qui sert à évaluer la performance d’un site web au niveau de sa vitesse de chargement et donc de l’expérience sur la page.
En quoi consiste exactement l’outil des Core Web Vitals et qu’est-ce que chacun des 3 éléments évaluent par rapport à la vitesse du site web?
Le LCP ou “Largest Contentful Paint”
Le premier élément est le LCP pour « Largest Contentful Paint ». Le LCP, c’est une approximation du temps que ça prend pour que les éléments HTML les plus importants de la page apparaissent à l’écran. C’est donc une estimation de la vitesse de chargement basée sur le rendu ou l’apparition des éléments principaux d’une page.
Le problème avec le LCP est que ça dépend de l’équipement de la personne qui visite votre site web et ça va être influencé par des aspects comme :
- La vitesse des CPU ou (Central Processing Unit qui est le cerveau de l’ordinateur)
- La quantité de CPU disponibles
- La mémoire disponible
- La resolution d’affichage
- La quantité de processeurs
- La vitesse de la connection internet
- Etc.
Le LCP va donc énormément varier d’un visiteur à l’autre. Est-ce que Google va mesurer et évaluer quelque chose qui dépend autant de l’équipement des visiteurs pour évaluer la vitesse du site web et même s’en servir pour décider de son référencement naturel? C’est une question légitime à se poser!
Google utilise peut-être des scores de vitesse de chargement pour les pages à savoir lesquelles ressortent le plus rapidement possible pour certains types d’équipement.
Une chose est certaine, Google classifie les sites web dans ses résultats de recherche en fonction de la pertinence des résultats?
Est-ce que la personne qui utilise son vieux cellulaire à l’abri d’autobus fait des recherches moins pertinentes sur Google que la personne qui est sur son ordinateur hyper performant avec une connexion internet très rapide? La réponse est évidente: NON!
Le FID ou “First Input Delay”
Le deuxième élément des Core Web Vitals est le FID pour « First Input Delay ». Le FID permet de mesurer l’interactivité. Le FID permet de mesurer le temps que ça prend pour que le site web réagisse à une action du visiteur comme cliquer sur un lien ou sur un bouton.
C’est super parce qu’on sait que l’attente est plate et que d’améliorer la vitesse va faire en sorte que l’expérience de l’utilisateur va être meilleure.
Par contre, jusqu’où on va avec ce concept?
Par exemple, si j’ai envie d’avoir un beau site web avec des éléments cliquables qui sont beaux et attrayant, je vais probablement avoir besoin de Javascript et c’est plus long à charger qu’un lien qui est fait avec un texte d’ancrage.
Il y a donc un optimum à avoir sur ce point et non une vitesse maximale de chargement pour avoir la meilleure performance possible.
Le CLS ou « Cumulative Layout Shift »
Le troisième élément des Core Web Vitals est le CLS pour « Cumulative Layout Shift ». Cet élément mesure la stabilité du visuel.
Par exemple, si je charge une page et que je commence à lire, est-ce que le visuel va changer en plein milieu de ma lecture parce qu’une image ou un vidéo vient de charger? Les probabilités que ça arrive pendant que j’ai commencé ma lecture sont faibles sur un ordinateur puissant qui a une connexion internet rapide mais avec un vieux cellulaire pendant que je suis à l’arrêt d’autobus, sur une connexion 4G, il y a plus de chances que ça arrive.
Est-ce que c’est pertinent de s’attarder sur le score des Core Web Vitals pour évaluer la vitesse de chargement de son site web pour son référencement naturel (SEO)?
Maintenant qu’on a une meilleure idée de ce que sont les Web Core Vitals, c’est le temps de se poser des questions sur leur importance. Google les a appelé les Core Web Vitals et le nom indique que c’est prioritaire, c’est même vital.
C’est certain que d’améliorer la performance de ces éléments (pour ce qu’on peut améliorer parce qu’on ne contrôle pas le contexte des visiteurs soit : leur équipement et leur vitesse de connexion) mais d’améliorer ce qu’on contrôle est bon pour l’expérience client.
Maintenant, Google affirme que les Core Web Vitals sont un facteur de classification.
Est-ce que c’est vrai ou est-ce que c’est faux?
Dernièrement, des collègues ont fait des tests. Ils ont testé les résultats de recherche pour une vingtaine de mots clés et ils ont regardé les résultats.
Ils ont ensuite évalué le score des Core Web Vitals des 20 premiers résultats de recherches pour les 20 recherches. Ils ont donc évalué 400 résultats.
Ils ont ensuite fait des corrélations entre les résultats sur Google et les résultats des Core Web Vitals pour voir si on pouvait voir une pente observable pour trouver des corrélations.
Le résultat a été que pour les 20 mots clés différents, il y a eu des nuages de points aléatoires…La réalité est donc que pour le moment, les Core Web Vitals ne sont pas un facteur de classification pour Google.
Si les Core Web Vitals ne sont pas importants (pour le moment) en SEO, est-ce que la vitesse de chargement d’un site web est importante pour le SEO?
Donc, les Core Web Vitals ne sont pas utilisés par Google pour le SEO.
Par contre, Google vérifie si votre site web charge assez rapidement et ce, non pas pour l’expérience utilisateur (UX), qui nécessiterait une vitesse de chargement plus rapide, mais bien pour améliorer son efficacité à parcourir le web pour l’indexer et le servir pour certaines requêtes (mots-clés).
En fait, on a constaté que Google utilise une technologie beaucoup plus simple et beaucoup moins dispendieuse pour vérifier si votre site web a une vitesse de chargement assez rapide.
En fait, ce que Google fait est qu’il va aller sur une page de votre site web et il va ressortir dans son index la version qu’il va avoir après avoir parcouru la page pendant 4 ou 5 secondes, ça dépend des pages
Donc, si votre page prend plus que 4 secondes à charger comme c’est parfois le cas pour certaines pages qui contiennent du Javascript (où le bas de la page n’est pas encore chargé après 4 secondes), eh bien Google ne prendra pas en considération ce contenu. Cette situation risque d’affecter négativement le SEO.
Donc quand une personne vous dit que Google n’aime pas le Javascript, c’est probablement ce qui se passe.
Avant, Google restait plus longtemps sur chacune des pages mais avec l’expansion de l’internet, il reste pendant 4 à 5 secondes maximum pour pouvoir parcourir plus de sites web plus rapidement pour suivre l’expansion accélérée du web dû notmmament à des outils de rédaction par l’intelligence artificielle.
Voulez-vous plutôt écouter la version podcast de cet article sur la vitesse de chargement du site web par rapport au SEO?
Voici l’épisode 121 de mon podcast Commerce électronique & actifs numériques qui traite de la vitesse de chargement du site web et qui partage la même information que le texte du haut. Cet épisode de podcast n’explique pas comment on a réussit à trouver la réponse de la vitesse minimale de chargement d’une page de site web pour le SEO mais pour le savoir, vous pouvez lire le reste de l’article.
Comment est-ce qu’on a espionné Google pour connaître la vitesse minimum de chargement d’une page de site web pour le SEO?
Si vous regardez la balise de titre du site web de SEO Espion, vous verrez qu’il y a un chronomètre qui compte la durée en secondes dans les parenthèses. Eh bien, si vous allez dans la barre de recherche de Google et que vous tapez site:seoespion.com
Vous remarquerez ceci:
Qu’est-ce que ce test nous prouve à propos de la vitesse de chargement des pages d’un site web pour le référencement naturel (SEO) seulement?
Avec les chiffres 5 et 4 dans la parenthèse, ce test nous prouve que Google utilise la version de la page qui est chargée après 5 secondes ou après 4 secondes. Pour le SEO seulement, votre site web devrait se charger avant 4 secondes. Pour l’expérience utilisateur, ça devrait évidemment être une vitesse de chargement encore plus rapide.
Est-ce que la vitesse minimale de chargement d’une page de site web pour le SEO va diminuer éventuellement?
De par le fait que l’expansion du web et donc le nombre de sites web et de pages s’accélère dû à l’intelligence artificielle qui aide à créer du contenu et que Google doit couvrir l’univers du web, on croit que la durée passée sur chacun des sites web et même sur chacune des pages va diminuer et donc, la vitesse de chargement va devoir s’accélérer. On recommande aussi une vitesse de chargement beaucoup plus rapide pour le UX.
Si on doit accélérer la vitesse de chargement des pages de son site web pour le SEO et le UX, quelle approche choisir pour le faire?
Certaines personnes vont décider d’optimiser la vitesse de chargement de leur site web par comme but d’améliorer le “time to first impression”. C’est une excellente idée de le faire parce que la psychologie indique que les humains vont accepter un site web qui charge à une vitesse où ça prend de 0 à 4 secondes. C’est probablement pourquoi Google indexe la version 4 ou 5 secondes d’une page de site web dans ses résultats de recherche. Idéalement, une page de site web va se charger en moins d’une seconde.
Pourquoi optimiser la vitesse de chargement des pages d’un site web seulement pour la première impression est une erreur faite par certains sites web?
Par contre, si l’optimisation de la vitesse de chargement est faite pour la première impression, cette optimisation de la vitesse de chargement doit aussi se faire au niveau de la navigation complète.
Sinon, le site web aura une vitesse de chargement très rapide pour la première impression mais si l’internaute continue sa navigation sur le site web et que le reste est lent, c’est une expérience d’utilisateur qui peut être frustrante. Donc, optmiser la vitesse de chargement pour la première impression seulement est une erreur sauf si on prévoit que les gens vont seulement consulter une page et repartir. C’est rarement le cas!
Quelle serait une meilleure solution pour optimiser la vitesse de chargement de son site web?
C’est ok d’optimiser la vitesse de chargement pour la première impression mais si vous prévoyez que vos internautes vont naviguer sur plusieurs pages, optimiser la vitesse de chargement des pages de votre site web par la cache sera beaucoup mieux pour l’expérience utilisateur. Donc, une meilleure solution serait d’optimiser pour les deux et si vous devez en choisir une seule, allez-y pour la cache. Évidemment, votre site web devrait charger ses pages dans une durée la plus rapide possible et cette vitesse de chargement dépend en grande partie de la manière que vos pages de sites web ont été bâties. Certains thèmes ou “page builers” ralentissent beaucoup la vitesse de chargement alors il faut choisir méticuleusement son thème ou son “site builder”. Une ressource gratuite pour avoir une idée de la vitesse de chargement de son site web est d’utiliser l’outil GT Metrix.
0 Comments