Core Web Vitals : Mesurez et améliorez les performances web
Vous avez construit un site web rapide, mais les utilisateurs se plaignent encore de lenteur. Ou peut-être que votre classement SEO a chuté après une mise à jour de Google. Le coupable pourrait être les Core Web Vitals — un ensemble de métriques que Google utilise pour mesurer l'expérience utilisateur réelle. Les ignorer peut nuire à la satisfaction des utilisateurs et à la visibilité dans les recherches.
Dans ce guide, vous apprendrez ce que sont les Core Web Vitals, comment les mesurer avec précision et les étapes pratiques pour améliorer chaque métrique. Nous nous concentrerons sur les trois métriques actuelles : Largest Contentful Paint (LCP), Interaction to Next Paint (INP) et Cumulative Layout Shift (CLS).
Que sont les Core Web Vitals ?
Les Core Web Vitals sont un sous-ensemble des Web Vitals que Google considère comme essentiels pour offrir une excellente expérience utilisateur. Ils quantifient la rapidité de chargement du contenu, la réactivité de la page aux interactions et sa stabilité visuelle.
Google utilise ces métriques comme signal de classement, mais plus important encore, elles reflètent les points de douleur réels des utilisateurs. Un LCP lent frustre les utilisateurs qui attendent le contenu ; un INP élevé donne une impression de lag ; un CLS élevé provoque des clics erronés et de l'agacement.
Les trois Core Web Vitals
- Largest Contentful Paint (LCP) : Mesure la performance de chargement. Il marque le moment où le plus grand élément de contenu (image, vidéo ou bloc de texte) devient visible. Un bon LCP est de 2,5 secondes ou moins.
- Interaction to Next Paint (INP) : Mesure la réactivité. Il enregistre la latence de toutes les interactions (clics, taps, pressions de touches) et rapporte une valeur unique. Un bon INP est de 200 millisecondes ou moins.
- Cumulative Layout Shift (CLS) : Mesure la stabilité visuelle. Il quantifie les décalages de mise en page inattendus pendant le chargement. Un bon CLS est de 0,1 ou moins.
Ces seuils sont basés sur des données de terrain provenant d'utilisateurs réels, et non sur des tests en laboratoire. Google les évalue au 75e percentile des chargements de page, ce qui signifie que 75 % des expériences utilisateur doivent atteindre le seuil « bon ».
Comment mesurer les Core Web Vitals
Vous avez besoin à la fois de données de laboratoire et de terrain. Les outils de laboratoire simulent un seul chargement de page dans des conditions contrôlées, tandis que les données de terrain (Real User Monitoring, RUM) capturent les expériences réelles des utilisateurs sur différents appareils et réseaux.
Outils de laboratoire
- Lighthouse : Intégré à Chrome DevTools, il audite les performances et fournit des scores pour LCP, CLS et le temps de blocage total (TBT), qui est corrélé à l'INP. Exécutez-le en mode navigation privée pour éviter que les extensions faussent les résultats.
- PageSpeed Insights : Combine les données de laboratoire (Lighthouse) et de terrain (CrUX). Utilisez-le pour voir à la fois vos scores de laboratoire et les métriques des utilisateurs réels.
- WebPageTest : Offre des tests avancés depuis plusieurs emplacements et appareils. Il fournit des filmstrips et des diagrammes en cascade pour diagnostiquer les problèmes de chargement.
Outils de terrain
- Chrome User Experience Report (CrUX) : Un ensemble de données public de métriques d'utilisateurs réels provenant de Chrome. Disponible via PageSpeed Insights, le tableau de bord CrUX ou BigQuery.
- Google Search Console : Affiche l'état des Core Web Vitals pour votre site en fonction des données CrUX. Il regroupe les URL par performance.
- Bibliothèque JavaScript web-vitals : Une petite bibliothèque pour mesurer les métriques dans votre propre RUM. Vous pouvez envoyer les données à votre plateforme d'analyse.
Voici comment utiliser la bibliothèque web-vitals pour enregistrer les métriques dans la console :
import {onLCP, onINP, onCLS} from 'web-vitals';
function sendToAnalytics(metric) {
const body = JSON.stringify(metric);
// Utilisez navigator.sendBeacon() ou fetch() pour envoyer les données
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);
Pour une vérification rapide sans coder, vous pouvez utiliser des outils en ligne qui analysent les données de performance. Par exemple, si vous avez des logs serveur, l'Nginx Log Analyzer peut vous aider à identifier les réponses lentes qui pourraient affecter le LCP.
Améliorer le Largest Contentful Paint (LCP)
Le LCP est souvent la métrique la plus impactante à optimiser. Il est affecté par le temps de réponse du serveur, le temps de chargement des ressources et le rendu côté client.
Optimiser la réponse du serveur
- Utilisez un CDN pour servir le contenu depuis des emplacements plus proches des utilisateurs.
- Activez la mise en cache (navigateur et côté serveur) pour les ressources statiques.
- Optimisez les requêtes de base de données et le code côté serveur pour réduire le TTFB (Time to First Byte).
- Passez à HTTP/2 ou HTTP/3 pour le multiplexage et des connexions plus rapides.
Optimiser les ressources
- Préchargez les ressources critiques : Utilisez
<link rel="preload">pour l'image ou la police LCP. - Compressez et dimensionnez correctement les images : Utilisez des formats modernes comme WebP ou AVIF, et servez des images responsives avec
srcset. - Minifiez le CSS et le JavaScript : Supprimez les caractères et commentaires inutiles.
- Différez le JavaScript non critique : Utilisez les attributs
asyncoudefer. - Intégrez le CSS critique : Placez les styles au-dessus de la ligne de flottaison directement dans le HTML pour éviter les requêtes bloquant le rendu.
Éliminer les ressources bloquant le rendu
Le CSS et le JavaScript dans le <head> bloquent le rendu. Intégrez le CSS critique et chargez le reste de manière asynchrone. Pour le JavaScript, utilisez defer ou async.
Améliorer l'Interaction to Next Paint (INP)
L'INP mesure le temps entre une interaction utilisateur et la prochaine peinture. Il est influencé par l'exécution du JavaScript, la gestion des événements et le travail de rendu.
Réduire le temps d'exécution du JavaScript
- Divisez les tâches longues (plus de 50 ms) en utilisant
setTimeoutourequestIdleCallback. - Utilisez des web workers pour les calculs lourds.
- Appliquez un debounce ou un throttle aux gestionnaires d'événements pour le défilement, le redimensionnement et les événements de saisie.
- Évitez les gros scripts synchrones ; découpez le code et chargez les modules en lazy-loading.
Optimiser la gestion des événements
- Utilisez des écouteurs d'événements passifs pour les événements tactiles et de molette afin d'améliorer les performances de défilement.
- Minimisez la manipulation du DOM ; regroupez les mises à jour et utilisez
requestAnimationFrame. - Réduisez la portée des recalculs de style en évitant les sélecteurs complexes.
Améliorer les performances de rendu
- Utilisez
will-changeoutransformen CSS pour les animations afin de déclencher l'accélération GPU. - Évitez le layout thrashing en lisant et écrivant les styles dans des phases séparées.
Améliorer le Cumulative Layout Shift (CLS)
Le CLS mesure les décalages de mise en page inattendus. Il est causé par des éléments qui changent de position pendant le chargement, souvent à cause d'images sans dimensions, de publicités ou de contenu injecté dynamiquement.
Toujours inclure les attributs de taille
Pour les images et les vidéos, définissez les attributs width et height ou utilisez aspect-ratio en CSS. Cela réserve l'espace et empêche les décalages.
<img src="#" width="800" height="600" alt="Hero">
Réserver de l'espace pour le contenu dynamique
- Utilisez
min-heighten CSS pour les conteneurs qui chargent du contenu de manière asynchrone (par exemple, publicités, intégrations). - Évitez d'insérer du contenu au-dessus du contenu existant, sauf si cela est déclenché par une interaction utilisateur.
Utiliser font-display: swap
Les polices personnalisées peuvent provoquer du texte invisible (FOIT) ou des décalages de mise en page lors de leur chargement. Utilisez font-display: swap pour afficher immédiatement le texte de secours, et préchargez les polices pour réduire le temps de remplacement.
Tout mettre en place : un workflow pratique
- Mesurer : Commencez par PageSpeed Insights pour obtenir à la fois les données de laboratoire et de terrain. Identifiez la métrique à améliorer.
- Diagnostiquer : Utilisez Lighthouse et le panneau Performance de Chrome DevTools pour trouver les goulots d'étranglement. Examinez le waterfall, l'activité du thread principal et les décalages de mise en page.
- Optimiser : Appliquez les techniques ci-dessus, en priorisant les changements qui affectent la métrique la plus mauvaise.
- Tester : Relancez les tests de laboratoire pour confirmer les améliorations. Déployez sur un environnement de staging et utilisez le RUM pour surveiller les données de terrain.
- Surveiller : Mettez en place un RUM continu avec la bibliothèque web-vitals et alertez en cas de régressions. Utilisez Search Console pour suivre l'état des Core Web Vitals.
Rappelez-vous que les optimisations peuvent avoir des compromis. Par exemple, le lazy-loading des images peut améliorer le chargement initial mais peut nuire au LCP si l'image LCP est chargée en lazy-loading. Testez toujours avec des utilisateurs réels.
FAQ
Quels sont les seuils actuels des Core Web Vitals ?
Pour le LCP, bon est ≤2,5 s, à améliorer est ≤4,0 s, et mauvais est >4,0 s. Pour l'INP, bon est ≤200 ms, à améliorer est ≤500 ms, et mauvais est >500 ms. Pour le CLS, bon est ≤0,1, à améliorer est ≤0,25, et mauvais est >0,25. Ces seuils sont évalués au 75e percentile des chargements de page.
À quelle fréquence dois-je vérifier les Core Web Vitals ?
Surveillez les données de terrain en continu avec le RUM. Consultez Search Console mensuellement pour les tendances globales. Exécutez des tests de laboratoire après des changements de code majeurs ou des déploiements. Les Core Web Vitals peuvent changer avec les mises à jour de votre site ou des scripts tiers.
Puis-je améliorer les Core Web Vitals sans développeur ?
Certaines améliorations sont possibles via des plugins ou des paramètres (par exemple, activer la mise en cache, optimiser les images). Cependant, des gains significatifs nécessitent souvent des modifications de code comme l'intégration du CSS critique, le report du JavaScript ou la restructuration du chargement des ressources. L'aide d'un développeur est généralement nécessaire pour l'INP et les optimisations avancées du LCP.
Prêt à analyser les performances de votre serveur ? Essayez notre Nginx Log Analyzer pour identifier les requêtes lentes qui pourraient impacter vos Core Web Vitals.