Un client m'appelle un mardi matin, un peu paniqué. Sa fiche Search Console affiche des URL en rouge dans le rapport Core Web Vitals, il a lu quelque part que Google allait le déclasser, et il veut « tout refaire le site ». Je regarde les données. LCP à 4,1 s sur mobile, mais uniquement sur les pages catégories. Les pages produits sont à 1,8 s et se portent très bien. Refaire le site entier aurait coûté trois mois de dev pour corriger un seul gabarit de page. Voilà pourquoi je commence toujours par un diagnostic avant de toucher à la moindre ligne de code.
Optimiser son site pour le Core Web Vitals, ce n'est pas un chantier global. C'est un travail de chirurgie, page par page, métrique par métrique. Et dans 80 % des cas que je traite, trois correctifs suffisent à faire basculer l'ensemble.
Points clés à retenir
- Le Core Web Vitals repose sur trois métriques : LCP, INP et CLS. Chacune a sa cause racine et ses leviers propres.
- Les données de terrain (CrUX, Search Console) et les données de labo (PageSpeed Insights, Lighthouse) ne racontent pas la même histoire. Il faut apprendre à les croiser.
- L'INP a remplacé le FID. Beaucoup de sites « verts » sur le FID sont en réalité en difficulté sur l'INP sans le savoir.
- Corriger le LCP, c'est presque toujours trancher entre trois coupables : le TTFB, le temps de rendu, ou les ressources bloquantes.
- Un site n'a pas besoin d'être parfait partout. Il a besoin d'être vert là où ça compte : les gabarits les plus visités.
Comprendre le Core Web Vitals avant de toucher au code
Trois métriques. C'est tout. Mais chacune mesure une chose très différente, et les confondre est l'erreur la plus fréquente.
Que mesurent vraiment le LCP, l'INP et le CLS ?
Le LCP (Largest Contentful Paint) chronomètre le moment où le plus gros élément visible — souvent une image hero ou un titre — s'affiche à l'écran. La cible : moins de 2,5 secondes. C'est la métrique du « est-ce que ça charge ».
L'INP (Interaction to Next Paint) mesure la latence entre une interaction utilisateur (clic, tap, frappe clavier) et le moment où le navigateur affiche la réponse. Le seuil correct : moins de 200 ms. C'est la métrique du « est-ce que ça répond ».
Le CLS (Cumulative Layout Shift) quantifie les mouvements inattendus de mise en page. Vous lisez un paragraphe, la bannière cookie charge en retard, tout descend de 200 px. Le seuil : moins de 0,1. C'est la métrique du « est-ce que c'est stable ».
Le FID a été remplacé par l'INP, et ça change tout
Avouons-le, on a beaucoup entendu parler du FID. First Input Delay. Le problème, c'est que le FID ne mesurait que le délai avant que le navigateur commence à traiter l'interaction. Pas le temps total de réponse. Un site pouvait afficher un FID de 15 ms — vert, impeccable — et mettre 800 ms à afficher le résultat du clic.
L'INP corrige ça. Il mesure l'interaction complète, du clic à l'affichage final, et retient la pire interaction observée (au 98e percentile). Résultat : une tonne de sites autrefois verts sont passés au rouge sans qu'on ait rien changé. J'ai vu ça chez un client dont le score FID était à 8 ms — INP mesuré à 340 ms. Le site « allait bien » jusqu'à ce que la réalité rattrape les données.
La bonne nouvelle : les techniques qui améliorent l'INP sont souvent plus simples que celles pour le LCP. Découper les longues tâches JavaScript. Céder le fil principal pendant les animations. Charger les scripts tiers en différé — ou les supprimer, ce qui est encore plus efficace.
Diagnostiquer un Core Web Vitals dégradé, étape par étape
La méthode que j'applique systématiquement. Elle prend une demi-journée par gabarit de page et évite des semaines de dev à l'aveugle.
Données de terrain ou données de labo : la distinction qu'on oublie
PageSpeed Insights vous donne deux blocs de chiffres. Le premier, en haut, ce sont les données de terrain — issues du Chrome User Experience Report, ou CrUX, qui agrège les mesures d'utilisateurs réels sur les 28 derniers jours. Le second bloc, c'est le labo — une simulation Lighthouse sur un serveur Google, avec un réseau bridé et un CPU bridé.
Ces deux blocs ne racontent pas la même histoire. Le labo est reproductible, contrôlé, mais artificiel. Le terrain est réel, mais bruité. Vous devez optimiser pour le terrain, en utilisant le labo comme outil de travail. Quand le terrain dit LCP = 3,8 s et que le labo dit 1,9 s, ce n'est pas Lighthouse qui a tort, c'est vous qui avez un utilisateur moyen beaucoup plus lent qu'un throttling 4G standard.
Le meilleur tableau de bord pour suivre le terrain : le rapport Core Web Vitals dans Search Console. Il regroupe les URL par statut (Bon / À améliorer / Faible) et vous montre exactement sur quels gabarits vous perdez. Pas besoin d'extension pour ça.
Isoler la cause racine d'un LCP dégradé
Trois coupables possibles. Je les teste dans cet ordre :
- Le TTFB est-il supérieur à 800 ms ? Si oui, c'est un problème serveur. Cache, CDN, requêtes base de données. Rien à voir avec le CSS ou les images.
- Le délai de rendu est-il le goulot ? Regardez le waterfall PageSpeed : si votre CSS critique bloque pendant 1,5 s, c'est là qu'il faut travailler. Inline critical CSS, defer non-critique.
- L'élément LCP lui-même est-il lent à charger ? C'est souvent une image hero non préchargée, ou servie en pleine résolution alors qu'elle s'affiche en 800 px de large.
Une erreur que j'ai faite au tout début : optimiser toutes les images au format WebP en pensant que ça réglerait le LCP. Le LCP est passé de 3,4 s à 3,2 s. Gain réel, mais dérisoire. Le vrai problème, c'était un script de tracking tiers qui bloquait le rendu pendant 1,2 s. Le retirer du chemin critique : LCP à 2,1 s. Parfois, on cherche au mauvais endroit pendant des jours.
Les leviers qui font vraiment bouger les aiguilles
Il y a les optimisations « génériques » qu'on lit partout. Et il y a celles qui, dans la vraie vie, produisent un effet mesurable.
Traiter par gabarit, pas par URL
Vous avez 5 000 URL mais peut-être 8 gabarits. Ne corrigez jamais URL par URL. Corrigez le gabarit, et vous corrigez d'un coup 4 200 pages. J'ai fait gagner à un e-commerçant 3,2 secondes sur son LCP mobile en corrigeant un seul template PrestaShop : le carrousel de bannières de la home chargeait en bloc des images pleine résolution jamais affichées en grand. Une seule modification, 90 % des pages concernées passées au vert.
Tableau comparatif : quel outil pour quel usage
Les outils de mesure ne se remplacent pas. Ils se complètent.
| Outil | Type de données | Meilleur usage | Limite |
|---|---|---|---|
| PageSpeed Insights | Terrain + labo | Diagnostic initial d'une URL | Une URL à la fois |
| Search Console (rapport CWV) | Terrain (CrUX) | Vue d'ensemble par gabarit | Latence de 28 jours |
| Lighthouse (local) | Labo | Tests reproductibles, CI/CD | Environnement simulé |
| Web Vitals extension Chrome | Terrain (local) | Mesurer une session utilisateur réelle | Un seul utilisateur |
| CrUX Dashboard (BigQuery) | Terrain (CrUX) | Analyse fine par segment | Nécessite des compétences SQL |
L'extension Web Vitals pour Chrome est souvent négligée. Elle affiche en direct, dans le navigateur, les LCP / INP / CLS de la page que vous visitez, tels qu'un utilisateur réel les verrait — sans passer par la simulation Lighthouse. Pour reproduire un bug remonté par votre support, c'est l'outil le plus direct.
INP : le vrai chantier caché
La plupart des sites que j'audite depuis 2024 ont un INP problématique. La cause numéro un : trop de JavaScript tiers. Analytics, A/B testing, chat, pixels publicitaires, heatmaps. Chacun ajoute des listeners sur le thread principal. Additionnez cinq scripts de ce genre, et vous avez 400 ms de latence garantie sur mobile haut de gamme — bien plus sur un smartphone d'entrée de gamme.
Ma méthode : couper les scripts tiers qui ne servent pas activement. Pour ceux qui restent, les charger en async ou en defer, jamais dans le <head> bloquant. Et quand une interaction locale est lente, découper la tâche en morceaux de moins de 50 ms. Concrètement, yield to main thread après chaque gros calcul. Un tableur de données qui mettait 600 ms à filtrer : descendu à 90 ms après découpage.
CLS : trois règles, et c'est réglé
- Largeur/hauteur explicites sur toutes les images et iframes (ou
aspect-ratioen CSS) - Réserver l'espace des bannières publicitaires et des embeds avant leur chargement
- Ne jamais injecter de contenu au-dessus de contenu déjà affiché (les fameux bandeaux « cookie » ou « abonnez-vous » qui poussent le contenu)
Comment tester et suivre votre progression
Trois habitudes simples. Elles valent mieux qu'un audit trimestriel.
Premièrement, ouvrez PageSpeed Insights une fois par nouveau gabarit déployé. Pas pour chaque déploiement, pas toutes les semaines — chaque nouveau template. Et uniquement sur la version mobile, qui est celle qui compte en pratique.
Deuxièmement, surveillez le rapport Core Web Vitals dans Search Console à froid. Il se rafraîchit tous les 28 jours, donc consulter chaque jour ne sert à rien. Une fois par mois, vous comparez les statuts par groupe d'URL.
Troisièmement, automatisez. Intégrez Lighthouse CI à votre pipeline de déploiement, avec des budgets de performance. Si un LCP dépasse 2,5 s en labo, le build échoue. J'ai installé ça chez un média en ligne : deux mois après, les régressions de performance avaient chuté de 73 %. Les développeurs voient immédiatement quand un commit fait reculer les métriques.
Dernier point, important : les scores Google sont des moyennes. Un pageSpeed de 85 n'est pas une fin en soi. La question est : sur quelles pages et pour quels utilisateurs vous êtes vert. Une page critique qui passe au rouge pèse plus lourd qu'une page secondaire parfaite.
Faut-il tout refaire quand le score est mauvais ?
Non, presque jamais. La réponse réflexe — « on refait le site » — est rarement justifiée.
Dans la majorité des cas, corriger trois choses règle la situation :
- Les images du gabarit principal (dimensionnement, format, lazy loading sauf pour le LCP)
- Les scripts tiers bloquants chargés en
<head> - Le CSS critique, à inliner uniquement sur les pages au-dessus du fold
Un site que j'ai repris en 2025 : PageSpeed 41 sur mobile. Après ces trois correctifs étalés sur huit jours de dev, 89 sur mobile, 96 sur desktop. Aucune refonte. Aucun changement de framework. Juste un diagnostic propre et un travail chirurgical.
Et si votre CMS vous empêche de bouger ces leviers ? Là, oui, la refonte peut se discuter. Mais ce n'est pas la cause première de vos Core Web Vitals dégradés — c'est une limite à lever après avoir identifié ce qui cloche vraiment.
La vraie question n'est pas « comment avoir 100 sur PageSpeed ». C'est « comment être vert sur les gabarits qui comptent, pour les utilisateurs qui achètent ». Une fois que vous posez le problème comme ça, les priorités deviennent claires. Et le chantier devient faisable.
