Que sont les Core Web Vitals ?

Les Core Web Vitals sont un ensemble de métriques spécifiques et mesurables que Google utilise pour évaluer l'expérience utilisateur réelle d'une page web. Elles se concentrent sur trois aspects fondamentaux de la perception d'une page par les visiteurs : la vitesse à laquelle le contenu principal apparaît, la rapidité avec laquelle la page répond aux interactions et la stabilité de la mise en page pendant le chargement. Google utilise les Core Web Vitals comme signal de classement officiel dans les résultats de recherche depuis juin 2021, ce qui signifie que ces métriques influencent directement la position de votre site WordPress dans les résultats.

Les trois Core Web Vitals expliqués

Chaque Core Web Vital mesure une dimension différente de l'expérience utilisateur, et chacune a un seuil spécifique qui définit les performances « bonnes », « à améliorer » et « médiocres ».

Largest Contentful Paint (LCP)

Le LCP mesure le temps nécessaire pour que le plus grand élément de contenu visible soit entièrement rendu à l'écran. Il s'agit généralement d'une image hero, d'un grand bloc de texte ou d'une vignette vidéo. Le chronomètre démarre lorsque l'utilisateur navigue pour la première fois vers la page et s'arrête lorsque ce plus grand élément finit d'être peint.

• Bon : 2,5 secondes ou moins
• À améliorer : Entre 2,5 et 4,0 secondes
• Médiocre : Plus de 4,0 secondes

Le LCP est la métrique qui reflète le plus directement la vitesse de chargement perçue. Une page peut avoir un Time to First Byte (TTFB) rapide mais avoir tout de même un mauvais LCP si le plus grand élément met longtemps à se rendre à cause d'images volumineuses, de ressources bloquant le rendu ou de réponses serveur lentes pour des actifs critiques.

Interaction to Next Paint (INP)

L'INP a remplacé le First Input Delay (FID) en tant que Core Web Vital en mars 2024. Alors que le FID ne mesurait que le délai de la toute première interaction, l'INP mesure la réactivité de toutes les interactions tout au long du cycle de vie de la page. Il suit les clics, les tapotements et les saisies clavier, en enregistrant le temps écoulé entre l'interaction et le moment où le navigateur met effectivement à jour l'écran. La valeur finale d'INP est généralement la pire interaction observée (avec quelques ajustements pour les valeurs aberrantes).

• Bon : 200 millisecondes ou moins
• À améliorer : Entre 200 et 500 millisecondes
• Médiocre : Plus de 500 millisecondes

L'INP est plus difficile à optimiser que le FID car il couvre chaque interaction, pas seulement la première. Une page peut répondre rapidement au premier clic mais devenir lente plus tard lorsque du JavaScript lourd s'exécute.

Cumulative Layout Shift (CLS)

Le CLS mesure à quel point le contenu visible se déplace de manière inattendue pendant le chargement de la page et durant la session de l'utilisateur. Chaque fois qu'un élément change de position sans que l'utilisateur ne l'ait initié (par exemple, en cliquant sur un bouton), ce décalage contribue au score CLS. Le score est calculé en multipliant la fraction d'impact (quelle proportion du viewport est affectée) par la fraction de distance (de combien l'élément s'est déplacé).

• Bon : 0,1 ou moins
• À améliorer : Entre 0,1 et 0,25
• Médiocre : Plus de 0,25

Le CLS est particulièrement frustrant pour les utilisateurs. Imaginez essayer de cliquer sur un bouton, mais juste avant que votre clic n'atterrisse, une publicité se charge au-dessus et pousse le bouton vers le bas. Vous finissez par cliquer sur la publicité à la place. C'est exactement le type d'expérience que mesure le CLS.

Comment Google utilise les Core Web Vitals comme signal de classement

Les Core Web Vitals font partie des signaux de classement plus larges de Google appelés « page experience », qui incluent également la compatibilité mobile, HTTPS et l'absence d'interstitiels intrusifs. Google évalue les Core Web Vitals en utilisant des données utilisateurs réelles provenant du Chrome User Experience Report (CrUX). Cela signifie que Google utilise des données de terrain réelles d'utilisateurs Chrome qui visitent votre site, et non des données de laboratoire issues d'un seul test. L'impact sur le classement s'applique à la fois aux résultats de recherche mobiles et desktop. Bien que la pertinence du contenu reste le facteur de classement le plus fort, les Core Web Vitals peuvent faire la différence entre des pages dont la qualité du contenu est similaire.

Mesurer les Core Web Vitals

Plusieurs outils permettent de mesurer les Core Web Vitals, et ils se répartissent en deux catégories : les données de terrain (mesures réelles d'utilisateurs) et les données de laboratoire (tests simulés).

• PageSpeed Insights : L'outil de Google qui affiche à la fois les données de terrain (depuis CrUX) et les données de laboratoire (depuis Lighthouse). La section des données de terrain affiche les scores Core Web Vitals réels basés sur les utilisateurs réels au cours des 28 derniers jours. C'est la section la plus importante car elle reflète ce que Google utilise pour le classement.
• Google Search Console : Le rapport Core Web Vitals regroupe vos URL par statut (bon, à améliorer, médiocre) en fonction des données utilisateurs réelles. Il vous aide à identifier des motifs sur l'ensemble de votre site plutôt que de vérifier des pages individuelles.
• Chrome User Experience Report (CrUX) : Le jeu de données brut qui alimente PageSpeed Insights et la Search Console. Vous pouvez l'interroger directement via l'API CrUX ou BigQuery pour des analyses personnalisées.
• Lighthouse : Un outil de test en laboratoire intégré aux Chrome DevTools. Il simule le chargement des pages sur une connexion bridée et rapporte le LCP et le CLS (l'INP nécessite une véritable interaction utilisateur et ne peut pas être mesuré de manière fiable en conditions de laboratoire). Utile pour le débogage mais ne reflète pas l'expérience utilisateur réelle.
• Extension Chrome Web Vitals : Une extension de navigateur qui affiche en temps réel les scores Core Web Vitals pendant que vous naviguez, facilitant la détection des problèmes pendant le développement et les tests.

Données utilisateurs réelles vs données de laboratoire

Cette distinction importe plus que beaucoup de propriétaires de sites ne le réalisent. Les données de laboratoire (provenant de Lighthouse ou d'outils similaires) simulent un chargement de page dans des conditions contrôlées : un appareil spécifique, une vitesse réseau et un emplacement spécifiques. Elles sont utiles pour le débogage et l'identification de problèmes techniques, mais elles ne reflètent pas ce que les vrais visiteurs vivent. Les données utilisateurs réelles (données de terrain) proviennent d'utilisateurs Chrome réels qui visitent votre site. Elles capturent toute la gamme d'appareils, de vitesses réseau et d'emplacements géographiques que vos visiteurs utilisent. L'algorithme de classement de Google utilise les données de terrain, pas les données de laboratoire. Une page peut obtenir 95 dans Lighthouse et avoir tout de même de mauvais Core Web Vitals sur le terrain car les utilisateurs réels sur des appareils plus lents vivent une expérience différente.

Problèmes WordPress fréquents pour le LCP

Les sites WordPress rencontrent fréquemment des difficultés avec le LCP en raison de plusieurs problèmes courants :

• Images hero volumineuses et non optimisées : Une image hero de 3 Mo prend beaucoup plus de temps à télécharger et à afficher qu'une version WebP correctement compressée de 200 Ko. Compressez toujours les images, utilisez des formats modernes (WebP ou AVIF) et servez des images correctement dimensionnées pour l'écran du visiteur.
• CSS et JavaScript bloquants pour le rendu : Lorsque le navigateur rencontre des fichiers CSS ou JavaScript dans le <head>, il doit les télécharger et les analyser avant de pouvoir afficher le moindre contenu. Trop de feuilles de style ou des feuilles de style trop volumineuses retardent considérablement le LCP. Intégrez le CSS critique en ligne et différez les feuilles de style non essentielles pour résoudre cela.
• Temps de réponse serveur lent (TTFB) : Si votre serveur d'hébergement met 2 secondes juste pour générer le HTML, votre LCP ne peut pas être en dessous de 2,5 secondes. Mettez à niveau l'hébergement, activez la mise en cache côté serveur et utilisez un CDN pour réduire le TTFB.
• Trop d'extensions : Chaque extension ajoute potentiellement du CSS et du JavaScript à chaque page. Les sites avec plus de 30 extensions actives ont souvent des dizaines de ressources bloquant le rendu et se disputant la bande passante.
• Attribut fetchpriority manquant : L'élément LCP devrait avoir fetchpriority="high" pour signaler au navigateur de le télécharger en premier. Sans cela, le navigateur peut prioriser d'autres ressources sur la plus importante.

Problèmes WordPress fréquents pour l'INP

Les problèmes d'INP dans WordPress remontent généralement à l'exécution de JavaScript :

• JavaScript lourd provenant des extensions : Les sliders, popups, outils d'analyse, widgets de chat et extensions de partage social ajoutent tous du JavaScript qui s'exécute sur le thread principal. Lorsqu'un utilisateur clique sur quelque chose, le navigateur peut avoir besoin de terminer l'exécution d'autres scripts avant de pouvoir réagir.
• Scripts tiers : Google Analytics, Facebook Pixel, scripts publicitaires et outils de chat en direct exécutent souvent des tâches longues qui bloquent le thread principal. Charger ces scripts avec async ou defer aide, mais ils consomment tout de même du temps de traitement.
• Taille DOM excessive : Les pages avec des milliers d'éléments DOM (courantes avec les page builders comme Elementor ou Divi) prennent plus de temps au navigateur pour se mettre à jour lorsque des interactions se produisent. Un clic qui modifie une classe CSS peut déclencher des recalculs de style coûteux sur des milliers d'éléments.
• Tâches longues sur le thread principal : Toute tâche JavaScript s'exécutant plus de 50 millisecondes est considérée comme une « tâche longue » qui bloque la réactivité. Diviser les grandes tâches en morceaux plus petits en utilisant des motifs requestAnimationFrame ou setTimeout peut aider.

Problèmes WordPress fréquents pour le CLS

Les décalages de mise en page sur les sites WordPress sont généralement causés par :

• Images sans attributs de largeur et de hauteur : Lorsqu'une image se charge sans dimensions explicites, le navigateur ne sait pas combien d'espace réserver. Le contenu en dessous se décale lorsque l'image finit par s'afficher. Définissez toujours les attributs width et height sur les images (WordPress le fait automatiquement pour les images ajoutées via la bibliothèque de médias).
• Chargement de polices web : Les polices personnalisées qui se chargent après le rendu initial peuvent provoquer un reflux du texte lorsque la police est échangée. Utilisez font-display: swap combiné avec le préchargement des polices pour minimiser cet effet, ou envisagez font-display: optional pour les polices non critiques.
• Injections publicitaires : Les publicités qui se chargent dynamiquement déplacent le contenu. Réservez de l'espace pour les emplacements publicitaires en utilisant des conteneurs de taille fixe, même avant que la publicité ne se charge.
• Contenu injecté dynamiquement : Les bannières de consentement aux cookies, popups de newsletter et barres de notification qui apparaissent après le chargement de la page peuvent décaler le contenu s'ils sont insérés dans le flux du document plutôt que superposés par-dessus.
• Contenus intégrés et iframes sans dimensions : Les vidéos YouTube, tweets et autres contenus intégrés sans dimensions explicites provoquent des décalages lors de leur chargement.

Améliorer les Core Web Vitals pour WordPress

Voici une approche pratique pour améliorer chaque métrique sur un site WordPress :

• Pour le LCP : Optimisez et compressez les images (utilisez WebP/AVIF), utilisez un CDN, activez la mise en cache côté serveur, intégrez le CSS critique en ligne, différez le JavaScript non essentiel et ajoutez fetchpriority="high" à l'image LCP. Supprimez les extensions inutilisées qui ajoutent des ressources bloquant le rendu.
• Pour l'INP : Auditez et supprimez le JavaScript inutile, différez les scripts tiers, réduisez la taille du DOM (envisagez des page builders plus légers ou des blocs WordPress natifs) et divisez les tâches JavaScript longues en morceaux plus petits. Utilisez l'onglet Performance dans les Chrome DevTools pour identifier quels scripts bloquent le thread principal.
• Pour le CLS : Définissez des dimensions explicites sur toutes les images, vidéos et iframes. Préchargez les polices et utilisez font-display: swap. Réservez de l'espace pour les publicités et le contenu dynamique. Évitez d'insérer du contenu au-dessus du contenu existant après le chargement de la page.

Ce que InspectWP vérifie

InspectWP analyse plusieurs facteurs qui influencent directement les scores Core Web Vitals. Il vérifie la compression HTTP (qui affecte le LCP), l'utilisation de HTTP/2 (qui permet le chargement parallèle des ressources), le nombre de fichiers JavaScript et CSS (qui peuvent causer un blocage du rendu et affecter à la fois le LCP et l'INP), les opportunités d'optimisation des images, la taille du document HTML et d'autres indicateurs liés à la performance. Cela vous donne une image claire de ce qui doit être amélioré pour atteindre de meilleurs scores Core Web Vitals.