L'essentiel
Les Core Web Vitals sont les trois mesures que Google utilise pour juger l'expérience réelle de vos visiteurs : le LCP (vitesse d'affichage du contenu principal, à viser sous 2,5 secondes), l'INP (réactivité aux clics et aux saisies, sous 200 millisecondes) et le CLS (stabilité visuelle, sous 0,1). Un site qui passe ces seuils garde plus de visiteurs et envoie un signal de qualité à Google. La plupart des sites lents le sont à cause d'images non optimisées et d'un empilement de plugins; un site construit sur mesure et servi depuis un réseau edge atteint et conserve ces cibles plus facilement.
Les trois mesures que Google regarde vraiment
- LCP (Largest Contentful Paint) — le temps avant que l'élément principal de la page (souvent une image ou un titre) s'affiche. Cible : sous 2,5 secondes.
- CLS (Cumulative Layout Shift) — la stabilité de la mise en page : est-ce que le contenu saute pendant le chargement (cette publicité qui pousse le bouton au moment où vous cliquez). Cible : sous 0,1.
Depuis quelques années, Google ne se contente plus de regarder votre contenu : il mesure aussi comment votre site se comporte pour un vrai visiteur, sur un vrai téléphone, avec une vraie connexion. Ces mesures portent un nom — les Core Web Vitals — et il y en a trois. Elles sont volontairement simples à comprendre, parce qu'elles décrivent trois moments concrets de la visite.
Le plus important est que ces chiffres viennent de vos visiteurs réels, pas d'un test en laboratoire. Google évalue votre site au 75e centile : pour réussir, il faut que 75 % des visites respectent les seuils. Autrement dit, ça ne suffit pas que votre site soit rapide pour vous, sur votre ordinateur de bureau en fibre — il doit l'être pour la majorité des gens, souvent en déplacement et en données cellulaires.
Le mobile d'abord, pas le mobile après coup
La majorité de vos visiteurs arrivent par téléphone, et Google indexe d'abord la version mobile de votre site. C'est précisément là que les problèmes de performance font le plus mal : un téléphone a moins de puissance qu'un ordinateur, et une connexion cellulaire est plus capricieuse que le Wi-Fi du bureau.
Un site qui paraît correct sur grand écran peut être pénible sur mobile : images trop lourdes téléchargées en entier, texte qui saute pendant le chargement, bouton qui ne répond pas tout de suite. Concevoir pour le mobile en premier — et tester sur de vrais appareils, pas seulement en simulation — n'est pas une option. C'est la base, et c'est là que se gagne ou se perd l'expérience de la plupart de vos clients.
Ce qui ralentit un site, concrètement
- Images non optimisées : pas redimensionnées, pas compressées, servies dans d'anciens formats au lieu de WebP ou AVIF.
- Empilement de plugins et de scripts tiers qui s'exécutent à chaque chargement.
- Polices et bannières qui décalent la page pendant qu'elle se construit (mauvais CLS).
- Hébergement mutualisé bon marché et lointain, qui répond lentement à la première requête.
- Code générique d'un thème prêt-à-l'emploi, alourdi de fonctions que vous n'utilisez jamais.
Les sites lents le sont rarement par hasard. Les coupables reviennent presque toujours, et le plus fréquent n'a rien d'exotique : ce sont les images. Une photo exportée à pleine résolution depuis un téléphone peut peser plusieurs mégaoctets; en mettre dix sur une page, sans redimensionnement ni format moderne, suffit à plomber le LCP.
L'autre grand responsable est l'accumulation. Beaucoup de sites reposent sur WordPress avec une dizaine d'extensions (plugins) installées au fil du temps : un pour les formulaires, un pour le carrousel, un pour les fenêtres surgissantes, un pour les statistiques. Chacun ajoute son propre code, ses propres scripts, ses propres requêtes — et l'addition se paie en lenteur et en instabilité visuelle. Plus il y a de pièces mobiles, plus il y a de choses qui ralentissent et qui cassent.
Comment on atteint un site rapide et stable
Chez nous, la vitesse n'est pas un correctif appliqué à la fin : c'est une décision prise au départ. On construit les sites en React/Vite — du code sur mesure, sans CMS ni empilement de plugins — précisément pour ne pas traîner le poids mort qui ralentit les sites WordPress moyens. Moins de pièces mobiles, c'est moins de choses qui ralentissent et qui cassent.
Concrètement, on travaille les images au bon format et à la bonne taille, on évite les scripts tiers inutiles, on réserve l'espace des éléments pour qu'aucun bouton ne saute, et on sert le site depuis un hébergement edge mondial pour que la première réponse arrive vite, peu importe d'où vient le visiteur. C'est ce qui nous permet de viser un score Lighthouse de 90 et plus — un indicateur reconnu de bonne performance technique — tout en respectant la Loi 25, entièrement en vigueur au Québec depuis le 22 septembre 2024. Et parce que le code vous est remis à la livraison, vous n'êtes prisonnier de personne pour le faire évoluer.