Les Core Web Vitals sont devenus un facteur de ranking Google incontournable. Comme nous l'expliquons dans notre article sur pourquoi les sites rapides rankent mieux, ces métriques mesurent l'expérience utilisateur réelle de votre site. Dans ce guide technique, nous détaillons les optimisations concrètes pour améliorer chacune des trois métriques : LCP, INP et CLS.

Rappel : les trois Core Web Vitals

Avant de plonger dans les optimisations, rappelons rapidement les seuils à atteindre :

LCP (Largest Contentful Paint) : moins de 2,5 secondes — mesure la vitesse de chargement perçue.
INP (Interaction to Next Paint) : moins de 200 millisecondes — mesure la réactivité aux interactions.
CLS (Cumulative Layout Shift) : moins de 0,1 — mesure la stabilité visuelle de la page.

Améliorer le LCP (Largest Contentful Paint)

Le LCP est souvent la métrique la plus problématique. Il dépend de plusieurs facteurs : le temps de réponse du serveur, le chargement des ressources critiques, et le rendu côté client.

1. Optimiser les images

L'élément LCP est fréquemment une image hero ou une bannière. Voici les optimisations essentielles :

Format moderne : utilisez WebP ou AVIF au lieu de JPEG/PNG. Le gain de poids est de 25 à 50 % sans perte visible de qualité. Pour les sites WordPress, notre plugin H1Site WebP Converter automatise cette conversion.
Dimensionnement correct : ne servez pas une image de 4000 px de large si elle s'affiche à 800 px. Utilisez l'attribut srcset et l'attribut sizes pour servir la bonne taille selon le viewport.
Preload l'image LCP : ajoutez <link rel="preload" as="image" href="..."> dans le <head> pour l'image LCP. Cela indique au navigateur de commencer à la télécharger immédiatement, sans attendre que le CSS ou le JavaScript la découvre.
Ne pas lazy-load l'image LCP : le lazy loading est excellent pour les images sous le fold, mais l'image LCP doit charger immédiatement. Ajoutez loading="eager" et fetchpriority="high".
Utiliser un CDN d'images : des services comme Cloudinary, imgix ou le CDN de Vercel optimisent et servent les images depuis des serveurs proches de l'utilisateur.

2. Optimiser les polices de caractères

Les polices web peuvent bloquer le rendu du texte et retarder le LCP.

font-display: swap : cette propriété CSS affiche immédiatement le texte avec une police système de remplacement, puis bascule vers la police web quand elle est chargée. Le texte est visible dès le début, ce qui améliore le LCP.
Preload les polices critiques : ajoutez <link rel="preload" as="font" type="font/woff2" crossorigin href="..."> pour les polices utilisées au-dessus du fold.
Héberger les polices localement : plutôt que d'utiliser Google Fonts via leur CDN (qui ajoute une connexion DNS supplémentaire), téléchargez les fichiers de polices et servez-les depuis votre domaine.
Limiter le nombre de polices : chaque police supplémentaire (et chaque variante de poids) ajoute des kilo-octets. Limitez-vous à 2 polices et 3 à 4 variantes de poids maximum.

3. Réduire le temps de réponse serveur (TTFB)

Le Time to First Byte est le fondement du LCP. Si votre serveur met 2 secondes à répondre, votre LCP ne peut pas être en dessous de 2 secondes.

Choisir un hébergement performant : un hébergement mutualisé à 5 $/mois ne peut pas rivaliser avec un hébergement optimisé. Comme nous l'expliquons dans notre article sur les raisons d'un site lent, l'hébergement cheap est la première cause de lenteur.
Activer le cache serveur : pour WordPress, utilisez un plugin de cache (WP Rocket, LiteSpeed Cache). Pour Next.js, le SSG et l'ISR garantissent un TTFB minimal grâce au CDN.
Utiliser un CDN : un Content Delivery Network sert les pages depuis un serveur géographiquement proche de l'utilisateur. Cloudflare (gratuit) ou Vercel Edge Network réduisent le TTFB de façon significative.
Optimiser les requêtes base de données : pour WordPress, ajoutez des index, nettoyez les tables inutiles (revisions, transients), et utilisez un cache objet (Redis, Memcached).

4. Éliminer les ressources bloquant le rendu

CSS critique inline : intégrez le CSS nécessaire pour le contenu au-dessus du fold directement dans le HTML. Différez le chargement du reste du CSS.
Defer/async JavaScript : ajoutez defer ou async aux balises script qui ne sont pas critiques pour le rendu initial.
Réduire les chaînes de requêtes critiques : minimisez le nombre de ressources qui doivent se charger séquentiellement avant que le contenu ne s'affiche.

Améliorer l'INP (Interaction to Next Paint)

L'INP mesure le temps entre une interaction utilisateur (clic, tap, touche clavier) et la mise à jour visuelle qui en résulte. Un INP élevé signifie que votre site semble non réactif.

1. Réduire le JavaScript principal

Code splitting : divisez votre JavaScript en morceaux chargés à la demande. Avec Next.js, le code splitting est automatique par page. Avec webpack, utilisez import() dynamique.
Tree shaking : éliminez le code JavaScript inutilisé. Les bundlers modernes (webpack, esbuild, SWC) le font automatiquement si vous utilisez des imports ES modules.
Auditer les dépendances : vérifiez la taille de chaque package npm avec des outils comme bundlephobia.com. Remplacez les bibliothèques lourdes par des alternatives légères (par exemple, day.js au lieu de moment.js).
Minifier et compresser : minifiez votre JavaScript (Terser, SWC) et servez-le compressé en Brotli ou Gzip.

2. Optimiser les event handlers

Éviter les long tasks : une « long task » est une tâche JavaScript qui dure plus de 50 ms et bloque le thread principal. Découpez les traitements lourds en morceaux plus petits avec requestAnimationFrame, requestIdleCallback ou scheduler.yield().
Debounce et throttle : pour les événements fréquents (scroll, resize, input), utilisez le debounce ou le throttle pour limiter le nombre d'exécutions.
Déplacer le travail hors du thread principal : utilisez les Web Workers pour les calculs intensifs. Le thread principal reste libre de répondre aux interactions.
Éviter les forced reflows : les lectures de layout suivies d'écritures (par exemple, lire offsetHeight puis modifier le style) forcent le navigateur à recalculer le layout de manière synchrone.

3. Réduire l'impact des scripts tiers

Charger les scripts tiers en différé : Google Analytics, chatbots, pixels publicitaires — chargez-les après le contenu principal avec defer ou via un chargement dynamique après l'interaction.
Utiliser un gestionnaire de consentement léger : les bannières de cookies mal implémentées peuvent bloquer le thread principal pendant des centaines de millisecondes.
Limiter le nombre de scripts tiers : chaque script tiers ajoute du poids et du travail JavaScript. Auditez régulièrement et supprimez ceux qui ne sont plus utilisés.

Améliorer le CLS (Cumulative Layout Shift)

Le CLS mesure les décalages visuels inattendus. Un bon CLS donne l'impression d'une page stable et professionnelle.

1. Définir les dimensions des images et vidéos

Attributs width et height : ajoutez toujours les attributs width et height sur vos balises <img> et <video>. Cela permet au navigateur de réserver l'espace avant le chargement.
CSS aspect-ratio : utilisez la propriété CSS aspect-ratio pour les conteneurs d'images et de vidéos responsives. Exemple : aspect-ratio: 16/9.
Next.js Image component : le composant <Image> de Next.js gère automatiquement les dimensions et le placeholder, éliminant le CLS lié aux images.

2. Gérer les polices web sans décalage

font-display: optional : si la police web ne charge pas assez vite, le navigateur garde la police système. Zéro décalage, mais la police custom peut ne pas s'afficher sur les premières visites.
Polices avec métriques similaires : choisissez des polices de remplacement dont les métriques (largeur des caractères, hauteur de ligne) sont proches de votre police web. Next.js fait cela automatiquement avec le module next/font.
Précharger les polices : un preload des polices critiques réduit le délai de swap et minimise le décalage.

3. Réserver l'espace pour le contenu dynamique

Publicités et iframes : définissez une taille fixe pour les conteneurs de publicités. Si une publicité ne charge pas, l'espace reste réservé. Utilisez min-height pour prévenir les effondrements.
Contenu chargé dynamiquement : si vous injectez du contenu via JavaScript (carrousels, notifications, barres de cookie), réservez l'espace dans le layout CSS avant le chargement.
Éviter les insertions au-dessus du fold : n'insérez jamais du contenu dynamique au-dessus du contenu visible. Les notifications et bannières doivent apparaître en overlay ou être pré-réservées dans le layout.

4. Animations et transitions

Utiliser transform au lieu de top/left : les animations CSS basées sur transform et opacity ne déclenchent pas de recalcul de layout. Les animations basées sur top, left, width, height causent du CLS.
CSS contain : la propriété contain: layout isole un élément du reste du layout. Les changements à l'intérieur de cet élément n'affectent pas le reste de la page.

Outils de mesure et de diagnostic

Données de terrain (Field Data)

Les données de terrain reflètent l'expérience des vrais utilisateurs. Ce sont ces données que Google utilise pour le ranking.

Google Search Console : rapport « Expérience sur la page » — montre les URLs qui échouent ou réussissent les Core Web Vitals.
PageSpeed Insights : la section « Données de terrain » affiche les métriques CrUX pour votre URL.
CrUX Dashboard : un tableau de bord Google Data Studio basé sur les données CrUX — permet de suivre l'évolution dans le temps.
web-vitals.js : bibliothèque JavaScript de Google pour mesurer les Core Web Vitals en temps réel sur votre site et envoyer les données à votre outil d'analytics.

Données de laboratoire (Lab Data)

Les données de laboratoire sont utiles pour diagnostiquer et tester les optimisations dans un environnement contrôlé.

Lighthouse : audit complet dans Chrome DevTools. Simule un appareil mobile avec une connexion lente.
WebPageTest : test détaillé avec waterfall chart et filmstrip. Permet de tester depuis différentes localisations.
Chrome DevTools Performance : enregistrement en temps réel du chargement. Identifie les long tasks, les forced reflows et les layout shifts.

Optimisations par plateforme

WordPress

WordPress nécessite des plugins et des configurations spécifiques pour de bons Core Web Vitals.

Cache : WP Rocket ou LiteSpeed Cache pour le cache page, le cache navigateur et la minification.
Images : notre plugin H1Site WebP Converter pour la conversion automatique en WebP. Smush ou ShortPixel pour la compression.
JavaScript : WP Rocket offre le delay JavaScript et le remove unused CSS. Perfmatters est une alternative légère.
Hébergement : Kinsta, Cloudways ou WP Engine pour un TTFB acceptable. Évitez l'hébergement mutualisé.
Thème : utilisez un thème léger (GeneratePress, Astra, Kadence). Évitez les thèmes multipurpose surchargés.
Plugins : limitez à 15-20 plugins maximum. Chaque plugin ajoute du CSS, du JavaScript et des requêtes SQL.

Next.js

Next.js offre d'excellents Core Web Vitals par défaut, mais quelques optimisations supplémentaires peuvent faire la différence.

Images : utilisez le composant <Image> pour l'optimisation automatique. Ajoutez priority sur l'image LCP.
Polices : utilisez next/font pour l'hébergement local automatique et l'élimination du CLS de swap de polices.
SSG/ISR : privilégiez la génération statique pour les pages de contenu. L'ISR permet la mise à jour sans rebuild complet.
Server Components : les React Server Components réduisent le JavaScript envoyé au client. Gardez les composants interactifs ("use client") au minimum.
Scripts tiers : utilisez le composant <Script> de Next.js avec strategy="lazyOnload" pour différer le chargement des scripts non critiques.
Bundle analyzer : utilisez @next/bundle-analyzer pour identifier les packages lourds et les optimiser.

Shopify

Shopify limite les optimisations côté serveur, mais plusieurs leviers restent accessibles.

Thème : utilisez un thème léger comme Dawn (thème par défaut Shopify 2.0). Évitez les thèmes tiers surchargés.
Apps : chaque app Shopify injecte du JavaScript. Limitez les apps installées et auditez régulièrement leur impact.
Images : Shopify optimise automatiquement les images via son CDN (format WebP, redimensionnement). Mais assurez-vous d'uploader des images de taille raisonnable.
Liquid : optimisez le code Liquid pour réduire les boucles inutiles et les requêtes API dans les templates.
Lazy loading : appliquez le lazy loading natif sur les images et vidéos sous le fold. Évitez-le sur les images hero.
Préchargement : utilisez les balises <link rel="preload"> dans le theme.liquid pour les ressources critiques.

Plan d'action : par où commencer ?

Si vous ne savez pas par où commencer, voici un plan d'action par ordre de priorité :

Mesurez d'abord : exécutez un audit PageSpeed Insights et notez vos scores LCP, INP et CLS actuels. Identifiez la métrique la plus problématique.
LCP en priorité : c'est la métrique qui échoue le plus souvent. Commencez par optimiser l'image LCP et le TTFB.
CLS ensuite : ajoutez les dimensions aux images et vidéos, corrigez le font swap, et réservez l'espace pour le contenu dynamique.
INP en dernier : auditez le JavaScript, réduisez les long tasks, et différez les scripts tiers.
Mesurez à nouveau : après chaque série d'optimisations, re-testez et comparez. Les données de terrain prennent 28 jours pour se mettre à jour dans CrUX.

Conclusion

Améliorer les Core Web Vitals n'est pas un projet ponctuel — c'est une pratique continue. Les optimisations décrites dans cet article peuvent transformer un site avec un score PageSpeed de 30 en un site à 90+. L'impact sur votre SEO, votre taux de conversion et l'expérience de vos utilisateurs est mesurable et significatif.

Si vous avez besoin d'aide pour diagnostiquer et optimiser la performance de votre site, notre équipe chez H1Site peut réaliser un audit complet et implémenter les optimisations. Que votre site soit sur WordPress, Next.js, Shopify ou une autre plateforme, contactez-nous pour une évaluation gratuite.

Comment améliorer les Core Web Vitals de votre site web