Core Web Vitals

Un LCP qui dépasse 4 secondes sur mobile, c’est une part significative des visiteurs qui partent avant que la page ait fini de s’afficher. C’est ce que je constate à chaque audit : Search Console classe les URL en rouge, personne dans l’équipe n’a de prise directe sur le sujet parce que ça touche à la fois le thème, les plugins, les images et parfois l’hébergement lui-même.

Un site lent, ce sont des clients qui partent avant la fin

Les Core Web Vitals (LCP, INP, CLS) ne sont qu’un signal de classement parmi des centaines pour Google, mais ils traduisent surtout une expérience réelle pour vos visiteurs : un site qui bouge sous les doigts au chargement, qui met une seconde à répondre au clic sur « Ajouter au panier », ça se transforme en taux de rebond et en paniers abandonnés, pas seulement en position dans les résultats de recherche.

Le cas classique : un site qui passait au vert il y a deux ans repasse au rouge après une refonte du thème, l’ajout d’un slider ou d’un widget de chat, ou une nouvelle configuration d’hébergement. Personne n’y touche tant que « ça fonctionne à peu près » — jusqu’à ce que le trafic mobile décroche ou qu’une migration mal préparée fasse chuter les positions d’un coup. Un audit SEO technique complet permet de resituer ce problème de performance dans l’ensemble des signaux techniques qui comptent pour votre référencement.

LCP, INP, CLS : ce que Google mesure réellement

Le LCP (Largest Contentful Paint) mesure le temps d’affichage du plus gros élément visible à l’écran — une image héro, un titre, un bloc vidéo. Le seuil « bon » est fixé à 2,5 secondes sur mobile ; au-delà de 4 secondes, la page est classée « à améliorer » ou « mauvaise » par Google.

L’INP (Interaction to Next Paint), qui a remplacé le FID en 2024, mesure le délai entre une interaction — clic, tap, saisie — et le rendu visuel de sa réponse. Il doit rester sous 200 ms. C’est souvent le plus difficile à corriger : il dépend de tout le JavaScript exécuté sur la page, y compris les scripts tiers (chat, publicité, tracking) que vous ne contrôlez pas toujours directement.

Le CLS (Cumulative Layout Shift) mesure les décalages visuels pendant le chargement : une image sans dimension réservée qui pousse le texte, une bannière de cookies qui s’affiche après coup, une police qui change la taille d’un bloc. Le seuil bon est 0,1.

Ces trois métriques sont mesurées sur de vrais utilisateurs (données CrUX, remontées via Search Console et PageSpeed Insights), pas seulement en laboratoire. C’est une nuance importante : un score PageSpeed à 95 sur un test ponctuel ne garantit rien une fois le site exposé au trafic réel, avec une connexion 4G moyenne et un téléphone d’entrée de gamme.

Comment j’interviens

Je commence par un diagnostic sur les URL réellement indexées et à fort trafic — pas sur la page d’accueil seule, rarement représentative. Je croise Search Console, PageSpeed Insights et un audit Lighthouse en conditions mobiles réalistes (CPU throttlé, réseau 4G simulé) pour distinguer un problème de conception (thème, structure du DOM) d’un problème de contenu (poids des images, scripts tiers empilés au fil du temps).

Une fois les correctifs déployés, je repasse sur les mêmes URL deux à trois semaines plus tard : les données CrUX se mettent à jour sur une fenêtre glissante de 28 jours, donc un résultat instantané dans PageSpeed Insights ne veut rien dire sur le terrain. Je fournis un avant/après basé sur Search Console, pas seulement un score de test isolé.

Un exemple concret

C’est un cas fréquent avec les sites construits sur un page builder : les widgets préconfigurés chargent des styles et des scripts pour toutes les options possibles, même celles que vous n’utilisez pas.

Dans ce cas précis, le gain n’est pas venu d’une refonte mais d’un nettoyage : réduction du nombre de widgets actifs, remplacement d’un carrousel lourd, compression des visuels. C’est souvent plus rapide et moins cher qu’un changement de thème complet.

Les cas où je vous déconseille cette prestation

Si votre thème ou votre page builder accumule une dette technique trop lourde — trop de plugins de mise en page superposés, code généré illisible — corriger les Core Web Vitals un par un revient à rafistoler indéfiniment. Dans ce cas, une refonte du thème est souvent plus rentable qu’une série d’interventions ponctuelles qui ne tiendront pas à la prochaine mise à jour.

Si votre trafic mobile est marginal (site B2B consulté depuis un poste de bureau, par exemple), l’urgence est ailleurs : mieux vaut d’abord un audit SEO technique global pour prioriser les vrais points de friction.

Et si les scripts tiers qui plombent votre INP sont imposés par votre service marketing ou juridique (bannière de consentement, pixel de tracking, chat client), la marge de manœuvre technique est réelle mais limitée : je peux alléger leur impact, pas les supprimer sans votre accord.

Combien coûte une mission Core Web Vitals

Ce type de mission ne se prête pas à un forfait fixe : le temps nécessaire dépend directement du nombre de gabarits concernés, de la nature du CMS et du nombre de scripts tiers à traiter. Je facture donc ce travail en régie, sur la base d’un diagnostic initial qui chiffre le nombre de jours nécessaires avant de démarrer.

Pour un site vitrine avec deux ou trois gabarits problématiques, on parle généralement de quelques jours. Pour un site e-commerce multi-boutiques avec un catalogue important, le chiffrage se fait après l’audit, gabarit par gabarit. Si le site nécessite par ailleurs un suivi régulier — mises à jour, surveillance des régressions après chaque changement de plugin —, ce suivi peut être intégré à un contrat de maintenance à partir de 80 € HT/mois.

FAQ