Modèle d'audit des Core Web Vitals et de la vitesse de page

Benchmark et données de terrain vs laboratoire

Établissez une référence pour chaque Core Web Vital avant de modifier quoi que ce soit, et apprenez à quelle source de données vous fier pour le scoring par rapport au débogage.

Établissez votre référence

Avant d'optimiser quoi que ce soit, notez où en est chaque métrique aujourd'hui pour [URL de la page]. Google classe selon les données de terrain (utilisateurs réels de Chrome, le jeu de données CrUX, une fenêtre glissante de 28 jours), c'est donc ce chiffre qui compte pour la recherche. Les données de laboratoire (Lighthouse, un seul chargement simulé) servent au débogage, car elles sont reproductibles et fournissent des traces exploitables.

• Source de terrain : récupérez les données CrUX depuis PageSpeed Insights ou le rapport Core Web Vitals de la Search Console pour [Propriété].
• Source de laboratoire : lancez Lighthouse (Chrome DevTools ou PageSpeed Insights) pour reproduire et tracer les problèmes.
• Notez les seuils : LCP bon <=2,5 s, INP bon <=200 ms, CLS bon <=0,1 ; notez votre valeur actuelle et le statut réussite/échec au "75e centile" pour chacune.

Les données de terrain et de laboratoire divergeront, et c'est attendu. Le laboratoire charge sur un seul appareil et réseau ; le terrain en agrège beaucoup. Utilisez le laboratoire pour trouver la cause et le terrain pour confirmer le remède.

Résultat : un tableau de référence indiquant chaque métrique, sa valeur de terrain actuelle, sa valeur de laboratoire et son statut réussite/échec pour [Date].

Correctifs Largest Contentful Paint (LCP)

Diagnostiquez et corrigez un LCP lent pour que l'élément de contenu principal s'affiche en 2,5 secondes pour la plupart des visiteurs.

Faites apparaître le contenu principal rapidement

Le LCP mesure le moment où le plus grand élément visible (généralement une image de héros, une affiche vidéo ou un bloc de titre) achève son rendu. La cible est <=2.5s au 75e centile. Identifiez l'élément LCP dans Lighthouse, puis attaquez les quatre phases qui le retardent.

1. Time to first byte : réduisez la réponse serveur pour [Origine] avec la mise en cache, un hébergement plus rapide ou le rendu en périphérie.
2. Ressources bloquant le rendu : différez le CSS et le JavaScript non critiques pour que le navigateur puisse peindre plus tôt.
3. Délai de chargement de la ressource : ajoutez un preload pour l'image LCP et définissez [fetchpriority=high] dessus pour que le navigateur la récupère tôt.
4. Délai de rendu de la ressource : assurez-vous que l'image LCP n'est pas en lazy-load et qu'elle est servie dans un format moderne à la bonne taille.

Évitez de charger l'image de héros via un fond CSS ou du JavaScript côté client, car le navigateur la découvre trop tard. Une image directement référencée, préchargée et correctement dimensionnée l'emporte presque toujours.

Vérifiez : relancez Lighthouse et confirmez que l'élément LCP et sa chronologie de chargement pour [URL de la page] sont passés sous 2,5 s.

Correctifs Interaction to Next Paint (INP)

Améliorez la réactivité pour que la page réagisse vite aux clics, appuis et frappes de touches, en remplaçant l'ancienne métrique FID.

Rendez les interactions instantanées

L'INP a remplacé le FID comme Core Web Vital en mars 2024. Il mesure la latence des interactions sur l'ensemble de la visite, en rapportant approximativement la pire. La cible est <=200ms. Un mauvais INP remonte presque toujours à du JavaScript qui monopolise le thread principal au moment où l'utilisateur agit.

• Trouvez les tâches longues : utilisez le panneau Performance des DevTools pour repérer les tâches du thread principal de plus de 50 ms pendant l'interaction sur [URL de la page].
• Découpez le JavaScript : divisez les tâches longues en morceaux plus petits et cédez le thread principal pour que la saisie puisse être traitée.
• Réduisez le travail du thread principal : supprimez ou différez les scripts inutilisés, surtout les balises tierces lourdes comme [Nom de la balise].
• Optimisez les gestionnaires d'événements : appliquez un debounce au travail coûteux et différez les mises à jour non urgentes jusqu'après le prochain paint.
• Minimisez la taille du DOM et le coût de mise en page : un DOM volumineux ou profondément imbriqué rend chaque interaction plus coûteuse.

L'objectif est de garder le thread principal libre quand les utilisateurs cliquent et touchent, pour que le navigateur puisse peindre une réponse dans le budget de 200 ms.

Vérifiez : testez de vraies interactions et confirmez que l'INP de terrain tend vers le bon pour [Propriété].

Correctifs Cumulative Layout Shift (CLS)

Empêchez le contenu de sauter pendant le chargement pour que la mise en page reste visuellement stable en dessous d'un CLS de 0,1.

Empêchez la mise en page de sauter

Le CLS mesure les décalages de mise en page inattendus du contenu visible pendant la durée de vie de la page. La cible est <=0.1. Les décalages frustrent les utilisateurs et provoquent des clics erronés, et ils viennent presque toujours d'éléments qui se chargent sans espace réservé.

• Dimensionnez vos médias : définissez toujours les attributs width et height (ou un aspect-ratio CSS) sur les images, vidéos et iframes pour que le navigateur réserve l'espace avant leur chargement.
• Réservez de l'espace pour les intégrations et publicités : donnez aux emplacements de [Publicité ou intégration] un conteneur à min-height fixe pour qu'ils ne poussent pas le contenu vers le bas.
• N'insérez jamais de contenu au-dessus du contenu existant : évitez d'injecter des bannières, avis ou bandeaux de cookies qui poussent la page vers le bas après le rendu.
• Évitez les décalages de font-swap : préchargez les polices clés et utilisez [font-display] judicieusement pour limiter le reflow.
• Réservez l'espace pour l'UI dynamique : conservez de la place pour les éléments ajoutés par JavaScript afin qu'ils se déploient dans un espace pré-alloué.

Traitez tout "saut" que vous voyez pendant le chargement comme un défaut à éliminer.

Vérifiez : regardez le filmstrip de chargement et confirmez l'absence de décalages visibles sur [URL de la page].

Optimisation des assets et de la diffusion

Allégez et accélérez les ressources qu'une page livre — images, JavaScript, CSS, cache et CDN — pour améliorer toutes les métriques d'un coup.

Livrez moins, livrez plus vite

La plupart des problèmes de vitesse de page se résument à envoyer trop d'octets ou à les envoyer trop lentement. Optimiser la diffusion améliore le LCP, l'INP et le CLS ensemble, car le navigateur a moins à télécharger, analyser et exécuter.

• Images : servez des formats modernes (comme WebP ou AVIF), dimensionnez-les aux dimensions affichées et compressez ; ne faites du lazy-load que pour les images sous la ligne de flottaison, jamais pour l'image LCP.
• JavaScript : minifiez, faites du tree-shaking et du code-splitting pour que chaque page ne charge que ce dont elle a besoin ; différez ou passez en async les scripts non critiques.
• CSS : minifiez, supprimez les règles inutilisées et intégrez en inline le CSS critique du contenu au-dessus de la ligne de flottaison sur [Modèle].
• Mise en cache : définissez de longues durées de cache pour les assets statiques et utilisez des noms de fichiers à empreinte (fingerprint) pour que les mises à jour invalident le cache en toute sécurité.
• CDN : servez les assets depuis des emplacements en périphérie proches des utilisateurs et activez la compression (Brotli ou gzip) chez [Fournisseur CDN].

Auditez les scripts tiers sans pitié, car ils sont une cause fréquente et cachée de chargements lents et de mauvaise réactivité.

Vérifiez : comparez la taille totale de transfert et le nombre de requêtes avant et après pour [URL de la page].

Retester et surveiller

Confirmez que les correctifs ont fonctionné dans les données de terrain et mettez en place une surveillance continue pour détecter tôt les régressions.

Confirmez le gain et conservez-le

Un correctif n'est pas terminé tant que les données de terrain ne le confirment pas. Comme CrUX utilise une fenêtre glissante de 28 jours, les améliorations pour les utilisateurs réels mettent du temps à apparaître ; validez donc en deux temps : d'abord en laboratoire pour un retour immédiat, puis sur le terrain au fil des semaines suivantes.

1. Relancez les tests de laboratoire : utilisez Lighthouse ou PageSpeed Insights pour confirmer que le problème au niveau de la trace sur [URL de la page] est résolu.
2. Surveillez les données de terrain : suivez CrUX dans le rapport Core Web Vitals de la Search Console et attendez que la fenêtre de 28 jours se rafraîchisse avant de crier victoire.
3. Fixez des cibles : maintenez chaque groupe d'URL à LCP <=2.5s, INP <=200ms, CLS <=0.1 au 75e centile.
4. Surveillez en continu : ajoutez une surveillance des utilisateurs réels (RUM) ou des audits planifiés pour [Propriété] afin que les régressions ressortent vite.
5. Prémunissez-vous contre la dérive : réauditez après les gros déploiements, l'ajout de nouvelles balises tierces ou les changements de template.

La performance n'est pas un projet ponctuel ; traitez-la comme un budget permanent que vous défendez à chaque déploiement.

Résultat : un rapport avant/après et une cadence de surveillance notée pour [Date].

Quels sont les trois Core Web Vitals et leurs bons seuils ?

Le Largest Contentful Paint (LCP) doit être de 2,5 secondes ou moins, l'Interaction to Next Paint (INP) de 200 millisecondes ou moins, et le Cumulative Layout Shift (CLS) de 0,1 ou moins. Chaque seuil doit être atteint au 75e centile des visites d'utilisateurs réels pour être considéré comme bon.

Qu'est-il arrivé au First Input Delay (FID) ?

L'INP a remplacé le FID comme Core Web Vital en mars 2024. Le FID ne mesurait que le délai avant le traitement de la première interaction, tandis que l'INP mesure la latence complète des interactions sur toute la visite, offrant une image plus complète de la réactivité.

Quelle est la différence entre les données de terrain et les données de laboratoire ?

Les données de terrain proviennent d'utilisateurs réels de Chrome dans le jeu de données CrUX sur une fenêtre glissante de 28 jours, et c'est ce que Google utilise pour le classement. Les données de laboratoire proviennent d'un seul chargement simulé dans un outil comme Lighthouse ; elles sont reproductibles et idéales pour le débogage, mais ne reflètent pas ce que vivent les utilisateurs réels.

Pourquoi mon score Lighthouse diffère-t-il du score de terrain CrUX ?

Lighthouse exécute un chargement sur un appareil et un réseau simulés précis, tandis que CrUX agrège de nombreux utilisateurs réels sur des appareils, connexions et états de cache variés. Le désaccord est normal. Utilisez les données de laboratoire pour trouver et corriger la cause, et les données de terrain pour confirmer que le correctif a fonctionné pour les utilisateurs réels.

Pourquoi mes Core Web Vitals ne se sont-ils pas améliorés juste après le déploiement d'un correctif ?

Les données de terrain se mettent à jour lentement car CrUX utilise une fenêtre glissante de 28 jours, si bien que les améliorations mettent des semaines à apparaître pleinement. Confirmez le correctif avec des outils de laboratoire comme Lighthouse pour un retour immédiat, puis surveillez le rapport de terrain dans la Search Console à mesure que la fenêtre se rafraîchit progressivement avec les données post-correctif.

Quelle est la cause la plus fréquente d'un mauvais INP ?

De longues tâches JavaScript bloquant le thread principal lorsqu'un utilisateur interagit. Quand le thread principal est occupé, le navigateur ne peut pas traiter la saisie et peindre une réponse dans le budget de 200 ms. Découper les tâches longues, différer les scripts non critiques et tiers, et céder le thread principal sont les correctifs les plus efficaces.