Improving Core Web Vitals in Practice — How I Cut LCP from 3s to 1.2s

TASK 1 — post_id=80 / slug=core-web-vitals-optimization

TITLE_FR: Améliorer les Core Web Vitals en pratique — Comment j'ai fait passer le LCP de 3 s à 1,2 s

DESCRIPTION_FR: Le LCP (Largest Contentful Paint) influence directement le classement Google. En appliquant successivement l'optimisation des images, la stratégie de chargement des polices et le code splitting, le LCP est passé de 3,0 s à 1,2 s, et le CLS a chuté de 0,28 à 0,04.

CONTENT_MD_FR:

Résumé clé

• Le LCP (Largest Contentful Paint) est un indicateur central qui influence directement le classement dans la recherche Google.
• En appliquant successivement l'optimisation des images, la stratégie de chargement des polices et le code splitting, le LCP est passé de 3,0 secondes à 1,2 seconde.
• Le CLS a été amélioré de 0,28 à 0,04 en précisant des dimensions explicites pour les images et les zones publicitaires, supprimant ainsi les décalages de mise en page.
• Basé sur un projet Next.js en production réelle — les mêmes principes s'appliquent aux projets React et Vue.

Introduction — Pourquoi les Core Web Vitals ?

Lorsque Google a déployé la mise à jour Page Experience en 2021, les Core Web Vitals ont dépassé le simple statut de métriques d'expérience utilisateur pour devenir un facteur de classement SEO. Depuis, Google a continué d'augmenter le poids de ces signaux, et depuis 2024, le INP (Interaction to Next Paint) a totalement remplacé le FID comme métrique d'évaluation.

Un projet e-commerce que j'exploite affichait il y a à peine six mois un piètre score de 38 points sur PageSpeed Insights en version mobile. Le LCP était de 3,0 secondes, le CLS de 0,28, l'INP de 320 ms — les trois métriques dans la zone « À améliorer ». Cet article documente l'ensemble du processus de retournement de ces chiffres.

Comment comprendre rapidement les trois Core Web Vitals ?

LCP — La vitesse de la « première impression » d'une page

Le LCP mesure le temps nécessaire pour que le plus grand élément de contenu présent dans la fenêtre d'affichage (généralement l'image principale ou le titre H1) soit rendu. Le seuil fixé par Google est de 2,5 secondes ou moins pour Bon ; au-dessus de 4,0 secondes, c'est Faible.

Sur les sites e-commerce, l'image de bannière principale est très majoritairement la candidate au statut de LCP. Si cette seule image se charge trop lentement, toutes les autres optimisations deviennent inutiles.

CLS — La mise en page « saute »-t-elle ?

Le CLS (Cumulative Layout Shift) mesure à quel point les éléments se déplacent de façon inattendue pendant le chargement de la page. Les bandeaux publicitaires chargés tardivement ou les images sans dimensions explicites font monter le CLS en flèche. 0,1 ou moins est le seuil Bon.

INP — À quelle vitesse la page répond-elle aux entrées de l'utilisateur ?

Le INP mesure le délai de réponse pour toutes les interactions — clics, taps, frappes au clavier. Il a remplacé le FID en mars 2024, et 200 ms ou moins est le seuil Bon. Les gros bundles JavaScript bloquent le thread principal et dégradent l'INP.

Diagnostic du problème — Mesures initiales

Enregistrer précisément les métriques avant l'optimisation est le point de départ. Ces outils ont été utilisés dans l'ordre :

1. 1PageSpeed Insights — Fournit simultanément les données de terrain (données utilisateurs réelles) et les données de laboratoire (Lighthouse)
2. 2Chrome DevTools > onglet Performance — Inspecter la timeline de rendu et l'élément candidat LCP
3. 3WebPageTest — Mesure réelle depuis des serveurs CDN en périphérie, confirmation visuelle via filmstrip
4. 4Vercel Analytics / Sentry — Core Web Vitals collectés à partir des sessions utilisateurs réels

Le diagnostic a réduit les goulots d'étranglement à trois domaines :

• Image principale — JPEG de 4,2 Mo, inséré directement via balise sans aucune optimisation
• Google Fonts — 3 familles de polices chargées de manière synchrone via @import
• Taille du bundle — Chunk principal de 1,8 Mo, plusieurs bibliothèques incluses sans tree-shaking

Quelles ont été les trois méthodes qui ont fait passer le LCP de 3,0 s à 1,2 s ?

Méthode 1 — Optimisation des images et préchargement

Celle qui a eu le plus grand impact. La gestion de l'image principale a été entièrement repensée.

Avant

<img src="/banner.jpg" alt="Bannière principale" />

Après — Composant Image de Next.js + conversion WebP

import Image from 'next/image';

<Image
  src="/banner.webp"
  alt="Bannière principale"
  width={1920}
  height={800}
  priority          // Les images cibles LCP doivent toujours avoir priority
  quality={80}
  sizes="(max-width: 768px) 100vw, 1920px"
/>

Ajouter la prop priority à elle seule pousse Next.js à injecter automatiquement une balise pour l'image. Après conversion en WebP, la taille du fichier est passée de 4,2 Mo à 340 Ko — environ 92 % de réduction.

Pour les projets en pur HTML/React, ajoutez une balise preload directement dans :

<link
  rel="preload"
  as="image"
  href="/banner.webp"
  type="image/webp"
/>

Ce simple changement a fait baisser le LCP de 3,0 s à 1,8 s.

Méthode 2 — Stratégie de chargement des polices

Charger Google Fonts via @import force le navigateur à interrompre le parsing CSS pour faire une requête de police. Ce temps d'attente augmente substantiellement le LCP.

Avant

<style>
  @import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap');
</style>

Après — + display=swap + Self-hosting

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />


<link
  href="https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap"
  rel="stylesheet"
  media="print"
  onload="this.media='all'"
/>

Utiliser media="print" puis basculer sur media="all" au chargement permet de charger la feuille CSS des polices de manière asynchrone sans bloquer le rendu. display=swap affiche immédiatement une police de repli pendant que la police web se charge, gardant le texte visible.

Pour une performance maximale, héberger les polices localement supprime entièrement l'aller-retour vers Google Fonts :

@font-face {
  font-family: 'Inter';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url('/fonts/inter-regular.woff2') format('woff2');
}

Cette étape a ramené le LCP de 1,8 s à 1,4 s.

Méthode 3 — Code splitting et optimisation du bundle

Un chunk principal de 1,8 Mo signifie que les utilisateurs doivent télécharger et parser près de 2 Mo de JavaScript avant que la page ne devienne interactive.

Actions clés entreprises :

1. 1Imports dynamiques — Bibliothèques lourdes chargées uniquement au besoin :

// Avant : toujours chargé
import Chart from 'chart.js';

// Après : chargé seulement quand le composant chart est réellement rendu
const Chart = dynamic(() => import('chart.js'), { ssr: false });

1. 1Audit du tree-shaking — Remplacement de import _ from 'lodash' par des imports de fonctions individuelles :

// Avant : charge l'intégralité de la bibliothèque lodash
import _ from 'lodash';

// Après : charge uniquement debounce
import debounce from 'lodash/debounce';

1. 1Lazy loading des scripts tiers — Les scripts d'analytics et de widget de chat reportés pour se charger après que la page est interactive :

<script src="/analytics.js" defer></script>

Après l'optimisation du bundle, la taille du chunk principal est passée de 1,8 Mo à 620 Ko, et le LCP est passé de 1,4 s à 1,2 s.

Comment le CLS a-t-il été réduit de 0,28 à 0,04 ?

Les deux principaux fautifs du CLS étaient les publicités et les images sans dimensions explicites.

Zone publicitaire : réserver l'espace à l'avance

/* Réserver une hauteur minimale pour que le slot publicitaire ne provoque jamais de décalage */
.ad-container {
  min-height: 90px;  /* publicité de type bannière */
  min-width: 728px;
}

Images : toujours spécifier la largeur et la hauteur

/* Avant : pas de dimensions → cause un décalage de mise en page pendant le chargement */
<img src="/product.jpg" alt="Produit" />

/* Après : dimensions explicites → le navigateur réserve l'espace */
<Image
  src="/product.jpg"
  alt="Produit"
  width={400}
  height={300}
/>

Contenu dynamique : utiliser des placeholders

// Afficher un placeholder squelette pendant le chargement des données
{isLoading ? (
  <div className="h-48 bg-gray-200 animate-pulse rounded" />
) : (
  <ProductCard data={data} />
)}

Ces trois changements ont fait passer le CLS de 0,28 à 0,04.

Récapitulatif des résultats

Vérifiez les Core Web Vitals de votre propre site

Utilisez ces outils pour mesurer votre score actuel :

• Vérificateur PageSpeed — Consultez instantanément votre score PageSpeed Insights
• Vérificateur de balises Meta — Vérifiez simultanément la configuration SEO et OG

Questions fréquemment posées (FAQ)

Q1. Améliorer les Core Web Vitals augmente-t-il directement le classement dans la recherche ?

Les Core Web Vitals sont l'un des facteurs de classement officiels de Google. Google a publiquement confirmé qu'ils constituent un signal d'expérience de page. Cependant, d'autres facteurs comme la qualité du contenu et les liens entrants restent plus pesants ; l'amélioration des Core Web Vitals doit donc être considérée comme une condition nécessaire plutôt que comme une garantie.

Q2. Quelle métrique des Core Web Vitals a le plus d'impact sur le classement ?

Le LCP est le plus visible pour les utilisateurs et a l'impact le plus direct sur les taux de rebond, ce qui influence indirectement le classement. Le CLS affecte également directement l'expérience utilisateur, donc les deux sont des cibles de haute priorité. L'influence de l'INP en tant que métrique plus récente continue de se préciser.

Q3. Comment puis-je vérifier mon élément LCP ?

Ouvrez Chrome DevTools, allez dans l'onglet Performance, enregistrez un chargement de page, et cherchez « LCP » dans la timeline. Sinon, en lançant PageSpeed Insights, il vous dira exactement quel élément est candidat au LCP.

Q4. Google Fonts nuit-il aux Core Web Vitals ?

Oui. Charger Google Fonts via @import bloque le rendu et est une cause fréquente de dégradation du LCP. L'utilisation de combinée à display=swap ou l'hébergement local des polices est fortement recommandée.

Q5. Dans quelle mesure Next.js aide-t-il pour les Core Web Vitals ?

De manière très significative. Next.js propose l'optimisation automatique des images (conversion WebP, lazy loading, optimisation de taille), l'optimisation des polices intégrée (next/font) et le code splitting basé sur les routes, le tout en natif. À elles seules, ces fonctionnalités peuvent entraîner des améliorations spectaculaires des Core Web Vitals sans configuration supplémentaire.

Q6. À quelle fréquence faut-il vérifier les Core Web Vitals ?

Une surveillance au moins une fois par mois est recommandée. PageSpeed Insights reflète les données utilisateurs réels collectées sur les 28 derniers jours, donc les changements mettent du temps à apparaître. Utiliser Google Search Console pour suivre les tendances des données de terrain dans la durée est plus pratique que des mesures ponctuelles.