La webperf fait partie des sujets à la mode dans les conférences SEO et marketing. Pour cause : c’est l’un des leviers qui est entièrement administrables en interne et qui impacte en grande majorité les équipes de développements. Elle peut donc être facilement mise en place au sein d’un projet cadré, structuré et mesuré. C’est la partie du SEO qui est aujourd’hui la moins sujette à interprétation.
Mais est-ce que c’est vraiment efficace la webperf pour le SEO ?
Est-ce qu’améliorer mon temps de chargement va me permettre de gagner des places sur Google ?
Contrairement à ce qui vous a été dit depuis plusieurs mois, années, décennies ? (non là j’en fait trop.) La webperf n’a clairement pas un gros impact sur le SEO. Bon, forcément, c’est un peu facile dis comme ça, je vais donc étayer mon propos.
Tout d’abord, de quelle webperf parle-t-on ? Il est certain que si l’on parle d’un site qui met 20 secondes avant d’afficher la première image, là il y a un sujet, un sujet bloquant même, qu’il va falloir optimiser. Mais soyons clair, si le sujet de la webperformance vous préoccupe, ce sujet bloquant n’est clairement pas le cas de votre site, ni d’ailleurs de 90% des sites Internet réalisés par une équipe de développeurs compétents.
De notre point de vue, nous comparons souvent la webperf et le SEO technique à un frein à main. S’il est enclenché, on le fait sauter ; en revanche, inutile d’accrocher des ailerons sur une voiture qui n’a qu’un petit moteur, on n’en fera pas un avion de chasse !
Que regarde réellement Google en termes de temps d’affichage ?
Pour nous, la webperformance intervient à deux niveaux dans l’analyse de Google. Deux, pas plus. Inutile d’aller chercher plus loin des audits à des prix mirobolants ! Pour bien les comprendre, il faut se rappeler deux points très importants liés à Google : le moteur de recherche naturel lui coûte de l’argent, et il veut satisfaire un maximum d’utilisateurs.
Le temps de chargement du HTML brut : TTFB
Le TTFB (Time To First Byte) est l’un des deux indicateurs importants pour le SEO. Quand Google vient voir votre site web, il ne télécharge pas systématiquement l’intégralité des ressources de la page, médias images, vidéos, javascript, feuille de style, police d’écriture, audio, pdf etc. Non, la plupart du temps, il se contente de récupérer le HTML brut, c’est l’un des point que l’on découvre lorsque l’on fait de l’analyse de logs en SEO. En effet, il s’agit ici du temps de téléchargement du texte analysable de la page. On est clairement, ici, sur le souhait de Google de bien comprendre le contenu et l’objectif de la page au sens sémantique du terme. Il en profitera également pour analyser les liens vers d’autres pages (internes ou externes). C’est entre autre pour cela qu’un site en JavaScript qui ne propose pas de rendu HTML (server side rendering) dès le premier chargement de la page ne sera d’aucune efficacité en SEO.
Cet aspect nous rappelle quelques points importants pour votre SEO :
- Avoir du texte en HTML dans la page (pas dans des images)
- Le contenu ajouté en JavaScript a posteriori ne sert à rien
On touche ici au temps que Google met pour télécharger le contenu (texte) de la page. L’équation est simple :
« Plus Google peut récupérer le contenu de votre site rapidement, moins il perd de temps et donc d’argent »
Comment optimiser concrètement le TTFB de votre site Internet ?
Cet indicateur peut être optimisé de quatre manières différentes :
- Avoir un hébergement proche de vos internautes (on parle ici de réduire le temps réseau entre le visiteur et l’hébergement) ;
- Avoir un hébergement plus rapide : plus vite l’hébergement fait les calculs nécessaires à l’affichage du site, mieux c’est ;
- Avoir un système de cache performant : tous les calculs ne sont pas forcément à réaliser à chaque chargement, un système de cache permet de servir un contenu identique plusieurs fois sans refaire de calcul. Par exemple, sur un site e-commerce il est fort probable que la liste des produits d’une catégorie évolue peu durant plusieurs heures ;
- Coder proprement : si vous testez vos requêtes SQL et algorithmes PHP et qu’ils mettent trop de temps à s’exécuter, c’est qu’il y a un souci. Il faudra donc chercher une autre façon de calculer l’information, car si le serveur met du temps à la générer, c’est une menace pour le TTFB. Des outils comme blackfire peuvent ici être grandement utiles pour identifier les fonctions coûteuses en webperformance.
Le temps d’affichage du premier rendu visuel : FMP
La FMP (First Meaningful Paint) correspond au moment où votre site commence à ressembler à quelque chose qui correspond à ce sur quoi l’Internaute a cliqué dans Google. Entendons nous bien : on ne parle pas d’un affichage complet, d’un site web utile ou quoi que ce soit, mais simplement de la confirmation visuelle pour le visiteur que le site charge sur le bon contenu. En gros un premier logo et quelques bribes de textes suffiront largement.
L’idée ici serait d’éviter ce que l’on appelle le » pogosticking« . En résumé, si votre visiteur clique sur votre résultat et donc lance le chargement de votre site, si il ne se passe rien qui lui laisse penser qu’il est au bon endroit et qu’il décide de revenir en arrière et de changer de page, alors Google va penser qu’il a montré un résultat non-pertinent à son visiteur et va déclasser le vôtre.
Attention cependant, cela ne se produit que sur les requêtes (certes de plus en plus nombreuses) où des mécaniques comme rank brain (l’intelligence artificielle de Google) sont actives. Dans tous les autres cas, à part perdre un client potentiel, vous ne risquez rien.
Sur la capture ci dessus, on voit que notre page qui vise la requête Agence Seo Lyon affiche un premier contenu en 0.8s et quasiment tout le rendu final en 1.1s, ce qui est très faible et donc très bien optimisé.
Comment optimiser le FMP ?
Pour optimiser cette partie (en plus du TTFB) il faut jouer sur la rapidité des éléments de haut de la page, on se moque ici complètement de la suite de la page. Voici quelques règles d’or, simples à mettre en place:
- Activation de HTTP2 côté serveur pour faciliter le chargement de plusieurs ressources en parallèle ;
- Mise en place de photos de faible taille sur le haut de la page (pour permettre la rapidité de leur chargement) ;
- Utilisation de CSS inline sur les éléments de haut de page. Pour faire simple, en incluant le CSS directement sur certains point de la première hauteur de page (couleur d’arrière plan, hauteur de bloc, couleur du texte), on favorise l’apparition d’éléments reconnaissables avant même que la première feuille de style soit chargée et interprétée.
Et vous, c’est pour quand ?
Si vous aviez bien lu jusque là, vous aurez potentiellement relativisé sur les rapports peu flatteurs constatés dans GTmetrix, Google lighthouse… Si toutefois les problèmes indiqués sont toujours là, je vous invite à nous contacter, on doit sans doute pouvoir faire quelque chose pour vous !
