Pourquoi la vitesse de mon site compte-t-elle pour le SEO ?

La vitesse aide le SEO, mais ne remplace pas la réponse

Un bon résultat de performance ne suffit pas à bien se classer. Google utilise les Core Web Vitals, des mesures de l’expérience sur une page, dans ses systèmes de classement. Il précise aussi qu’une bonne évaluation ne garantit pas une place en haut des résultats et qu’il cherche à proposer les contenus les plus pertinents. La documentation sur l’expérience sur la page explique cette limite.

Le SEO, ou Search Engine Optimization, signifie optimisation pour les moteurs de recherche. Si ce terme est nouveau pour vous, commencez par la définition du référencement naturel. Ici, nous traitons une partie technique : le confort d’utilisation de vos pages.

Une page de menuiserie peut s’afficher vite et rester inutile si elle ne précise pas les travaux proposés. À l’inverse, une description claire devient difficile à consulter si le menu tarde à répondre. Les deux problèmes demandent des corrections différentes. Pour replacer la performance parmi les autres priorités, l’article comment améliorer sa position sur Google complète cette lecture.

Ne cherchez pas un pourcentage de classement à gagner grâce à la vitesse. Aucun poids universel ni gain de positions ne peut être déduit d’une note PageSpeed. Notez plutôt le défaut rencontré par le visiteur et ce que la correction doit rendre utilisable.

LCP, INP, CLS : trois problèmes différents à comprendre

« Rapide » ne veut pas seulement dire « téléchargé ». Une page peut montrer sa photo rapidement, puis bloquer quand on ouvre le menu. Elle peut aussi répondre au clic tout en déplaçant le bouton sous le doigt. Les Core Web Vitals donnent trois repères pour distinguer ces situations.

Ces seuils sont présentés dans les recommandations Web Vitals. Ils s’évaluent au 75e centile, séparément sur mobile et ordinateur : pour la mesure concernée, au moins 75 % des observations doivent être au niveau du seuil ou en dessous. Ce n’est ni une moyenne ni le résultat d’un seul chargement.

Gardez ces unités lorsque vous transmettez un rapport. « Le LCP mobile est à améliorer » indique un problème à explorer ; « mon site a 65 » ne dit pas ce qui attend, bloque ou bouge.

Lisez PageSpeed en séparant terrain et laboratoire

PageSpeed Insights réunit deux observations différentes. Les données de terrain décrivent des visites réellement collectées par le rapport d’expérience utilisateur Chrome, appelé CrUX. Le test de laboratoire utilise Lighthouse pour charger une page dans des conditions simulées et rechercher des causes possibles.

Dans PageSpeed Insights, saisissez l’adresse complète de la page, puis regardez mobile et ordinateur séparément. Notez si les données réelles portent sur cette URL ou sur l’origine, c’est-à-dire l’ensemble du site pour le domaine et le protocole concernés. Une observation globale ne décrit pas forcément votre page services.

La documentation de PageSpeed indique que le terrain couvre les 28 jours précédents. Une correction faite aujourd’hui ne remplace donc pas immédiatement tout cet historique. Le laboratoire peut aider à vérifier plus vite la modification, sans prouver que tous les visiteurs bénéficient du même résultat.

Si aucune donnée réelle ne s’affiche

L’absence de données ne signifie pas que le site est lent. CrUX exige notamment une page publique et assez d’observations admissibles. Le seuil exact n’est pas publié. La méthodologie CrUX explique ces conditions. Un petit site peut manquer d’échantillons : conservez alors les tests et leurs limites, au lieu de leur donner le statut de données réelles.

Une bonne note de laboratoire n’est pas non plus une garantie d’un bon INP pendant une vraie visite. Ouvrez le menu, la galerie et les questions fréquentes : le chargement initial ne décrit pas à lui seul ces interactions.

Un exemple de diagnostic en six contrôles

Exemple illustratif : Thomas est menuisier à Namur et présente ses bibliothèques sur mesure. Sur son site fictif, la photo d’accueil apparaît tard et le bouton de contact descend pendant le chargement. Cette situation sert à expliquer le diagnostic ; elle ne décrit ni un client ni des résultats d’OOZWEB.

1. Partir d’une vraie tâche et de la bonne page

Testez « comprendre la prestation, voir une réalisation, préparer une demande ». Ouvrez la page services sur un téléphone, comme le ferait une personne qui ne connaît pas le site. Notez l’adresse, l’appareil et le moment où vous rencontrez un obstacle. Thomas ne se limite pas à l’accueil : la page bibliothèques peut recevoir un visiteur directement depuis une recherche.

2. Examiner l’image qui tarde à apparaître

Vérifiez le fichier reçu avant de réduire la qualité. Une photo affichée en petit peut encore faire télécharger son grand original. Préparez des dimensions adaptées et comparez la netteté avec le poids ; WebP et AVIF peuvent améliorer la compression, sans rendre tous les fichiers automatiquement légers. Le guide des performances des images décrit ces choix.

Si cette photo est le principal élément visible au début, évitez de la charger en différé avec loading="lazy". Ce réglage convient aux images hors écran, mais peut retarder l’image LCP. Consultez les conseils d’optimisation du LCP. Pour les variantes et le cadrage, suivez la préparation des photos du site, plutôt que recompresser toute la galerie sans contrôle.

3. Réserver la place des photos et modules

Empêchez le contenu d’attendre l’image pour connaître sa place. Les dimensions width et height donnent au navigateur le rapport de taille à réserver. Elles doivent correspondre au fichier ; l’affichage responsive conserve sa proportion. C’est une correction recommandée dans le guide sur les déplacements de mise en page.

Exemple pour une photo de galerie, située plus bas dans la page, de 1 200 × 800 pixels :

<img src="bibliotheque-sur-mesure.webp"
     width="1200" height="800"
     loading="lazy"
     alt="Bibliothèque en chêne ajustée sous un plafond incliné">

Le fichier doit exister à ce chemin. loading="lazy" diffère cette photo hors écran ; alt décrit la scène. Les dimensions réservent une proportion, elles ne compressent pas le fichier. Vérifiez aussi qu’une carte, une vidéo ou un module ajouté tardivement dispose d’un espace prévu. Dans le scénario, le bouton doit rester à sa place quand les photos arrivent.

4. Tester le menu pendant et après le chargement

Reproduisez le clic lent avant de supprimer des scripts. JavaScript sert notamment au menu, à une galerie ou à une réservation. Son traitement peut occuper le navigateur et retarder une réponse, mais tout script n’est pas inutile. Faites inventorier les fonctionnalités réellement nécessaires, les modules externes et le travail effectué au clic. Le guide d’optimisation de l’INP distingue l’attente, le traitement et l’affichage.

Pour Thomas, « le menu ne s’ouvre pas quand la galerie démarre » est une observation utile à transmettre. « Supprimer tout JavaScript » ne définit pas une correction acceptable. Après intervention, testez aussi le clavier et la fermeture du menu ; une fonction cassée n’est pas une amélioration.

5. Distinguer attente du serveur et attente de l’image

Si rien n’arrive au début, ne supposez pas que la photo est seule responsable. Le TTFB, ou Time to First Byte, décrit le délai avant le début de la réponse. Il inclut notamment la connexion et la réponse du serveur ; c’est un indicateur de diagnostic, pas un quatrième Core Web Vital. La définition du TTFB aide à lire cette étape.

Demandez de distinguer redirections, connexion, serveur et ressources suivantes. Changer d’hébergeur sans ce relevé peut laisser intacte la cause observée. À l’inverse, recompresser une galerie ne corrige pas une attente située avant la réponse du document.

6. Comparer et refaire le contact

Gardez la même page et des conditions comparables avant et après. Archivez les rapports, le mode mobile ou ordinateur, la date, les mesures et les changements réalisés. Répétez le test pour voir si le défaut est stable. Les notes peuvent varier avec les conditions ; la documentation Lighthouse explique cette variabilité.

Dans le scénario, Thomas vérifie que la photo reste lisible, que le bouton ne se déplace plus et que le menu répond. Il termine la démarche jusqu’au formulaire. Il ne conclut pas que ces corrections lui ont apporté des clients : aucun résultat commercial n’a été mesuré.

Choisissez une correction ciblée avant une refonte

Un défaut isolé ne justifie pas toujours de refaire le site. Une photo trop grande, un espace non réservé ou un module superflu peuvent appeler une correction ciblée. Si les prestations sont obsolètes, les pages mal organisées et le contact inadapté, le problème dépasse la performance.

Pour cette dernière décision, consultez les critères pour savoir quand refaire son site. Pour le référencement au-delà de la vitesse, utilisez le guide des bases SEO d’un site vitrine.

Le relevé à préparer pour demander une amélioration

Transmettez un problème vérifiable plutôt qu’une demande de note parfaite. Ce relevé organise votre demande ; il ne remplace pas une analyse professionnelle :

1. Page concernée : son adresse exacte et son rôle pour le client.
2. Tâche : lire un service, ouvrir une photo, réserver ou préparer le contact.
3. Défaut : ce qui tarde, bloque ou se déplace, avec les étapes pour le reproduire.
4. Contexte : appareil, navigateur, connexion, date et rapport disponible.
5. Vérification : ce qui doit rester lisible et fonctionner après correction.

Demandez ensuite quelles causes seront examinées, quelles actions sont comprises et comment elles seront contrôlées. Gardez les mesures de performance séparées du suivi des positions et des demandes reçues. Une amélioration technique peut être utile sans que vous puissiez lui attribuer une évolution commerciale.

Foire aux questions