La checklist ultime des Core Web Vitals (2026)

Table of Contents!

• La checklist ultime des Core Web Vitals
• Checklist d'optimisation des Core Web Vitals
  • Optimiser les images
  • Optimiser les polices web
  • Optimiser les scripts
  • Optimiser les styles
  • Optimiser les indices de ressources
  • Optimiser les icônes
  • Optimiser les temps de réponse serveur
  • Optimiser l'interactivité
  • Monitoring des Core Web Vitals
  • Optimiser le chemin critique de rendu
  • Optimiser le consentement aux cookies
  • Optimiser les applications monopage
  • Éviter une taille de DOM excessive
  • Optimiser les requêtes API
  • Optimiser les widgets de chat
  • Optimiser les performances des Service Workers
  • Optimiser le contenu vidéo

Optimiser les images

Les images volumineuses dans la zone visible de l'écran deviendront, la plupart du temps, l'élément Largest Contentful Paint. L'optimisation des images est l'une des actions ayant le plus d'impact sur le LCP. Utilisez ces éléments de la checklist des Core Web Vitals pour améliorer la vitesse de chargement des images. Pour approfondir le sujet, consultez notre guide sur l'optimisation de l'image LCP.

• Redimensionnez les images pour correspondre aux plus grandes dimensions affichées à l'écran : Cela garantit que les octets ne sont jamais gaspillés en téléchargeant des images plus grandes que leur taille maximale d'affichage. Combinez cette pratique avec les images responsives pour les écrans plus petits. Servir des images correctement dimensionnées peut réduire la taille des fichiers image de 50 % ou plus sans aucune perte de qualité visible.
• Utilisez le chargement différé pour les images hors écran : Le chargement différé retarde le chargement des images en dehors de la zone visible jusqu'à ce qu'elles soient affichées par défilement, améliorant le First Contentful Paint (FCP) et la vitesse globale de chargement de la page. Ne chargez jamais en différé l'image LCP, car cela la retardera considérablement.
• Préchargez les images visuellement importantes comme l'élément LCP : Le préchargement indique au navigateur de récupérer les images critiques avant le reste du contenu, en priorisant le LCP. Utilisez <link rel="preload" as="image"> combiné avec fetchpriority="high" pour de meilleurs résultats. C'est particulièrement important lorsque l'image LCP est référencée depuis le CSS ou chargée via JavaScript.
• Définissez la largeur et la hauteur : Définir les dimensions des images à l'avance empêche les décalages de mise en page causés par l'attente du chargement des images par le navigateur. Cela améliore le CLS. Les navigateurs modernes utilisent les attributs width et height pour calculer le rapport d'aspect avant le chargement de l'image, réservant ainsi l'espace nécessaire.
• Utilisez des formats d'image modernes comme WebP ou AVIF : Ces formats offrent des tailles de fichier plus petites par rapport au JPEG ou au PNG tout en maintenant une qualité similaire, ce qui se traduit par des temps de chargement plus rapides. WebP atteint généralement des fichiers 25 à 34 % plus petits que le JPEG, tandis qu'AVIF peut réduire la taille des fichiers jusqu'à 50 %. Utilisez l'élément <picture> avec des alternatives de format pour une compatibilité maximale avec les navigateurs.
• Utilisez le chargement différé natif et désactivez le chargement différé basé sur JavaScript : Le chargement différé retarde le chargement des images en dehors de la zone visible jusqu'à ce qu'elles soient affichées par défilement. Le chargement différé natif offert par les navigateurs via l'attribut loading="lazy" est généralement plus efficace que de s'appuyer sur JavaScript pour cette tâche, car il ne nécessite pas d'analyse ou d'exécution de script supplémentaire.
• Utilisez les images responsives avec srcset : Cet attribut spécifie différentes versions d'images pour différentes tailles d'écran, garantissant que le navigateur fournit l'image optimale pour l'appareil de l'utilisateur, réduisant les téléchargements volumineux inutiles. Combinez srcset avec l'attribut sizes pour un contrôle précis.
• Ajoutez decoding="async" : L'attribut decoding="async" empêche le navigateur de bloquer d'autres contenus lors du décodage d'une image. Cela permet au moteur de rendu de continuer à peindre les autres éléments pendant que le décodage de l'image s'effectue en parallèle.
• Supprimez les métadonnées des images : Les métadonnées comme les données EXIF intégrées dans les images peuvent ajouter des octets inutiles. Supprimer ces informations peut réduire la taille des fichiers sans affecter la qualité de l'image. Des outils comme ImageOptim, Squoosh ou Sharp peuvent automatiser la suppression des métadonnées dans votre processus de build.
• Évitez les images d'arrière-plan CSS pour les éléments LCP : Les images d'arrière-plan référencées en CSS sont découvertes plus tardivement par le navigateur que les éléments <img> en HTML. Si vous devez utiliser une image d'arrière-plan comme élément LCP, préchargez-la avec une balise <link rel="preload"> pour garantir une découverte précoce. En savoir plus sur le délai de chargement des ressources LCP.

Optimiser les polices web

Les polices web peuvent retarder le First Contentful Paint, provoquer des décalages de mise en page et concurrencer les ressources à bande passante limitée en début de chargement. Utilisez cette checklist pour garantir une expérience fluide avec les polices web. Pour les bonnes pratiques d'hébergement de polices, consultez notre guide sur l'auto-hébergement des Google Fonts.

• Utilisez font-display: swap pour un premier affichage plus rapide : Définissez la propriété font-display sur swap dans vos déclarations @font-face. Cela garantit que le navigateur affiche immédiatement une police de secours tout en chargeant la police web en arrière-plan. Une fois la police prête, elle est remplacée de manière transparente. En savoir plus sur comment garantir la visibilité du texte pendant le chargement des polices web.
• Utilisez font-display: optional combiné au préchargement pour éliminer les décalages de mise en page causés par les polices : Combiner font-display: optional avec le préchargement offre un équilibre entre vitesse et décalages de mise en page potentiels. La valeur optional masque brièvement le texte (environ 100 ms) avant d'utiliser une police de secours. Le préchargement indique au navigateur de récupérer la police web en avance, minimisant le temps passé sur les polices de secours et réduisant les décalages de mise en page.
• Utilisez les descripteurs font-face pour faire correspondre les dimensions de la police de secours à celles de la police web : Cela garantit un CLS minimal lors du remplacement par la police web. En spécifiant des métriques similaires avec size-adjust, ascent-override, descent-override et line-gap-override pour la police de secours, vous pouvez empêcher le contenu de sauter lors du chargement de la police.
• Sous-ensemblez les polices pour n'inclure que les caractères nécessaires : Réduisez la taille des fichiers de police en les sous-ensemblant pour n'inclure que les caractères nécessaires à votre contenu. Des outils comme Font Squirrel, pyftsubset ou glyphhanger peuvent aider à générer des sous-ensembles. Une police avec un jeu de caractères latins complet peut souvent être réduite de plus de 100 Ko à moins de 20 Ko avec un sous-ensemblage approprié.
• Limitez le nombre de graisses et de styles de police : Évitez de charger un nombre excessif de variations de police. Limitez-vous à un maximum de 2 polices critiques (généralement préchargées) et 2 polices à chargement tardif (chargées après le rendu initial). Chaque graisse de police supplémentaire ajoute de 15 à 50 Ko de téléchargement.

Optimiser les scripts

Les scripts peuvent causer des problèmes d'Interaction to Next Paint, déclencher des Cumulative Layout Shifts ou retarder le Largest Contentful Paint. Même les scripts optimisés et relativement inoffensifs chargés tôt peuvent concurrencer les ressources et retarder les métriques de peinture (LCP et FCP). Pour un guide complet, consultez 14 méthodes pour différer le JavaScript.

• Supprimez le JavaScript inutile : Identifiez et éliminez le code JavaScript non utilisé pour minimiser la quantité de code à télécharger et à exécuter. Utilisez l'onglet Coverage des Chrome DevTools pour trouver le code inutilisé. Supprimer le code mort réduit à la fois le temps de téléchargement et le traitement du thread principal.
• Priorisez les scripts en fonction de leur rôle et de leur importance : Les scripts qui effectuent des modifications importantes dans la zone visible doivent être bloquants pour le rendu. Les scripts importants doivent être différés ou chargés en mode async. Les scripts secondaires doivent être chargés lorsque le navigateur est inactif. Consultez notre guide de priorisation des ressources pour une stratégie détaillée.
• Fractionnement du code et chargement différé : Découpez les gros bundles JavaScript en morceaux plus petits et chargez-les uniquement lorsque nécessaire. Cela réduit le temps de chargement initial. Les bundlers modernes comme webpack, Rollup et esbuild prennent en charge le fractionnement automatique du code basé sur les imports dynamiques.
• Minifiez et recompilez les fichiers JavaScript : Minifiez et recompilez toujours vos fichiers JavaScript avec un outil de minification comme SWC, Terser ou esbuild. La minification réduit généralement la taille des fichiers JavaScript de 30 à 50 %.
• Limitez les scripts tiers : Les scripts tiers peuvent introduire une surcharge de performance significative. Évaluez leur nécessité et explorez des alternatives si possible. Chaque script tiers ajoute des résolutions DNS, une surcharge de connexion et du temps de traitement sur le thread principal. Auditez régulièrement les scripts tiers à l'aide du panneau Network des Chrome DevTools.
• Chargez les scripts tiers de manière asynchrone : En raison de la nature imprévisible des scripts tiers, ne laissez jamais le rendu être bloqué par un tiers. Utilisez l'attribut async ou defer sur toutes les balises de scripts tiers.
• Surveillez les performances des scripts tiers : Utilisez l'API Long Animation Frames (LoAF) ou CoreDash pour suivre l'impact réel des scripts tiers sur l'INP et le LCP. Définissez des budgets de performance pour le JavaScript tiers et révisez-les régulièrement.

Optimiser les styles

Les styles sont bloquants pour le rendu par défaut. Optimiser les styles permettra d'optimiser les métriques de peinture. Suivez cette checklist pour améliorer les performances des styles de votre page web. Le CSS bloquant le rendu impacte directement le First Contentful Paint et le délai de rendu de l'élément LCP. Pour des conseils sur le nettoyage des styles inutilisés, consultez comment supprimer le CSS inutilisé.

• Minifiez les fichiers CSS : Supprimez les caractères inutiles comme les espaces, les commentaires et le formatage des fichiers CSS. Les fichiers minifiés sont plus petits, ce qui accélère les temps de chargement. Des outils comme cssnano, PostCSS ou la compression intégrée de votre préprocesseur CSS peuvent automatiser cette tâche.
• Supprimez le CSS inutilisé : Identifiez et éliminez le code CSS qui n'est pas utilisé sur vos pages web. Cela réduit la quantité de données que le navigateur doit télécharger et analyser, améliorant ainsi les performances. Des outils comme PurgeCSS ou l'onglet Coverage des Chrome DevTools aident à identifier le CSS inutilisé.
• Intégrez le CSS critique en ligne : Servez les styles essentiels au rendu du contenu initial de la page directement dans le HTML pour améliorer les métriques de peinture. Envisagez de servir le CSS critique uniquement aux nouveaux visiteurs et d'utiliser des feuilles de style externes mises en cache pour les visiteurs récurrents. Cette technique peut réduire le FCP en éliminant l'aller-retour nécessaire pour récupérer une feuille de style externe.
• Répartissez équitablement la taille des fichiers CSS : Bien qu'il puisse sembler efficace de combiner tout le CSS en un seul fichier, les fichiers excessivement volumineux peuvent ralentir les temps de téléchargement. Envisagez de diviser le CSS en fichiers plus petits avec une distribution de taille plus uniforme (10 à 15 Ko chacun) pour optimiser le chargement et permettre au navigateur de traiter les styles de manière incrémentielle.
• Chargez les styles hors écran de manière asynchrone : Pour les styles qui s'appliquent aux éléments en dehors de la zone visible initiale, envisagez le chargement asynchrone via le pattern media="print" onload="this.media='all'". Cela permet au navigateur de récupérer ces styles en parallèle avec d'autres ressources sans bloquer le rendu initial de la page.

Optimiser les indices de ressources

Les indices de ressources aident à prioriser le téléchargement des ressources critiques. Les ressources préchargées sont généralement mises en file d'attente pour le téléchargement et disponibles pour le navigateur beaucoup plus tôt qu'elles ne l'auraient été sans préchargement. Une utilisation efficace des indices de ressources peut réduire significativement le délai de chargement des ressources LCP. Pour une implémentation avancée, consultez notre article sur les 103 Early Hints.

• Supprimez les indices de ressources non critiques : Supprimez les hints de préchargement pour les ressources qui ne sont pas essentielles au chargement initial de la page. Cela évite les téléchargements ou connexions réseau inutiles qui concurrencent les ressources critiques à bande passante limitée en début de chargement. Chaque préchargement inutile consomme de la bande passante qui pourrait être utilisée pour des ressources véritablement critiques.
• Préconnectez-vous aux domaines critiques : Établissez des connexions avec les domaines importants (comme les réseaux de diffusion de contenu ou les fournisseurs de polices) en avance. Cela accélère le téléchargement des ressources critiques depuis ces domaines en effectuant les handshakes DNS, TCP et TLS à l'avance. Utilisez <link rel="preconnect" href="https://example.com"> pour les origines tierces critiques.
• Envisagez le DNS prefetch comme alternative au preconnect : Similaire au preconnect, le DNS prefetch indique au navigateur les connexions potentielles. Cependant, le preconnect priorise l'établissement de la connexion complète, tandis que le DNS prefetch indique simplement au navigateur de résoudre le nom de domaine à l'avance. Utilisez <link rel="dns-prefetch"> lorsque la surcharge de connexion complète du preconnect n'est pas justifiée.
• Préchargez l'élément LCP : Le LCP mesure le temps nécessaire pour que le contenu principal se charge. Précharger l'élément LCP indique au navigateur de prioriser le téléchargement de cette ressource critique, accélérant le temps nécessaire aux utilisateurs pour voir le contenu principal. C'est particulièrement important pour les images référencées en CSS ou chargées via JavaScript.
• Préchargez les polices critiques : Précharger les polices critiques garantit que le navigateur les récupère tôt, évitant les retards d'affichage du texte et améliorant les décalages de mise en page cumulés causés par le remplacement de polices. Utilisez <link rel="preload" as="font" type="font/woff2" crossorigin> pour vos typographies les plus importantes.
• Préférez les 103 Early Hints pour les indices de ressources : Le code de statut HTTP 103 Early Hints permet au serveur d'envoyer des indices de ressources avant que la réponse complète ne soit prête. Si votre serveur ne supporte pas le 103, utilisez les en-têtes de réponse Link à la place. Si les en-têtes ne sont pas disponibles, ajoutez des éléments <link> dans le <head> de la page comme solution de repli. Plus les indices sont délivrés tôt, plus la découverte des ressources est rapide.
• Préchargez les polices avant que les fichiers CSS ne les découvrent : Les polices référencées en CSS ne sont découvertes qu'après le téléchargement et l'analyse du fichier CSS. En préchargeant les polices directement dans le <head> du HTML, vous éliminez la dépendance à l'analyse du CSS et permettez aux polices de se charger en parallèle, réduisant à la fois le FCP et le risque de décalage de mise en page.

Optimiser les icônes

Les icônes peuvent ajouter un poids significatif à votre page si elles ne sont pas optimisées. Les grandes icônes SVG en ligne alourdissent votre HTML, tandis que les polices d'icônes incluent souvent des milliers de glyphes inutilisés. L'optimisation des icônes impacte à la fois le LCP (poids réduit du HTML/CSS) et le CLS (réservation correcte des dimensions).

• Évitez les icônes SVG en ligne dans le HTML : Intégrer de grandes icônes SVG en ligne peut augmenter la taille de votre code HTML et ralentir le chargement de la page. Envisagez des méthodes alternatives comme les servir en tant que fichiers séparés ou utiliser des polices d'icônes (avec prudence) pour minimiser la taille du HTML et permettre la mise en cache des icônes par le navigateur. Une feuille de sprites SVG externe est souvent le meilleur équilibre entre performance et flexibilité.
• Évitez les polices d'icônes volumineuses : N'utilisez jamais de grands jeux d'icônes comme Font Awesome dans leur intégralité. Utilisez le sous-ensemblage pour créer des polices d'icônes optimisées ou des SVG individuels afin de réduire la taille globale de la page web et améliorer la vitesse de chargement. Un jeu Font Awesome complet peut dépasser 100 Ko, tandis qu'un sous-ensemble de 20 icônes peut faire moins de 5 Ko.
• Réservez la largeur et la hauteur pour les icônes : Comme pour les images, spécifier la largeur et la hauteur des icônes aide le navigateur à réserver l'espace et empêche les décalages de mise en page lors de leur chargement. Utilisez les attributs width et height sur les éléments SVG ou définissez des dimensions explicites en CSS.
• Dépriorisez les jeux d'icônes non critiques : Si les icônes ne sont pas critiques pour le rendu initial de votre page, envisagez de les charger avec une priorité plus basse. Cela garantit que le contenu essentiel se charge en premier et minimise l'impact sur les métriques Core Web Vitals. Utilisez le chargement différé ou chargez les feuilles de style d'icônes de manière asynchrone après le premier affichage.

Optimiser les temps de réponse serveur

Les temps de réponse serveur, mesurés par le Time to First Byte (TTFB), ont une relation directe avec toutes les métriques de peinture. Une réponse serveur lente retarde tout ce qui suit. Pour des stratégies d'optimisation détaillées, explorez nos guides sur le diagnostic des problèmes de TTFB et la configuration de Cloudflare pour la performance.

• Utilisez un hébergeur rapide et fiable : Un hébergeur rapide avec une infrastructure solide peut améliorer significativement les temps de réponse serveur et les performances globales du site web. Comparez les hébergeurs en utilisant des mesures réelles de TTFB, pas des arguments marketing synthétiques.
• Optimisez le code côté serveur et les requêtes de base de données : Journalisez régulièrement les temps d'exécution du code et des requêtes de base de données pour trouver les goulots d'étranglement et améliorer la vitesse globale. Utilisez le profilage de requêtes et les outils de monitoring des performances applicatives (APM) pour identifier les endpoints lents.
• Implémentez des stratégies de mise en cache : Utilisez la mise en cache du navigateur et la mise en cache côté serveur pour stocker les données fréquemment accédées, réduisant le besoin de récupérations répétées et améliorant les temps de chargement. La mise en cache de page complète peut réduire le TTFB de quelques secondes à moins de 100 ms. En savoir plus sur l'optimisation de la durée de cache.
• Rendu côté client ou en périphérie pour la personnalisation : Envisagez le rendu côté client ou en périphérie des petites personnalisations comme le nombre d'articles dans le panier, le statut de connexion ou les modifications mineures de menu pour conserver la fonctionnalité de mise en cache de page complète. Cela évite d'invalider le cache de la page entière pour des éléments dynamiques mineurs.
• Optimisez les configurations serveur : Vérifiez et ajustez les paramètres de votre serveur web pour la performance. Cela inclut les paramètres keep-alive, le nombre de processus workers, l'allocation mémoire et les valeurs de timeout. Des serveurs mal configurés peuvent gaspiller des ressources et augmenter les temps de réponse.
• Utilisez un réseau de diffusion de contenu (CDN) : Un CDN distribue le contenu statique de votre site web sur plusieurs nœuds edge (serveurs). Cela réduit la distance physique que les utilisateurs doivent parcourir pour accéder à votre contenu, ce qui se traduit par des temps de chargement plus rapides pour un public mondial. De plus, les CDN sont généralement mieux configurés que votre propre serveur. Consultez notre guide sur la configuration de Cloudflare pour un exemple pratique de mise en place.
• Réduisez le traitement côté serveur : Minimisez la quantité de travail que votre serveur effectue par requête. Précalculez les opérations coûteuses, utilisez des algorithmes efficaces et déplacez les traitements non essentiels vers des tâches en arrière-plan. Analysez le cycle de vie des requêtes de votre application pour trouver et éliminer les étapes de traitement inutiles.
• Utilisez HTTP/3 : HTTP/3 est la dernière version du protocole de transfert hypertexte. HTTP/3 est plus rapide et plus efficace que HTTP/2 et significativement plus rapide que HTTP/1.1. Passer à HTTP/3 peut améliorer les temps de chargement globaux des pages et potentiellement les trois métriques Core Web Vitals (LCP, INP, CLS). En savoir plus sur l'optimisation de la durée de connexion.
• Configurez les en-têtes Server-Timing : Ces en-têtes fournissent des informations détaillées sur la durée de traitement des différentes parties de votre page sur le serveur. Avec ces données, vous pouvez identifier les goulots d'étranglement et les axes d'amélioration, en vous concentrant spécifiquement sur l'amélioration du Largest Contentful Paint (LCP). Les en-têtes Server-Timing sont visibles dans le panneau Network des Chrome DevTools et peuvent être capturés par des outils RUM comme CoreDash.
• Journalisez les requêtes de base de données lentes et optimisez-les régulièrement : Activez la journalisation des requêtes lentes dans votre base de données (MySQL, PostgreSQL, MongoDB) et examinez les logs chaque semaine. L'optimisation des index, la restructuration des requêtes et l'ajout de couches de mise en cache pour les requêtes fréquentes peuvent réduire considérablement le TTFB.
• Utilisez la compression GZIP ou Brotli : GZIP, ou le plus récent Brotli, offre une compression à la volée des ressources textuelles (HTML, CSS, JavaScript) avant transmission, résultant en des tailles de fichiers environ 70 % plus petites. Brotli atteint généralement une compression 15 à 20 % meilleure que GZIP. Des tailles de fichiers plus petites se traduisent par des temps de chargement plus rapides.

Optimiser l'interactivité

L'Interaction to Next Paint (INP) mesure la rapidité avec laquelle votre site répond aux interactions utilisateur. Une mauvaise interactivité est souvent causée par des tâches JavaScript de longue durée qui bloquent le thread principal. Pour une décomposition complète des trois phases de l'INP, consultez nos guides sur le délai d'entrée, le temps de traitement et le délai de présentation.

• Implémentez un pattern idle-until-urgent pour les scripts coûteux : Cette approche consiste à prioriser les tâches critiques et à différer l'exécution JavaScript non essentielle jusqu'à ce que le thread principal du navigateur soit inactif. Cela garantit que les tâches critiques comme le rendu et les interactions utilisateur ne sont pas bloquées par des scripts de longue durée. Utilisez requestIdleCallback pour planifier les tâches non urgentes. En savoir plus sur l'optimisation du temps de traitement.
• Découpez les tâches longues en cédant le contrôle au thread principal : Les tâches JavaScript complexes peuvent bloquer le thread principal, retardant la réactivité. Diviser ces tâches en morceaux plus petits et redonner le contrôle au thread principal entre les morceaux permet au navigateur de gérer les interactions utilisateur et de maintenir une expérience fluide. Utilisez scheduler.yield() (si supporté) ou setTimeout(0) pour découper les tâches longues. Consultez notre guide sur l'amélioration de l'INP en abandonnant le défilement JavaScript.
• Fournissez un retour immédiat après une interaction : Les utilisateurs s'attendent à une réactivité immédiate après avoir interagi avec votre site web. Fournissez des indices visuels ou accusez réception de l'entrée utilisateur rapidement, même pendant que des tâches de longue durée sont en cours de traitement en arrière-plan. Utilisez les transitions CSS et la pseudo-classe :active pour un retour visuel instantané. Cela aide à maintenir un sentiment d'interactivité et empêche les utilisateurs de penser que le site web est figé.
• Utilisez des écouteurs d'événements passifs pour le défilement et le toucher : Ajoutez { passive: true } aux écouteurs d'événements de défilement et de toucher. Les écouteurs passifs indiquent au navigateur que le gestionnaire n'appellera jamais preventDefault(), lui permettant de commencer le défilement immédiatement sans attendre JavaScript. C'est particulièrement impactant sur les appareils mobiles et améliore directement l'INP pour les interactions liées au défilement.

Monitoring des Core Web Vitals

Surveiller vos Core Web Vitals en continu est essentiel pour détecter les régressions rapidement et valider que les optimisations ont l'impact attendu. Utilisez une combinaison d'outils en laboratoire, de données terrain et de monitoring des utilisateurs réels pour avoir une vue complète.

• Vérifiez Lighthouse régulièrement : Lighthouse est un outil d'audit gratuit et open-source de Google qui vous aide à identifier les problèmes de performance sur vos pages web. Bien que Lighthouse ne mesure pas les Core Web Vitals directement dans un contexte d'utilisateur réel, c'est un excellent outil pour tester et comparer périodiquement votre site web dans des conditions régulées et standardisées. Exécutez Lighthouse dans les pipelines CI/CD pour détecter les régressions avant le déploiement.
• Vérifiez les données historiques CrUX régulièrement : CrUX (Chrome User Experience Report) est un jeu de données public de Google qui fournit des données de performance réelles. CrUX est la source de données utilisée par Google pour déterminer si vous réussissez ou non les Core Web Vitals. Utilisez les données historiques pour repérer rapidement les régressions. Vous pouvez accéder aux données CrUX via PageSpeed Insights, le CrUX Dashboard ou l'API CrUX.
• Mettez en place un suivi RUM : Le RUM (Real User Monitoring) consiste à suivre les expériences réelles des utilisateurs sur votre site web. Les outils RUM collectent des données sur le temps réel de chargement des pages pour vos visiteurs dans différentes localisations et sur différents appareils. Cela fournit des informations précieuses sur les performances réelles, complétant les données simulées de Lighthouse et CrUX. Nous recommandons CoreDash comme outil de suivi RUM pour des données d'attribution détaillées des Core Web Vitals.
• Définissez des budgets de performance : Les budgets de performance fixent des objectifs de performance spécifiques (par exemple, LCP inférieur à 2,5 secondes, INP inférieur à 200 ms, CLS inférieur à 0,1) pour différentes métriques. Ils servent de repères pour guider vos efforts d'optimisation. Vérifier régulièrement vos performances par rapport à ces budgets vous aide à identifier les domaines nécessitant une attention immédiate et à prioriser les optimisations.
• Utilisez la segmentation : Utilisez la segmentation pour suivre vos types de visiteurs les plus précieux et les différents types de pages. Des volumes de trafic plus importants pourraient autrement masquer les problèmes de performance impactant spécifiquement ces groupes vitaux. Segmentez par type d'appareil, vitesse de connexion, géographie et modèle de page pour découvrir des problèmes cachés.

Optimiser le chemin critique de rendu

Le chemin critique de rendu est la séquence d'étapes que le navigateur suit pour convertir le HTML, le CSS et le JavaScript en pixels visibles. Optimiser ce chemin améliore directement le First Contentful Paint et le délai de rendu de l'élément LCP. Consultez également comment éviter une taille de DOM excessive.

• Minimisez le nombre de ressources critiques : Chaque ressource bloquant le rendu (CSS et JavaScript synchrone) doit être téléchargée et traitée avant que le navigateur puisse peindre. Réduisez le nombre de ressources critiques en différant les scripts non essentiels et en chargeant de manière asynchrone les feuilles de style non critiques.
• Optimisez l'ordre de chargement des ressources : Assurez-vous que le CSS critique et les polices se chargent en premier, suivis des images au-dessus de la ligne de flottaison, puis des scripts différés. Utilisez l'attribut fetchpriority et les indices de priorisation des ressources pour communiquer l'importance au navigateur.
• Réduisez la profondeur de l'arbre DOM : Les arbres DOM profondément imbriqués augmentent le temps de calcul des styles et le travail de mise en page. Visez une profondeur maximale de 32 niveaux et moins de 1 500 éléments DOM au total dans la mesure du possible. Une structure DOM plus plate améliore à la fois les performances de peinture et le délai de présentation INP.
• Privilégiez les classes et les ID aux balises d'éléments et aux attributs : Au lieu de p.important, utilisez .important. Cela réduit le besoin du navigateur de parcourir tous les éléments de ce type pour la correspondance des styles, ce qui accélère le recalcul des styles.
• Évitez l'imbrication profonde des sélecteurs : Plus vous imbriquez les sélecteurs CSS en profondeur, plus le navigateur doit effectuer de calculs. Essayez de restructurer votre HTML pour réduire l'imbrication ou utilisez des classes plus spécifiques proches de l'élément. Limitez la profondeur des sélecteurs à 3 niveaux maximum.
• Minimisez les sélecteurs descendants : Les sélecteurs comme .container > .content forcent le navigateur à vérifier chaque élément à l'intérieur du conteneur. Si possible, utilisez une classe plus directe sur l'élément de contenu pour une correspondance de sélecteur plus rapide.
• Consolidez les sélecteurs partageant les mêmes styles : Si plusieurs éléments partagent les mêmes styles, regroupez-les dans une seule classe ou utilisez une convention de nommage BEM (Block Element Modifier) pour une meilleure maintenabilité et un CSS plus compact.

Optimiser le consentement aux cookies

Les bannières de consentement aux cookies sont exigées par le RGPD et les réglementations similaires, mais elles peuvent avoir un impact significatif sur les Core Web Vitals si elles ne sont pas implémentées avec soin. Une bannière de consentement mal chargée peut retarder le LCP, provoquer du CLS et augmenter l'INP. Pour plus de détails, consultez notre article sur l'optimisation des widgets tiers pour les Core Web Vitals.

• Envisagez un consentement aux cookies côté serveur pour les pages dynamiques : Pour les pages rendues dynamiquement côté serveur, implémenter une solution côté serveur qui intègre la bannière de consentement dans la réponse HTML initiale est souvent plus rapide que de charger une solution JavaScript séparée. Cela élimine la requête réseau supplémentaire et la surcharge d'évaluation du script.
• Chargez les scripts de consentement aux cookies de manière asynchrone sur les pages en cache : Pour les pages en cache, chargez votre script de consentement aux cookies en mode asynchrone et envisagez d'ajouter fetchpriority="high" au script pour garantir qu'il se charge suffisamment tôt pour s'afficher avant l'interaction utilisateur.
• Gardez le texte de consentement court pour éviter les interférences avec le LCP : Les textes longs de notification de cookies peuvent prendre le dessus sur l'élément LCP car le navigateur considère le plus grand bloc de texte visible comme candidat potentiel au LCP. Envisagez d'écrire des textes plus courts ou de découper les textes en plusieurs paragraphes avec une surface visible plus petite.
• Auto-hébergez les scripts de notification de cookies : Mettez en cache et auto-hébergez les scripts et feuilles de style de notification de cookies autant que possible. Cela élimine les résolutions DNS et la surcharge de connexion vers les plateformes tierces de gestion du consentement et vous donne un contrôle total sur le comportement de chargement.

Optimiser les applications monopage

Les applications monopage (SPA) construites avec React, Vue, Angular ou des frameworks similaires font face à des défis uniques en matière de Core Web Vitals. Le rendu côté client peut retarder à la fois le FCP et le LCP, tandis que l'hydratation peut bloquer l'INP.

• Utilisez toujours le rendu côté serveur ou le pré-rendu : Les SPA qui reposent uniquement sur le rendu côté client forcent le navigateur à télécharger, analyser et exécuter le JavaScript avant qu'aucun contenu ne soit visible. Utilisez le SSR (Next.js, Nuxt, SvelteKit) ou le pré-rendu statique pour servir du HTML initial que le navigateur peut peindre immédiatement.
• Préférez les pré-rendus statiques à la génération dynamique : Les pré-rendus statiques (générés au moment du build) sont beaucoup plus rapides que les pré-rendus générés dynamiquement car ils peuvent être servis directement depuis un CDN sans aucun traitement côté serveur. Utilisez la génération statique pour les pages qui ne nécessitent pas de données par requête.
• Chargez les scripts tiers après l'hydratation : Pendant l'hydratation, le framework consomme déjà un temps significatif sur le thread principal pour rendre la page interactive. Charger des scripts tiers simultanément aggrave le problème et détériore le délai d'entrée. Différez tous les scripts non essentiels jusqu'à ce que le processus d'hydratation soit terminé.

Éviter une taille de DOM excessive

Un DOM volumineux (plus de 1 500 éléments ou une profondeur dépassant 32 niveaux) augmente l'utilisation mémoire, ralentit les calculs de styles et provoque des reflows de mise en page coûteux. Cela impacte directement le délai de présentation INP et les métriques de peinture. Consultez comment corriger une taille de DOM excessive.

• Réduisez les éléments DOM inutiles : Auditez votre HTML pour repérer les éléments englobants qui ne servent aucun objectif de style ou de structure. Remplacez les structures <div> profondément imbriquées par des éléments HTML sémantiques. Envisagez la virtualisation des longues listes avec des bibliothèques comme react-window ou virtual-scroller pour garder le DOM actif petit.
• Utilisez des sélecteurs JavaScript et CSS efficaces : Les sélecteurs CSS complexes et les requêtes DOM JavaScript (comme querySelectorAll avec des patterns larges) deviennent exponentiellement plus lents à mesure que la taille du DOM augmente. Utilisez des sélecteurs de classe spécifiques et limitez la portée des requêtes DOM aux sous-arbres autant que possible.
• Utilisez content-visibility: auto pour le contenu hors écran : La propriété CSS content-visibility: auto indique au navigateur de ne pas effectuer le rendu des éléments hors écran jusqu'à ce qu'ils soient affichés par défilement. Cela peut réduire considérablement le travail de rendu initial pour les pages avec de longues sections de contenu.

Optimiser les requêtes API

Les requêtes API qui bloquent le rendu ou retardent le contenu peuvent avoir un impact négatif sur le LCP et le TTFB. La récupération de données côté client est une source courante de LCP lent dans les applications monopage.

• Minimisez le nombre de requêtes API : Chaque requête API ajoute au temps de chargement global de la page. Évaluez les fonctionnalités de votre site web et identifiez les opportunités de réduire le nombre de requêtes API nécessaires pour rendre le contenu initial. Des techniques comme le regroupement de données (combiner plusieurs requêtes en une) et GraphQL peuvent réduire les allers-retours.
• Utilisez des API efficaces et optimisées : La conception et l'implémentation des API elles-mêmes peuvent impacter les performances. Assurez-vous d'utiliser des API bien conçues et optimisées pour la vitesse et l'efficacité. Implémentez des mécanismes de mise en cache côté API pour réduire les temps de réponse pour les données fréquemment demandées.
• Préchargez les requêtes API critiques : Similaire au préchargement des ressources critiques comme les images, précharger les requêtes API essentielles peut améliorer significativement la performance perçue. Utilisez <link rel="preload" as="fetch"> pour indiquer au navigateur de récupérer les API critiques en avance, minimisant les délais lorsqu'elles sont nécessaires pour le rendu du contenu initial. Consultez notre guide de priorisation des ressources pour plus de techniques.

Optimiser les widgets de chat

Les widgets de chat sont une cause courante de décalages de mise en page et peuvent même causer des problèmes avec le LCP s'ils sont chargés tôt. Pour une approche étape par étape, consultez comment implémenter un widget de chat avec des Core Web Vitals parfaits.

• Chargez les widgets de chat après le chargement du contenu principal : Personne dans l'histoire d'internet n'a jamais eu besoin de chatter avant que le contenu principal de la page ne soit chargé. Différez l'initialisation du widget de chat jusqu'à ce que la page ait terminé son rendu initial, en utilisant requestIdleCallback ou un déclencheur basé sur le défilement.
• Empêchez les décalages de mise en page des widgets de chat : Si les widgets de chat provoquent un décalage de mise en page, il est généralement judicieux de les masquer avec opacity: 0 jusqu'à ce qu'ils soient entièrement rendus sur la page. Cela permet au widget de se mettre en page en arrière-plan sans faire sauter le contenu visible. Utilisez une transition CSS pour faire apparaître le widget en fondu enchaîné.
• Choisissez des fournisseurs de widgets de chat légers : Comparez les offres. Certains widgets de chat sont beaucoup plus légers et causent moins de problèmes de Core Web Vitals que d'autres. Comparez la taille du bundle JavaScript, le nombre de requêtes réseau et l'impact sur l'INP des différents fournisseurs avant de vous engager.

Optimiser les performances des Service Workers

Les service workers peuvent améliorer significativement les performances des visites récurrentes en mettant en cache les ressources et même les réponses de pages complètes, réduisant le TTFB pour les visiteurs de retour. Cependant, un service worker mal implémenté peut en réalité ralentir la navigation. En savoir plus sur l'optimisation de la durée de cache.

• Mettez en cache les ressources critiques dans le service worker : Utilisez une stratégie cache-first pour les ressources statiques comme le CSS, le JavaScript, les polices et les images. Cela permet aux visiteurs récurrents de charger votre site presque instantanément depuis le cache local. Précachez les ressources les plus importantes pendant l'événement d'installation du service worker.
• Optimisez le code du service worker : Gardez votre service worker léger et efficace. Évitez les logiques de routage complexes, l'utilisation excessive de event.waitUntil() et les manifestes de précache volumineux qui ralentissent l'installation. Utilisez le pattern stale-while-revalidate pour les ressources qui changent fréquemment mais ne nécessitent pas une fraîcheur immédiate.

Optimiser le contenu vidéo

Les éléments vidéo peuvent devenir l'élément LCP s'ils sont le contenu visible le plus volumineux dans la zone d'affichage. Les vidéos volumineuses et non optimisées concurrencent également la bande passante avec d'autres ressources critiques.

• Compressez et optimisez les vidéos : Utilisez des codecs modernes comme H.264, VP9 ou AV1 avec des paramètres de qualité appropriés. Réduisez la résolution vidéo pour correspondre à la taille d'affichage maximale. Une vidéo affichée à 400 px de large n'a pas besoin d'être encodée en 1920 px. Utilisez l'encodage en deux passes pour le meilleur rapport qualité/taille de fichier.
• Utilisez le chargement différé pour les vidéos : Pour les vidéos sous la ligne de flottaison, utilisez l'attribut loading="lazy" sur les éléments <iframe> ou retardez le chargement vidéo avec l'API Intersection Observer. Remplacez les vidéos d'arrière-plan en lecture automatique par des images poster et chargez la vidéo uniquement lorsque l'utilisateur défile à proximité.
• Hébergez les vidéos sur un CDN rapide : Les fichiers vidéo sont volumineux et bénéficient grandement de la distribution CDN. Utilisez un CDN dédié aux vidéos ou un service d'hébergement (comme Cloudflare Stream, Mux ou Bunny.net) qui fournit le streaming à débit adaptatif, la distribution géographique et une livraison optimisée.
• Utilisez des images poster pour les éléments vidéo : Définissez toujours un attribut poster sur les éléments <video>. L'image poster donne au navigateur quelque chose à peindre immédiatement pendant le chargement de la vidéo, ce qui peut servir d'élément LCP. Optimisez l'image poster comme toute autre image LCP.