Votre site est-il assez rapide pour Google ?

Google publie trois seuils, mesurés au 75e centile de vos visiteurs réels : LCP inférieur ou égal à 2,5 secondes (le contenu principal doit s'afficher vite), INP inférieur ou égal à 200 millisecondes (la page doit réagir vite au clic), et CLS inférieur ou égal à 0,1 (la mise en page ne doit pas sauter pendant le chargement). Le 75e centile signifie que trois visiteurs sur quatre doivent vivre cette expérience — pas la moyenne, qui masquerait les mauvaises sessions mobiles. Ces seuils sont documentés par Google sur web.dev. En interne, nous livrons plus strict que Google, parce qu'un site qui frôle le seuil le franchit au premier pic de trafic.

Parce qu'elles ne mesurent pas la même chose, et c'est normal. Les données de terrain viennent des vrais visiteurs de votre site sous Chrome, agrégées par Google sur une fenêtre glissante de 28 jours : elles reflètent vos utilisateurs, avec leurs vrais appareils et leurs vraies connexions. Ce sont ces chiffres-là qui comptent pour le classement. Le test en laboratoire (Lighthouse) simule une visite sur un mobile de milieu de gamme en 4G : il est reproductible et sert à diagnostiquer, pas à juger. Un écart entre les deux n'est pas un bug — il vous dit que votre audience réelle est mieux (ou moins bien) équipée que le mobile de référence.

Parce que votre site n'a pas encore assez de trafic sous Chrome pour que Google publie des données agrégées : le rapport d'expérience utilisateur exige un volume minimum, précisément pour ne pas exposer le comportement d'un utilisateur identifiable. Ce n'est pas un défaut de votre site. Dans ce cas, appuyez-vous sur le test en laboratoire, qui reste parfaitement exploitable pour identifier les causes (images trop lourdes, polices mal chargées, JavaScript bloquant), et réauditez dans quelques semaines une fois le trafic installé.

Oui, mais ce n'est pas une baguette magique — soyons honnêtes sur l'ordre de grandeur. Google confirme que l'expérience de page fait partie de ses signaux de classement : à pertinence comparable, le site le plus rapide passe devant. En revanche, un site rapide au contenu faible ne dépassera pas un site lent qui répond bien mieux à la question posée. Le vrai gain est ailleurs, et il est mesurable : la vitesse influe directement sur le taux de rebond et sur le taux de conversion. Autrement dit, on optimise les Core Web Vitals d'abord pour vos visiteurs, et le bénéfice SEO vient en prime.

Dans cet ordre, parce que c'est celui du rapport gain/effort. (1) L'image principale : la plus grosse cause de LCP dégradé est une image de bannière trop lourde, mal dimensionnée ou chargée en différé alors qu'elle est visible d'emblée. Servez-la au bon format, à la bonne taille, et préchargez-la. (2) Les polices : une police web mal déclarée bloque l'affichage du texte. (3) Le JavaScript bloquant : les scripts tiers (chat, tracking, tests A/B) chargés en tête de page repoussent tout le reste. (4) Le serveur : un temps de réponse élevé plafonne tout ce qui suit, quel que soit le travail front. Après chaque correction, réauditez : les données de terrain, elles, mettront quelques semaines à bouger.

En laboratoire, immédiatement : relancez l'audit après le déploiement, le score bouge tout de suite. Sur les données de terrain, comptez plusieurs semaines : Google calcule ces métriques sur une fenêtre glissante de 28 jours, donc vos anciennes mauvaises sessions continuent de peser tant qu'elles sont dans la fenêtre. Ne concluez pas trop vite qu'une correction n'a rien donné : vérifiez d'abord en laboratoire qu'elle produit l'effet attendu, puis laissez le temps aux données réelles de se renouveler. Nos audits conservent l'historique, ce qui vous permet de comparer votre évolution sans rien configurer.