Core Web Vitals : comment améliorer ses scores rapidement

Le score Core Web Vitals de votre site est passé au rouge et vous ne savez pas par quel bout le prendre. Je connais cette sensation. J'ai vu un de mes projets passer de 34 à 91 sur mobile en trois semaines — et j'ai aussi vu un site que je pensais irréprochable stagner pendant quatre mois parce que je corrigeais les mauvaises choses. Franchement, dans 8 cas sur 10, le problème n'est pas le nombre de correctifs. C'est la priorisation.

Alors, comment améliorer ses scores Core Web Vitals sans y passer six mois ? Voici ce que j'ai appris en me cassant les dents dessus, chiffres à l'appui.

Comprendre vos scores Core Web Vitals avant de toucher à quoi que ce soit

La première erreur que je vois partout : ouvrir PageSpeed Insights, voir un 42 rouge, paniquer, et demander à son développeur de « tout optimiser ». J'ai fait exactement ça sur un site e-commerce en 2024. Résultat : trois semaines de travail, 400 euros facturés, et un score réel qui n'avait pas bougé.

Pourquoi ? Parce que j'avais optimisé pour Lighthouse. Et Lighthouse, c'est de la donnée de labo. Une simulation dans un environnement contrôlé, sur un seul run, avec une connexion théorique. Google, lui, s'appuie sur les données de terrain — le CrUX, agrégées sur 28 jours à partir d'utilisateurs réels, sur leurs vrais appareils, avec leur vraie connexion pourrie dans le métro.

La différence terrain / labo que personne n'explique

Un score Lighthouse de 95 peut très bien cohabiter avec un LCP terrain de 3,8 s. Je l'ai constaté sur un site de presse : parfait sur desktop, catastrophique sur mobile parce que le JavaScript tiers des pubs s'exécutait uniquement sur les appareils réels. Lighthouse ne simulait pas ce tiers correctement.

Concrètement :

• Lighthouse / PageSpeed Insights (labo) : utile pour diagnostiquer, pas pour juger.
• Search Console → Rapport sur les Core Web Vitals : c'est votre source de vérité SEO.
• CrUX Dashboard / API : données de terrain brutes, agrégées.
• web-vitals en JavaScript : pour vos propres utilisateurs, en temps réel, si vous voulez descendre au niveau du détail.

Si vous ne retenez qu'une chose : Google juge sur le terrain. Tout le reste n'est qu'indice.

Les trois métriques, leurs seuils et ce qu'elles mesurent vraiment

Métrique	Seuil « bon »	Ce qu'elle mesure réellement	Cause n°1 des mauvais scores
LCP	< 2,5 s	Le moment où le plus gros élément visible s'affiche	Image principale mal servie, serveur lent
INP	< 200 ms	La réactivité aux clics et aux interactions	Tâches JavaScript longues sur le thread principal
CLS	< 0,1	Le décalage visuel pendant le chargement	Images sans dimensions, polices qui swap, pubs qui poussent

Le INP a remplacé le FID en mars 2024. Et je vois encore des articles de blog qui parlent du FID comme si c'était encore la métrique active. Franchement, ça fait mal. Le FID ne mesurait que la première interaction. L'INP mesure toutes les interactions, du premier clic au dernier. C'est brutalement plus exigeant.

Améliorer le score LCP : 80 % du problème se règle sur trois leviers

Le LCP, c'est la métrique la plus lourde à bouger — mais aussi la plus gratifiante. Sur mon dernier projet client, je l'ai fait passer de 4,1 s à 1,7 s en 12 jours, et la position moyenne sur trois requêtes commerciales a grimpé de 3 rangs. Corrélation ? Probablement partielle. Mais je prends.

Voici les trois leviers qui comptent, dans l'ordre.

Levier 1 : votre serveur respire-t-il ?

Avant toute optimisation front-end, testez votre TTFB (Time To First Byte). S'il dépasse 800 ms, arrêtez tout et changez d'hébergement ou activez un CDN. J'ai perdu une semaine à optimiser des images sur un site dont le serveur mettait 2,3 secondes à répondre. Ridicule.

Ce qui marche réellement :

1. Un CDN devant tout (Cloudflare, Bunny, Fastly — peu importe, du moment qu'il cache)
2. Le cache de page au niveau serveur (pour WordPress : WP Rocket, LiteSpeed Cache ou un Varnish)
3. Une base de données correctement indexée si vous avez du contenu dynamique

Levier 2 : l'image LCP se prépare comme un plat

Dans 90 % des cas, l'élément LCP est une image. Trois réglages, pas plus :

• Format : WebP ou AVIF. Un JPEG de 400 Ko qui devient un AVIF de 60 Ko, c'est un LCP qui descend d'une seconde sur mobile.
• Attribut fetchpriority="high" sur cette image précise, et rien d'autre. Pas sur toutes les images, ça n'a aucun sens.
• Preload dans le <head> si l'image se trouve plus bas dans le HTML ou est injectée par JavaScript.

Attention : si vous servez vos images via un CDN d'images (Cloudinary, Imgix, le CDN natif de Shopify), le preload devient souvent inutile et peut même nuire. Testez.

Levier 3 : le CSS critique, mais pas trop

Le CSS bloquant fait attendre le premier rendu. Inliner le above the fold et différer le reste est la technique classique. Attention au piège : j'ai vu des sites avec 80 Ko de CSS inliné dans le <head>, ce qui dégrade le LCP au lieu de l'améliorer. La cible raisonnable est 14 à 20 Ko de CSS critique. Au-delà, vous vous tirez une balle dans le pied.

Améliorer le score INP : le chantier que tout le monde néglige

L'INP est la métrique la plus difficile à faire bouger, et paradoxalement celle sur laquelle je vois le moins d'actions concrètes. Pourquoi ? Parce que le problème est rarement visible. Un site peut avoir un LCP parfait et un INP de 420 ms. Et l'utilisateur, lui, ne dit rien — il part.

Sur un projet SaaS que j'ai repris l'an dernier, l'INP était à 380 ms. On a mis deux semaines à identifier le coupable : un script d'A/B testing qui recalculait tout le DOM à chaque scroll. En le passant en requestIdleCallback, l'INP est tombé à 180 ms. Le taux de conversion sur le formulaire d'inscription a suivi (+ 12 %).

Les techniques qui marchent vraiment

• Découper les longues tâches avec scheduler.yield() ou en fractionnant avec setTimeout / requestIdleCallback
• Déplacer le JS non critique en Web Worker (calculs, parsing lourd)
• Réduire les listeners passifs : un scroll ou touchmove non passif bloque le thread principal
• Charger les scripts tiers après interaction (analytics, chat, pubs) — c'est le gain le plus rapide
• Éviter les frameworks réactifs sur du contenu statique. Oui, je le dis : charger React pour afficher une page d'article, c'est du gâchis d'INP.

Si vous voulez identifier précisément ce qui plombe votre INP, utilisez l'onglet Performance de Chrome DevTools avec un enregistrement de Interaction to Next Paint. C'est cinq minutes de setup, et ça évite des jours d'aveuglement.

Améliorer le score CLS : le gain le plus rapide, souvent en une après-midi

Bonne nouvelle : le CLS est la métrique la plus simple à corriger quand on sait où regarder. La mauvaise : beaucoup de développeurs pensent que c'est de la faute du CSS alors que c'est presque toujours celle des ressources qui arrivent sans dimensions réservées.

Trois causes, dans 95 % des cas :

1. Une image sans width et height explicites (ou sans ratio défini)
2. Une police web chargée avec font-display: swap qui fait bouger le texte (ou l'inverse, un flash invisible)
3. Un bandeau pub, un widget de chat ou une bannière cookies injectée en JavaScript

Les correctifs, dans l'ordre d'efficacité :

• Attributs width/height sur toute image. Toujours. Sans exception.
• font-display: optional plutôt que swap si vous voulez zéro CLS sur les polices — quitte à perdre la police custom sur connexion lente.
• min-height réservé sur les conteneurs qui reçoivent du contenu dynamique (pubs, embeds, commentaires).
• Aspect-ratio en CSS pour les vidéos et iframes.

Sur un site vitrine, j'ai ramené un CLS de 0,34 à 0,02 en 40 minutes. La cause ? Une bannière newsletter qui s'injectait en haut de page après deux secondes. Un simple min-height a tout réglé.

Core Web Vitals par CMS : WordPress, Shopify, Next.js — ce qui change vraiment

Je vois trop de guides génériques qui listent des conseils valables pour un site custom, puis les balancent tels quels à un utilisateur WordPress. Ça ne marche pas. Chaque stack a ses points faibles propres.

WordPress : plugins, cache, et le fléau des builders

Le premier coupable sur WordPress n'est pas WordPress. C'est Elementor, Divi ou WPBakery. Ces builders ajoutent du CSS et du JS monstrueux qui plombent l'INP. J'ai mesuré un site Elementor avec 2,1 Mo de CSS non compressé. Inadmissible.

Plan d'action :

• Cache de page + cache navigateur (WP Rocket, LiteSpeed, FlyingPress — à tester selon votre hébergeur)
• WebP automatique (Imagify, ShortPixel, ou le module natif de votre CDN)
• Désactiver les plugins inutilisés — vraiment. Dix plugins désactivés, c'est souvent 300 ms d'INP en moins.
• Si vous êtes sur un builder lourd, envisagez Gutenberg ou un thème orienté performance (GeneratePress, Kadence, Bricks).

Shopify : les apps sont votre pire ennemi

Shopify gère bien mieux son infrastructure qu'on ne le croit — le LCP côté serveur est rarement le problème. Non, le vrai souci, ce sont les apps tierces installées sans réfléchir. Chaque app ajoute son JS, et vous vous retrouvez avec 18 scripts qui se battent pour le thread principal.

Auditez vos apps tous les six mois. Virez tout ce qui n'est pas utilisé en production. Et privilégiez le thème Dawn ou les thèmes récents « Online Store 2.0 », qui sont conçus avec les Core Web Vitals en tête.

Next.js : maîtriser le rendu, ou subir

Next.js offre de très bonnes bases (streaming SSR, next/image, next/script avec stratégies de chargement). Mais mal configuré, il peut être catastrophique. J'ai vu une app Next.js entièrement rendue en client-side avec un LCP de 6 secondes. Douze lignes de refactoring pour basculer la page d'accueil en Server Components : LCP à 2,1 s. Le gain le plus simple de ma carrière.

Questions qu'on me pose souvent sur les Core Web Vitals

Est-ce que vraiment ça aide le SEO, ou c'est du marketing ?

Oui, ça aide, mais pas comme on l'imagine. Les Core Web Vitals sont un critère d'arbitrage, pas un facteur principal. Entre deux pages de qualité équivalente, celle avec de meilleurs scores passe devant. Mais si votre contenu est faible, un LCP à 1,2 s ne vous sauvera pas. J'ai longtemps cru l'inverse. C'était naïf.

Combien de temps avant que mes scores remontent ?

Techniquement, dès que vos utilisateurs naviguent sur la version corrigée, les données CrUX commencent à se mettre à jour. En pratique, comptez 28 jours — c'est la fenêtre d'agrégation. Sur Search Console, parfois un peu plus, le temps que le rapport se rafraîchisse. Si vous attendez une remontée en trois jours, vous allez vous impatienter pour rien.

Faut-il mesurer avec plusieurs outils ?

Un seul suffit si vous prenez les bons. Search Console pour les données terrain, PageSpeed Insights pour croiser les deux sources et diagnostiquer, et l'onglet Performance de DevTools pour descendre dans le code. Trois outils, c'est le maximum utile. Au-delà, on accumule des chiffres contradictoires et on ne décide plus rien.

Tout est rouge, par quoi je commence ?

Ordre de priorité, selon ce que j'ai vu fonctionner :

1. CLS — le plus rapide, souvent en moins d'une journée
2. LCP — image principale + serveur + CSS critique, une semaine environ
3. INP — le plus long, à traiter en continu (audit des scripts, découpage)

Et un conseil : corrigez une métrique à la fois, pas les trois en parallèle. Sinon, vous ne saurez jamais ce qui a produit le gain — ni ce qui l'a cassé.

Ce qui reste, une fois les scores au vert

Améliorer ses scores Core Web Vitals, c'est comme entretenir une voiture : on ne le fait pas une fois pour toutes. Déployer une nouvelle feature, installer une nouvelle app, ajouter un script marketing — et votre INP peut repartir à la hausse en une semaine.

Ce que j'ai fini par comprendre, après plusieurs cycles, c'est que le vrai enjeu n'est pas le score. C'est la discipline. Mettre en place un monitoring continu (une petite tâche qui enregistre le LCP, l'INP et le CLS réels de vos visiteurs), se fixer un seuil d'alerte, et traiter la dérive avant qu'elle ne devienne un chantier.

Un site qui passe de 34 à 91, puis retombe à 62 six mois plus tard, c'est un site qui n'a pas de processus. Et le meilleur score du monde ne sert à rien s'il ne tient pas.