Ce que Google mesure réellement avec les Core Web Vitals
Les Core Web Vitals sont trois métriques qui décrivent l’expérience de chargement telle que la vit un utilisateur réel. Le LCP mesure le temps d’affichage du contenu principal. Le CLS quantifie les sauts de mise en page pendant que la page se construit. L’INP mesure le délai entre une action de l’utilisateur et la réponse visible de l’interface.
La nuance que presque tout le monde rate se trouve dans la méthode d’évaluation. Google ne retient pas la moyenne de vos visites. Il retient le 75e percentile, sur une fenêtre glissante de 28 jours, et il sépare le mobile du desktop. Autrement dit, trois visiteurs sur quatre doivent passer sous le seuil pour que la métrique soit validée. Un site rapide pour la majorité mais catastrophique pour le quart d’utilisateurs en 4G dégradée échoue.
Cette mécanique explique pourquoi tant de sites affichent un score Lighthouse de 95 en local et restent en rouge dans la Search Console. Le score Lighthouse simule une visite dans des conditions figées. Les Core Web Vitals, eux, viennent du Chrome User Experience Report, la base de données que Chrome alimente avec les visites réelles des utilisateurs qui ont accepté la remontée de statistiques.
Les seuils officiels de Google : LCP inférieur ou égal à 2,5 secondes, CLS inférieur ou égal à 0,1, INP inférieur ou égal à 200 millisecondes. Entre 2,5 et 4 secondes, entre 0,1 et 0,25, entre 200 et 500 millisecondes, la métrique est classée « à améliorer ». Au-delà, elle est classée « médiocre ». Une URL n’est considérée comme conforme que si les trois métriques passent simultanément.
Ces trois indicateurs ont une histoire mouvante. Le FID, First Input Delay, a été remplacé par l’INP le 12 mars 2024 parce qu’il ne mesurait que le délai avant traitement de la première interaction, ce qui laissait passer des interfaces réellement poussives. L’INP a immédiatement fait basculer en rouge des milliers de sites WordPress surchargés de scripts qui affichaient jusque-là un FID confortable. Sur les audits que nous menons depuis, c’est la métrique qui échoue le plus souvent.
LCP : le plus gros élément visible décide de votre perception de vitesse
Le Largest Contentful Paint enregistre le moment où le plus grand élément de contenu visible dans la fenêtre initiale finit de s’afficher. Dans la pratique, il s’agit presque toujours de l’image de bannière, d’une vidéo de fond ou du bloc de titre principal. Google a choisi cette métrique parce qu’elle correspond au moment où le visiteur estime que la page est là.
Identifier l’élément LCP avant de tenter quoi que ce soit
Optimiser sans savoir quel élément est mesuré fait perdre des semaines. L’onglet Performance des DevTools Chrome affiche un marqueur LCP directement sur la timeline, et PageSpeed Insights nomme l’élément concerné dans la section diagnostics. Sur un site vitrine, c’est le visuel de hero dans 80 % des cas. Sur une fiche produit, c’est l’image principale du produit. Sur un article de blog, c’est souvent le titre H1 lui-même quand l’image à la une est chargée en différé.
Décomposer le LCP en quatre segments
Un LCP de 4,8 secondes ne dit rien tant qu’il n’est pas découpé. Le premier segment est le TTFB, le temps que met votre serveur à renvoyer le premier octet. Le deuxième est le délai avant découverte de la ressource, c’est-à-dire l’écart entre l’arrivée du HTML et le moment où le navigateur comprend qu’il doit télécharger cette image. Le troisième est le téléchargement de la ressource. Le quatrième est le délai de rendu, souvent causé par un CSS ou un JavaScript bloquant.
Cette décomposition change tout, parce que chaque segment appelle une correction différente. Un TTFB de 1,2 seconde se règle côté hébergement et cache serveur, jamais en compressant des images. Un délai de découverte élevé se règle en supprimant le lazy loading sur l’élément LCP et en ajoutant un attribut fetchpriority="high". Un temps de téléchargement excessif appelle du WebP ou de l’AVIF, un redimensionnement réel et un CDN. Un délai de rendu long trahit une feuille de style trop lourde ou une police web mal déclarée.
Le préchargement mérite une mention particulière parce qu’il est souvent mal employé. Déclarer une dizaine de ressources en preload revient à ne rien prioriser du tout : le navigateur se retrouve avec dix urgences simultanées et la bande passante se répartit entre elles. Un seul préchargement bien ciblé sur l’image LCP, associé à un preconnect vers le domaine qui l’héberge quand elle vient d’un CDN, produit un gain net. Au-delà, l’effet s’inverse.
loading="lazy" à toutes les images du site, y compris à celle du hero. Le navigateur repousse alors le téléchargement de l’élément LCP et la métrique explose. L’image visible au chargement ne doit jamais être différée.Google recommande un TTFB sous 800 millisecondes pour laisser une marge suffisante aux trois autres segments. Sur un WordPress mutualisé en PHP 7.4 sans cache objet, ce seuil est hors d’atteinte quel que soit le travail réalisé sur le front. C’est le premier point que nous vérifions lors d’un audit SEO technique, avant même de regarder le contenu.
CLS : l’instabilité visuelle que vos visiteurs subissent sans le dire
Le Cumulative Layout Shift mesure les déplacements inattendus des éléments pendant le chargement. Chaque décalage reçoit un score qui combine la fraction de l’écran affectée et la distance parcourue par l’élément. Le CLS retenu est celui de la pire fenêtre de session, une fenêtre de 5 secondes maximum, avec un intervalle d’une seconde entre deux décalages.
Personne ne se plaint d’un CLS élevé, et c’est précisément ce qui le rend dangereux. Le visiteur qui vise un bouton et clique sur une bannière publicitaire parce que la page a bougé ne remplit pas de formulaire de contact pour le signaler. Il repart. Sur les sites e-commerce que nous auditons, un CLS supérieur à 0,25 accompagne presque systématiquement un taux d’abandon anormal sur la fiche produit.
Les quatre causes qui produisent 90 % du CLS
Les images sans attributs width et height arrivent en tête. Sans ces dimensions, le navigateur ne peut pas réserver l’espace et le texte remonte brutalement quand l’image se charge. La correction tient en deux attributs, et WordPress les ajoute nativement depuis la version 5.5 pour les images insérées via l’éditeur, mais pas toujours pour celles injectées par un thème ou un constructeur de pages.
Viennent ensuite les contenus injectés dynamiquement au-dessus de la ligne de flottaison : bandeaux de consentement, barres de promotion, notifications de stock. Chacun pousse tout le reste vers le bas. La solution consiste à réserver la hauteur en amont avec un conteneur de dimension fixe, ou à superposer l’élément plutôt que de l’insérer dans le flux.
Les polices web constituent la troisième cause. Quand une police personnalisée remplace la police de secours, les métriques typographiques changent et le texte se réagence. Le couple font-display: swap et size-adjust limite le phénomène, à condition de précharger le fichier de police et de l’héberger sur votre propre domaine plutôt que d’aller le chercher chez un tiers.
Les iframes et les intégrations tierces ferment la marche. Une carte, un lecteur vidéo ou un widget d’avis clients qui se dimensionne après coup provoque un décalage systématique. Réserver le ratio d’affichage en CSS règle le problème sans toucher au service tiers.
« Un CLS propre ne se corrige pas après coup, il se conçoit. Sur un site construit correctement dès la maquette, avec des ratios d’image définis et des zones réservées pour chaque élément asynchrone, la métrique tombe naturellement sous 0,05. »
INP : la métrique qui sanctionne les sites surchargés de scripts
L’Interaction to Next Paint mesure le temps entre une interaction et la mise à jour visible de l’écran. Contrairement au FID qu’il a remplacé, il observe toutes les interactions de la visite, pas seulement la première, et il retient la plus lente ou presque. Sur les pages qui dépassent une cinquantaine d’interactions, l’algorithme ignore un cas extrême par tranche de cinquante pour éviter qu’un incident isolé ne pénalise l’ensemble.
Trois composantes, trois responsables différents
L’INP se décompose en délai d’entrée, temps de traitement et délai de présentation. Le délai d’entrée correspond à l’attente avant que le navigateur puisse seulement commencer à traiter le clic, parce que le fil d’exécution principal est occupé par autre chose. Le temps de traitement est la durée d’exécution de vos gestionnaires d’événements. Le délai de présentation couvre le recalcul de la mise en page et le rendu.
Dans la grande majorité des cas rencontrés sur WordPress, le coupable est le délai d’entrée, et le coupable derrière le coupable est un script tiers. Un gestionnaire de balises qui charge six outils de suivi, un widget de chat en direct, un module d’avis, un pixel publicitaire : chacun ajoute des tâches longues qui monopolisent le fil principal. Le visiteur clique, rien ne se passe pendant 600 millisecondes, il reclique.
Réduire l’INP sans casser les fonctionnalités
La première mesure consiste à faire l’inventaire des scripts tiers et à supprimer ceux dont personne ne consulte les données. Sur les sites que nous reprenons en maintenance WordPress, il n’est pas rare de désactiver trois outils de tracking redondants installés à des époques différentes par des prestataires successifs.
La deuxième consiste à différer ce qui peut l’être. Un widget de chat n’a aucune raison de se charger avant la première interaction du visiteur. Le charger au premier scroll ou au survol du bouton libère le fil principal pendant la phase critique.
La troisième consiste à découper les tâches longues. Un gestionnaire d’événements qui exécute 400 millisecondes de calcul d’un bloc doit rendre la main au navigateur entre deux étapes, avec scheduler.yield() quand il est disponible ou un simple report d’exécution. Le travail total reste identique, mais l’interface répond entre les segments.
Mesurer ses Core Web Vitals : données de terrain contre données de laboratoire
Confondre ces deux sources est l’erreur méthodologique la plus répandue. Les données de terrain proviennent de vos visiteurs réels et constituent la seule source utilisée par Google pour l’évaluation. Les données de laboratoire proviennent d’une simulation exécutée à la demande, dans un environnement standardisé. Les premières disent où vous en êtes. Les secondes disent pourquoi.
PageSpeed Insights, le point de départ
L’outil affiche les deux blocs sur la même page. En haut, l’évaluation de l’expérience utilisateur réelle, tirée du Chrome User Experience Report sur 28 jours. En bas, le diagnostic Lighthouse et sa liste d’opportunités. Le bloc supérieur est celui qui compte pour le référencement. Le bloc inférieur est celui qui vous dit quoi corriger.
Une page à faible trafic n’a pas assez de visites pour alimenter le rapport. PageSpeed Insights bascule alors sur les données du domaine entier, ce qui masque totalement le comportement de l’URL testée. Une fiche produit lente peut ainsi afficher un vert rassurant hérité de la page d’accueil.
La Search Console, pour raisonner à l’échelle du site
Le rapport Signaux web essentiels regroupe les URLs par similarité de structure et signale les groupes en échec. C’est l’outil qui permet de comprendre qu’un problème vient d’un gabarit et non d’une page. Quand 240 fiches produit apparaissent dans le même groupe en rouge, la correction se fait une fois dans le template et couvre l’ensemble du catalogue. Ce raisonnement par gabarit est central sur un projet de SEO e-commerce, où le volume d’URLs rend toute correction unitaire impossible.
Comptez 28 jours après une correction pour voir la Search Console basculer au vert. La fenêtre glissante du rapport intègre progressivement les nouvelles visites. Valider un correctif se fait en laboratoire dans l’heure, le confirmer sur le terrain prend un mois.
Mesurer chez vos propres visiteurs
La bibliothèque officielle web-vitals de Google permet de collecter les trois métriques directement dans le navigateur de vos visiteurs et de les envoyer vers votre outil d’analyse. L’intérêt est de segmenter par type d’appareil, par navigateur, par page et par pays, ce que le rapport agrégé ne permet pas. Sur un site multilingue servant l’Andorre, la France et l’Espagne, cette segmentation révèle parfois que le problème se limite à une zone géographique mal couverte par le CDN.
Corriger les Core Web Vitals sur WordPress et Elementor
WordPress n’est pas lent par nature. Il devient lent par accumulation : un thème générique chargé de fonctionnalités inutilisées, trente extensions dont douze injectent leur CSS sur toutes les pages, un constructeur de pages configuré par défaut, un hébergement mutualisé. Chaque couche ajoute quelques centaines de millisecondes.
L’hébergement et le TTFB, la fondation
Aucune optimisation front ne rattrape un serveur lent. PHP 8.2 ou supérieur, OPcache actif, cache objet persistant avec Redis, cache de page complet, HTTP/2 au minimum : ce socle divise couramment le TTFB par trois. Sur un site à trafic international, un CDN qui sert les ressources statiques depuis un point de présence proche du visiteur complète le dispositif. C’est exactement ce que couvre une offre d’hébergement infogéré, par opposition à un hébergement mutualisé à quelques euros par mois où votre site partage ses ressources avec des centaines d’autres.
Les images, le gisement le plus rentable
Trois actions dans l’ordre. Servir du WebP ou de l’AVIF plutôt que du JPEG, ce qui réduit le poids de 30 à 50 % à qualité visuelle constante. Redimensionner réellement les fichiers au lieu de laisser le navigateur réduire une image de 3000 pixels de large dans un conteneur de 800. Appliquer le lazy loading partout sauf sur l’élément LCP, avec fetchpriority="high" sur ce dernier.
Le CSS et le JavaScript, la discipline du chargement
Le principe tient en une phrase : ne charger sur une page que ce que cette page utilise. Un formulaire de contact qui injecte son CSS et son JavaScript sur l’intégralité du site alors qu’il n’apparaît que sur une URL représente un gaspillage pur. Le chargement conditionnel des ressources par extension, la mise en ligne du CSS critique dans le document et le report du reste constituent l’essentiel du travail.
Elementor, les réglages qui changent la donne
Elementor Pro traîne une réputation de lourdeur largement héritée de ses versions anciennes et de configurations laissées par défaut. Les fonctionnalités expérimentales à activer sont connues : chargement optimisé des ressources, chargement du CSS à la demande, icônes de police en ligne, sortie DOM optimisée. Elles retirent plusieurs dizaines de kilo-octets sur chaque page.
Le reste relève de la méthode de construction. Les conteneurs flexbox remplacent avantageusement l’ancien empilement section, colonne, widget, qui multipliait les niveaux d’imbrication et alourdissait l’arbre du document. Désactiver les bibliothèques d’icônes et les animations non utilisées supprime des requêtes entières. Sur nos projets de site sur-mesure, nous limitons volontairement le nombre de widgets tiers et nous réécrivons en HTML et CSS natifs les blocs dont la version widget coûte trop cher en performance.
Cette discipline a une limite qu’il faut assumer. Sur un site accumulant huit ans de contenus, trois refontes partielles et une bibliothèque d’extensions héritée, l’optimisation à la marge atteint un plafond. Une refonte de site internet coûte souvent moins cher que douze mois de correctifs successifs sur une base structurellement compromise, et elle donne un résultat que le rafistolage n’atteindra jamais.
La base de données et les extensions, le poste que personne ne regarde
Une installation WordPress de plusieurs années accumule silencieusement du poids invisible depuis le front. Les révisions d’articles se comptent parfois en dizaines de milliers de lignes, les tables des extensions désinstallées restent en place, les entrées transitoires expirées ne sont jamais purgées. Chaque requête de page traverse cette masse et le TTFB s’allonge de quelques dizaines de millisecondes à chaque couche.
Le nettoyage se fait sur sauvegarde préalable, jamais à chaud sur un site en production. Limiter le nombre de révisions conservées, purger les tables orphelines, indexer correctement les colonnes interrogées par les extensions gourmandes : le gain est rarement spectaculaire pris isolément, mais il s’ajoute aux autres et il évite la dérive lente que l’on constate sur les sites laissés sans suivi. C’est précisément ce que couvre un contrat de maintenance sérieux, par différence avec une simple surveillance de disponibilité.
Reste la question du nombre d’extensions, sur laquelle circulent beaucoup d’approximations. Trente extensions légères et bien codées pèsent moins lourd que cinq extensions qui chargent chacune leur bibliothèque JavaScript complète sur toutes les pages du site. Le critère utile n’est pas la quantité, c’est le poids réellement injecté page par page, que l’onglet Réseau des DevTools révèle en quelques minutes.
L’impact réel sur votre positionnement, sans exagération
Il faut être honnête sur le poids de ces métriques dans l’algorithme. Les Core Web Vitals sont un signal de classement, confirmé et documenté par Google, mais un signal parmi des centaines. Un site parfaitement optimisé techniquement et vide de contenu utile ne passera jamais devant une page de référence lente sur une requête concurrentielle. La pertinence et l’autorité restent devant.
Leur influence se manifeste dans deux situations précises. La première est l’arbitrage entre pages de qualité comparable : à pertinence équivalente, l’expérience de page départage. Sur une requête où dix résultats traitent le même sujet avec le même sérieux, la différence se joue là. La seconde est le budget d’exploration. Un serveur lent réduit le nombre de pages que Google explore par session, ce qui ralentit l’indexation des nouveautés sur les sites volumineux.
L’effet indirect pèse pourtant plus lourd que l’effet direct. Une page lente augmente le taux de rebond, réduit le nombre de pages vues par visite et fait chuter le taux de conversion. Ces comportements finissent par se lire dans les données que Google collecte à l’échelle du web. Un tunnel de commande qui met quatre secondes à réagir à chaque clic perd des paniers avant même de perdre des positions.
C’est aussi la raison pour laquelle nous traitons la performance comme une contrainte de conception et non comme une phase d’optimisation finale. Un site conçu avec un budget de performance défini dès la maquette n’a pas besoin d’être rattrapé après coup. Les projets visibles dans nos réalisations sont livrés directement dans le vert, sans extension miracle installée à la dernière minute.
La méthode d’intervention, dans l’ordre qui produit des résultats
L’ordre compte autant que les actions. Beaucoup de projets échouent parce qu’ils commencent par le plus visible plutôt que par le plus déterminant.
- Mesurer le point de départ sur le terrain. Relever les trois métriques dans la Search Console, groupe de pages par groupe de pages, et non sur la seule page d’accueil.
- Traiter le serveur. Version de PHP, cache objet, cache de page, TTFB sous 800 millisecondes. Rien d’autre n’avance tant que ce point n’est pas réglé.
- Corriger l’élément LCP page par gabarit. Préchargement, priorité de récupération, format et dimensions réelles de l’image.
- Éliminer les décalages. Dimensions sur toutes les images, espace réservé pour les éléments asynchrones, polices préchargées et hébergées localement.
- Faire l’inventaire des scripts tiers. Supprimer, différer, ou charger à l’interaction. C’est le poste qui débloque l’INP.
- Alléger le CSS et le JavaScript des extensions. Chargement conditionnel, CSS critique en ligne, report du reste.
- Attendre 28 jours et remesurer. Sur les données de terrain, jamais sur un score de laboratoire.
Cette séquence s’applique aussi bien à un site vitrine de douze pages qu’à un catalogue de plusieurs milliers de références. Seule l’ampleur du travail par étape change. Sur un site e-commerce, l’étape trois et l’étape cinq représentent à elles seules la majorité de l’effort, parce que les fiches produit concentrent les images lourdes et les scripts de personnalisation.
Une remarque sur le budget. La performance n’est pas une ligne optionnelle du devis, c’est une conséquence des choix d’architecture faits au départ. Un projet construit sur un thème générique acheté 60 euros coûtera plus cher à corriger sur trois ans qu’un développement propre. Notre simulateur de prix de site internet donne une fourchette réaliste en quelques minutes, et l’article détaillant combien coûte un site internet en 2026 explique ce que recouvre chaque poste.
Ce que vous devez retenir
Les Core Web Vitals ne récompensent pas la performance théorique, ils récompensent la performance vécue par le quart le moins bien loti de vos visiteurs. Cette différence de perspective explique l’écart permanent entre un score Lighthouse flatteur et un rapport Search Console en rouge.
Trois priorités se dégagent de la centaine d’audits que nous avons menés. Le serveur d’abord, parce qu’il conditionne tout le reste et qu’aucun réglage front ne compense un TTFB dégradé. L’élément LCP ensuite, parce qu’il se corrige vite et qu’il produit un gain immédiatement mesurable. Les scripts tiers enfin, parce qu’ils sont devenus la première cause d’échec depuis l’arrivée de l’INP et que personne ne les surveille.
Le reste relève de l’hygiène de projet : des dimensions sur les images, des polices hébergées localement, un espace réservé pour tout ce qui arrive après le premier rendu, et le refus des extensions qui promettent de tout régler en une case à cocher. Un site rapide n’est pas un site optimisé après coup, c’est un site construit correctement. Si vos métriques restent bloquées malgré les corrections, le problème est structurel et la discussion porte alors sur l’architecture, pas sur les réglages.
