Optimiser les Core Web Vitals : guide pratique pour améliorer LCP, INP et CLS

Un site peut avoir un excellent contenu et quand même perdre du trafic parce qu'il paraît lent, mou ou instable. C’est exactement ce que mesurent les Core Web Vitals.

Quand l’élément principal arrive trop tard, que les clics répondent avec retard ou que la mise en page saute pendant le chargement, l’effet se voit tout de suite sur l’expérience utilisateur. Et, derrière, sur le SEO et la conversion.

Les Core Web Vitals, en clair

Google s’appuie sur trois signaux pour évaluer l’expérience de page. Ils ne racontent pas la même chose, et c’est justement pour ça qu’il faut les regarder ensemble.

1. LCP (Largest Contentful Paint)

Le LCP mesure le temps nécessaire pour afficher l’élément principal visible à l’écran. Dans la vraie vie, c’est souvent l’image hero, un visuel de bannière, une vidéo ou le premier gros bloc de texte.

La cible à garder en tête: 2,5 secondes ou moins.

2. INP (Interaction to Next Paint)

L’INP mesure la vitesse à laquelle la page réagit visuellement après une action réelle: clic, tap, ouverture d’un menu, saisie dans un champ.

Le bon repère aujourd’hui, c’est 200 ms ou moins.

3. CLS (Cumulative Layout Shift)

Le CLS mesure les déplacements de mise en page inattendus pendant le chargement ou après l’apparition d’un élément.

Le seuil visé est 0,1 ou moins. Au-delà, la page donne une impression brouillonne et peu fiable.

Comment mesurer sans tourner en rond

Avant de corriger quoi que ce soit, il faut savoir si le problème vient du rendu, du réseau, du JavaScript ou simplement d’une mauvaise hiérarchie de chargement.

1. Google Search Console et PageSpeed Insights

Le rapport Core Web Vitals dans Search Console te montre les groupes d’URL qui posent problème avec des données terrain. PageSpeed Insights est ensuite utile pour creuser une URL précise.

2. Lighthouse dans Chrome

Lighthouse reste l’outil le plus rapide pour comprendre:

• quel élément est pris comme LCP
• quels scripts monopolisent le thread principal
• quels fichiers ralentissent le rendu initial
• où les décalages de layout apparaissent

3. RUM (Real User Monitoring)

Les données labo ne racontent pas tout. Les appareils plus anciens, les réseaux mobiles, les scripts tiers et les variations de marché se voient surtout dans les données utilisateur réelles.

Pour prioriser côté SEO, tu peux aussi passer les pages concernées dans SEO Analyzer afin de repérer plus vite les URL qui méritent d’être traitées en premier.

Réduire le LCP: commence par les gros freins

Quand le LCP est mauvais, ce n’est pas le moment de micro-optimiser partout. Il faut traiter d’abord ce qui retarde l’élément principal.

1. Corrige l’image principale

Dans beaucoup de cas, le LCP est une image.

• préfère WebP ou AVIF
• sers des tailles adaptées via srcset ou <picture>
• compresse avant mise en ligne
• évite loading="lazy" sur l’image critique
• définis width et height

1<picture>
2  <source
3    srcset="hero-1200.webp 1200w, hero-800.webp 800w, hero-400.webp 400w"
4    type="image/webp"
5    sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
6  >
7  <source
8    srcset="hero-1200.jpg 1200w, hero-800.jpg 800w, hero-400.jpg 400w"
9    type="image/jpeg"
10    sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
11  >
12  <img src="hero-800.jpg" alt="Homepage hero image" width="1200" height="800" loading="eager">
13</picture>

2. Accélère la réponse serveur

Si le TTFB est lent, le navigateur attend avant même de pouvoir afficher quelque chose.

• active le cache quand c’est pertinent
• sers les ressources statiques via un CDN
• surveille les requêtes base de données lentes
• enlève la logique serveur lourde du chemin critique

3. Élimine les ressources bloquantes

Une partie des pages lentes le sont simplement parce qu’elles chargent trop de CSS, de polices et de JavaScript avant d’afficher le haut de page.

• inline le CSS critique
• charge les scripts non essentiels avec defer
• charge les scripts indépendants avec async
• retire les bibliothèques inutiles du chargement initial

1<head>
2  <link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
3  <script src="/js/main.js" defer></script>
4  <script src="https://analytics.example.com/script.js" async></script>
5</head>

4. Utilise preload avec mesure

preload aide beaucoup pour une image LCP ou une police vraiment essentielle. En abuser crée l’effet inverse.

Améliorer l’INP: la page doit répondre vite, pas seulement charger vite

Un INP médiocre signifie presque toujours que le thread principal a trop de travail.

1. Allège le JavaScript

• découpe les bundles volumineux
• charge certaines fonctions à la demande
• supprime le code mort
• évite d’hydrater trop tôt des composants secondaires

1document.querySelector('.open-chart').addEventListener('click', async () => {
2  const { renderChart } = await import('./chart-module.js');
3  renderChart();
4});

2. Fais le tri dans les scripts tiers

Widgets de chat, outils d’A/B test, pixels marketing, cartes, vidéos embarquées: c’est souvent là que la réactivité se dégrade.

Pose-toi ces questions:

• quel script a un vrai impact business
• lequel peut attendre le premier scroll ou la première interaction
• lequel peut tout simplement disparaître

3. Coupe les longues tâches

Une tâche JavaScript qui monopolise le thread principal trop longtemps bloque la réponse à l’utilisateur.

• découpe les traitements lourds
• utilise requestIdleCallback pour les tâches secondaires
• envoie les calculs coûteux dans un Web Worker

Réduire le CLS: rendre la page plus stable

Le CLS est souvent le résultat d’une accumulation de petits oublis.

1. Réserve l’espace pour les médias

Images, vidéos, iframes et embeds ont besoin d’une zone prévue à l’avance.

• ajoute width et height
• utilise aspect-ratio pour les blocs responsives
• prévois des conteneurs stables pour les embeds

2. Évite les insertions surprises

Barre promotionnelle, bannière cookie, module de recommandation chargé après coup: tout ça peut faire bouger la page au pire moment.

• réserve l’espace avant chargement
• utilise un overlay si tu ne veux rien pousser
• fixe une hauteur minimale aux emplacements pub

3. Soigne le chargement des polices

Les polices web peuvent provoquer des décalages visibles.

• précharge la police principale
• utilise font-display: swap
• choisis une police de secours proche visuellement

Exemple concret: quand la performance améliore aussi le business

Sur un site e-commerce avec une forte part de trafic mobile, les métriques de départ étaient les suivantes:

• LCP: 4,8 s
• INP: 180 ms
• CLS: 0,25
• conversion: 1,2 %
• rebond: 65 %

Les optimisations mises en place:

1. passage des visuels principaux en WebP
2. dimensions fixes pour les images et les espaces pub
3. chargement différé des scripts analytics et pub
4. préchargement des images hero clés
5. réduction du CSS critique
6. diffusion des assets via CDN
7. ajustement des polices avec font-display: swap

Après optimisation:

• LCP: 1,9 s
• INP: 65 ms
• CLS: 0,08
• conversion: 2,8 %
• rebond: 42 %

Pas d’effet miracle. Juste une bonne hiérarchie des priorités.

Ce qu’il faut mettre en place sur la durée

Les Core Web Vitals se dégradent souvent petit à petit, au fil des nouveaux scripts, des nouvelles sections ou des changements de template.

1. Mettre en place un suivi continu

Search Console, les données RUM et les modèles de pages stratégiques doivent être suivis régulièrement.

2. Définir des budgets de performance

Fixe des limites sur:

• le poids total du JavaScript
• la taille maximale des images
• le nombre de polices chargées
• le nombre de scripts tiers

3. Intégrer la performance dans le workflow

Une landing, un redesign ou une nouvelle feature devrait toujours passer par un mini contrôle LCP, INP et CLS avant mise en ligne.

4. Faire monter toute l’équipe en compétence

Le sujet ne concerne pas seulement les développeurs. Le design, le contenu et le marketing influencent eux aussi ces métriques.

À retenir

• LCP se travaille surtout via la ressource principale, le serveur et le chemin critique.
• INP dépend beaucoup de la charge JavaScript sur le thread principal.
• CLS baisse quand l’espace est prévu à l’avance et que l’interface ne bouge plus par surprise.
• Les données terrain comptent plus que les scores labo isolés.
• Le vrai but n’est pas d’avoir un joli rapport, mais des pages plus fluides et plus rentables.

Si tu veux repérer rapidement quelles URL perdent le plus à cause de la performance, commence par un passage dans SEO Analyzer, puis affine avec Lighthouse et les données utilisateurs réelles.