Core Web Vitals : Mesurez et améliorez la performance web
Vous avez construit une application web moderne, mais les utilisateurs se plaignent de lenteur. Les classements dans les moteurs de recherche pourraient aussi en souffrir. Les Core Web Vitals (CWV) sont les métriques de Google pour l'expérience utilisateur : Largest Contentful Paint (LCP), Interaction to Next Paint (INP) et Cumulative Layout Shift (CLS). Ce guide vous montre comment les mesurer avec précision et les améliorer efficacement.
Que sont les Core Web Vitals ?
Les Core Web Vitals sont trois métriques qui quantifient des aspects clés de l'expérience utilisateur :
- LCP mesure la performance de chargement. Il indique quand le plus grand élément de contenu (image, bloc de texte, vidéo) devient visible. Visez ≤2,5 secondes.
- INP mesure la réactivité. Il capture la latence de toutes les interactions (clics, taps, pressions de touches) et rapporte le délai le plus défavorable (ou presque). Visez ≤200 millisecondes.
- CLS mesure la stabilité visuelle. Il quantifie les décalages de mise en page inattendus pendant le chargement. Visez ≤0,1.
Ces métriques sont mesurées sur le terrain (à partir d'utilisateurs réels) et en laboratoire (dans des environnements contrôlés). Les deux comptent.
Comment mesurer les Core Web Vitals
Vous avez besoin de données de terrain et de laboratoire pour diagnostiquer les problèmes.
Données de terrain (Real User Monitoring)
Les données de terrain reflètent les expériences réelles des utilisateurs sur différents appareils et réseaux. Utilisez ces sources :
- Chrome User Experience Report (CrUX) : Ensemble de données public de métriques d'utilisateurs réels pour des millions de sites. Accessible via PageSpeed Insights ou l'API CrUX.
- Google Search Console : Le rapport Core Web Vitals montre les groupes d'URL qui nécessitent une attention basée sur les données CrUX.
- Bibliothèque JavaScript Web Vitals : Ajoutez la bibliothèque
web-vitalsà votre site et envoyez les mesures à votre point de terminaison d'analyse.
import {onLCP, onINP, onCLS} from 'web-vitals';
function sendToAnalytics(metric) {
const body = JSON.stringify(metric);
navigator.sendBeacon('/analytics', body);
}
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);
Données de laboratoire (tests synthétiques)
Les outils de laboratoire simulent le chargement dans un environnement contrôlé, ce qui les rend idéaux pour le débogage et l'intégration CI.
- Lighthouse : Intégré à Chrome DevTools, disponible en CLI et intégré à PageSpeed Insights. Il rapporte les métriques de laboratoire et les opportunités.
- WebPageTest : Tests avancés avec des conditions réseau personnalisées et des filmstrips.
- Panneau Performance de Chrome DevTools : Enregistrez et analysez les performances d'exécution, y compris les tâches longues qui affectent l'INP.
Bonne pratique : Utilisez les données de laboratoire pour identifier les correctifs et les données de terrain pour valider l'impact.
Améliorer le Largest Contentful Paint (LCP)
Le LCP est généralement dominé par l'image principale ou un grand bloc de texte. Optimisez ces éléments :
- Optimisez la ressource LCP : Compressez les images (utilisez WebP/AVIF), servez des tailles responsives avec
srcsetet préchargez l'image LCP si elle est critique. - Éliminez les ressources bloquant le rendu : Intégrez le CSS critique, différez le CSS et le JavaScript non critiques.
- Améliorez le temps de réponse du serveur (TTFB) : Utilisez un CDN, activez la mise en cache et optimisez les requêtes backend.
- Réduisez le rendu côté client : Pour les SPA, envisagez le rendu côté serveur (SSR) ou la génération statique pour la vue initiale.
Exemple : Préchargez l'image LCP :
<link rel="preload" as="image" href="/hero.avif" imagesrcset="/hero-480.avif 480w, /hero-800.avif 800w" imagesizes="(max-width: 600px) 480px, 800px">
Améliorer l'Interaction to Next Paint (INP)
L'INP mesure le délai entre une interaction utilisateur et la prochaine peinture. Les tâches longues et le JavaScript lourd sont des causes courantes.
- Divisez les tâches longues : Utilisez
setTimeout,requestIdleCallbackou l'API scheduler pour céder la main au thread principal. - Optimisez les gestionnaires d'événements : Déboncez ou throttlez les gestionnaires coûteux ; évitez le layout thrashing.
- Réduisez le temps d'exécution JavaScript : Faites du code-splitting, du tree-shaking et différez les scripts non critiques.
- Utilisez des web workers pour les tâches gourmandes en CPU.
Exemple : Cédez la main au thread principal :
async function yieldToMain() {
if ('scheduler' in window && 'yield' in scheduler) {
return scheduler.yield();
}
return new Promise(resolve => setTimeout(resolve, 0));
}
async function handleClick() {
// ... faire du travail
await yieldToMain();
// ... continuer
}
Améliorer le Cumulative Layout Shift (CLS)
Le CLS se produit lorsque des éléments se décalent de manière inattendue. Prévenez-le en :
- Incluant toujours les attributs width et height sur les images et vidéos, ou en utilisant
aspect-ratioen CSS. - Réservant de l'espace pour le contenu dynamique (publicités, intégrations, iframes) avec min-height ou des placeholders.
- Évitant d'insérer du contenu au-dessus du contenu existant sauf si déclenché par une interaction utilisateur.
- Utilisant
font-display: optionalou en préchargeant les polices pour éviter les décalages FOIT/FOUT.
Exemple : Réservez de l'espace pour une publicité :
<div>
<!-- la publicité se charge ici -->
</div>
Outils et workflow pour une amélioration continue
La performance n'est pas un correctif unique. Intégrez la mesure dans votre workflow :
- Définissez des budgets : Utilisez Lighthouse CI pour appliquer des seuils dans les pull requests.
- Surveillez les données de terrain : Mettez en place des tableaux de bord avec CrUX ou votre propre RUM.
- Priorisez les correctifs : Concentrez-vous sur les métriques avec le plus grand écart par rapport aux seuils 'bons'.
- Testez sur des appareils réels : Émulez des appareils mobiles de milieu de gamme pour détecter les problèmes.
Pour une vérification rapide, passez votre page dans PageSpeed Insights ; il combine données de laboratoire et de terrain.
FAQ
Quels sont les seuils actuels des Core Web Vitals ?
LCP : bon ≤2,5s, à améliorer ≤4s, mauvais >4s. INP : bon ≤200ms, à améliorer ≤500ms, mauvais >500ms. CLS : bon ≤0,1, à améliorer ≤0,25, mauvais >0,25.
À quelle fréquence les données CrUX sont-elles mises à jour ?
Les données CrUX sont mises à jour quotidiennement, mais l'ensemble de données reflète une fenêtre glissante de 28 jours. Search Console est mise à jour périodiquement.
Puis-je améliorer les Core Web Vitals sans changer mon design ?
Oui. De nombreuses améliorations sont techniques : optimiser les images, différer les scripts, réserver de l'espace pour le contenu dynamique et réduire le travail sur le thread principal.
Prêt à analyser les performances de votre site ? Utilisez notre analyseur de logs Nginx pour identifier les réponses serveur lentes qui impactent le TTFB et le LCP.