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 du serveur
  • Optimiser l'interactivité
  • Suivi des Core Web Vitals
  • Optimiser le chemin de rendu critique
  • 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 grandes images dans le viewport visible deviennent, la plupart du temps, l'élément Largest Contentful Paint. L'optimisation des images est l'une des actions les plus impactantes pour le LCP. Utilisez ces éléments de la checklist Core Web Vitals pour améliorer la vitesse des images. Pour la stratégie complète, consultez notre guide sur comment optimiser l'image LCP.

• Redimensionner les images pour correspondre aux dimensions d'affichage maximales : Cela garantit qu'aucun octet n'est gaspillé pour télécharger des images plus grandes que leur taille d'affichage maximale. 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 perte de qualité visible.
• Utiliser le lazy loading pour les images sous la ligne de flottaison : Le lazy loading retarde le chargement des images hors du viewport jusqu'à ce qu'elles soient scrollées dans la vue, améliorant le First Contentful Paint (FCP) et la vitesse globale de chargement de la page. Ne faites jamais de lazy loading pour l'image LCP, car cela la retarderait considérablement.
• Précharger 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 les 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éfinir la largeur et la hauteur : Définir les dimensions des images en amont évite les décalages de mise en page causés par le navigateur en attente du chargement des images. Cela améliore le CLS. Les navigateurs modernes utilisent les attributs width et height pour calculer le ratio d'aspect avant le chargement de l'image, réservant l'espace correct.
• Utiliser des formats d'image modernes comme WebP ou AVIF : Ces formats offrent des tailles de fichier plus petites par rapport à JPEG ou PNG tout en maintenant une qualité similaire, ce qui accélère les temps de chargement. WebP atteint généralement des fichiers 25 à 34 % plus petits que JPEG, tandis qu'AVIF peut réduire la taille du fichier jusqu'à 50 %. Utilisez l'élément <picture> avec des fallback de format pour une compatibilité navigateur maximale.
• Utiliser le lazy loading natif et désactiver le lazy loading basé sur JavaScript : Le lazy loading retarde le chargement des images hors du viewport jusqu'à ce qu'elles soient scrollées dans la vue. Le lazy loading 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.
• Utiliser les images responsives avec srcset : Cet attribut spécifie différentes versions d'image pour différentes tailles d'écran, garantissant que le navigateur délivre 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.
• Ajouter decoding="async" : L'attribut decoding="async" empêche le navigateur de bloquer d'autres contenus pendant le décodage d'une image. Cela permet au moteur de rendu de continuer à peindre d'autres éléments pendant que le décodage de l'image se fait en parallèle.
• Supprimer 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 du fichier 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.
• Éviter les images d'arrière-plan CSS pour les éléments LCP : Les images d'arrière-plan référencées dans le CSS sont découvertes plus tard par le navigateur que les éléments <img> dans le 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 monopoliser les ressources de bande passante précoces. Utilisez cette checklist pour garantir une expérience de police web fluide. Pour les bonnes pratiques d'hébergement de polices, consultez notre guide sur l'auto-hébergement des Google Fonts.

• Utiliser 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 fallback pendant le chargement de 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 que le texte reste visible pendant le chargement des polices web.
• Utiliser 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 fallback. Le préchargement indique au navigateur de récupérer la police web tôt, minimisant le temps passé sur les polices de fallback et réduisant les décalages de mise en page.
• Utiliser les descripteurs font-face pour que la police de fallback corresponde aux dimensions 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 fallback, vous pouvez empêcher le contenu de sauter lors du chargement de la police.
• Subsetter les polices pour inclure uniquement les caractères nécessaires : Réduisez la taille des fichiers de police en subssettant les polices pour inclure uniquement 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 le jeu complet de caractères latins peut souvent être réduite de plus de 100 Ko à moins de 20 Ko avec un subsetting approprié.
• Limiter le nombre de graisses et de styles de police : Évitez de charger des variations de police excessives. 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 supplémentaire ajoute 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 précoces optimisés et relativement inoffensifs peuvent monopoliser les ressources et retarder les métriques de peinture (LCP et FCP). Pour un guide complet, consultez 14 méthodes pour différer JavaScript.

• Supprimer 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 de 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.
• Prioriser les scripts selon leur fonction et leur importance : Les scripts qui effectuent des modifications importantes du viewport visible doivent être bloquants pour le rendu. Les scripts importants doivent être différés ou chargés en async. Les scripts secondaires doivent se charger quand le navigateur est inactif. Consultez notre guide de priorisation des ressources pour une stratégie détaillée.
• Code splitting et lazy loading : Divisez les gros bundles JavaScript en morceaux plus petits et chargez-les uniquement en cas de besoin. Cela réduit le temps de chargement initial. Les bundlers modernes comme webpack, Rollup et esbuild supportent le code splitting automatique basé sur les imports dynamiques.
• Minifier et recompiler 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 %.
• Limiter 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 du thread principal. Auditez régulièrement les scripts tiers à l'aide du panneau Network de Chrome DevTools.
• Charger 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 script tierces.
• Surveiller 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 améliorera les métriques de peinture. Suivez la checklist pour améliorer les performances des styles de votre page web. Le CSS bloquant le rendu impacte directement à la fois 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é.

• Minifier 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.
• Supprimer 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 les performances. Des outils comme PurgeCSS ou l'onglet Coverage de Chrome DevTools aident à identifier le CSS inutilisé.
• Intégrer le CSS critique en inline : 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éguliers. Cette technique peut réduire le FCP en éliminant l'aller-retour nécessaire pour récupérer une feuille de style externe.
• Répartir équitablement les tailles de fichiers CSS : Bien qu'il puisse sembler efficace de combiner tout le CSS en un seul fichier, des 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émentale.
• Charger les styles hors-écran de manière asynchrone : Pour les styles qui s'appliquent aux éléments en dehors du viewport initial, 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 les téléchargements de 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 l'article sur les 103 Early Hints.

• Supprimer les indices de ressources non critiques : Supprimez les indices 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 monopolisent ces premières ressources de bande passante limitées. Chaque préchargement inutile consomme de la bande passante qui pourrait être utilisée pour les ressources critiques.
• Préconnecter aux domaines critiques : Établissez des connexions avec les domaines importants (comme les réseaux de diffusion de contenu ou les fournisseurs de polices) en amont. Cela accélère le téléchargement des ressources critiques depuis ces domaines en complétant les handshakes DNS, TCP et TLS à l'avance. Utilisez <link rel="preconnect" href="https://example.com"> pour les origines tierces critiques.
• Envisager 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écharger l'élément LCP : Le LCP mesure le temps nécessaire au chargement du contenu principal. 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 pour que les utilisateurs voient le contenu principal. C'est particulièrement important pour les images référencées dans le CSS ou chargées via JavaScript.
• Précharger 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 police. Utilisez <link rel="preload" as="font" type="font/woff2" crossorigin> pour vos polices les plus importantes.
• Préférer 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 en fallback. Une livraison plus précoce des indices signifie une découverte plus rapide des ressources.
• Précharger les polices avant que les fichiers CSS ne les découvrent : Les polices référencées dans le 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 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 inline 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 HTML/CSS réduit) et le CLS (réservation correcte des dimensions).

• Éviter les icônes SVG inline dans le HTML : Intégrer de grandes icônes SVG en inline peut augmenter la taille de votre code HTML et ralentir le chargement de la page. Envisagez des méthodes alternatives comme les servir en 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. Un sprite sheet SVG externe est souvent le meilleur équilibre entre performance et flexibilité.
• Éviter les grandes polices d'icônes : N'utilisez jamais de grands jeux d'icônes comme Font Awesome dans leur intégralité. Utilisez le subsetting pour créer des polices d'icônes optimisées ou des SVG individuels pour 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éserver 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 évite 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éprioriser 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 faible. Cela garantit que le contenu essentiel se charge en premier et minimise l'impact sur les métriques Core Web Vitals. Utilisez le lazy loading ou chargez les feuilles de style d'icônes de manière asynchrone après le premier affichage.

Optimiser les temps de réponse du serveur

Les temps de réponse du 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.

• Utiliser un hébergeur rapide et fiable : Un hébergeur rapide avec une infrastructure solide peut améliorer significativement les temps de réponse du serveur et les performances globales du site. Évaluez les hébergeurs à l'aide de mesures TTFB en conditions réelles, et non de promesses marketing synthétiques.
• Optimiser le code côté serveur et les requêtes de base de données : Enregistrez fréquemment 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 des outils de profilage de requêtes et de monitoring des performances applicatives (APM) pour identifier les endpoints lents.
• Mettre en place 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 consultées, réduisant le besoin de récupérations de données 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 plusieurs secondes à moins de 100 ms. En savoir plus sur l'optimisation de la durée de cache.
• Rendu côté client ou en edge pour la personnalisation : Envisagez le rendu côté client ou en edge des petites personnalisations comme le compteur de panier, le statut de connexion ou les modifications mineures du menu pour conserver la fonctionnalité de cache de page complète. Cela évite d'invalider le cache de la page entière pour des éléments dynamiques mineurs.
• Optimiser les configurations du serveur : Révisez et ajustez les paramètres de votre serveur web pour la performance. Cela inclut les paramètres de keep-alive de connexion, le nombre de processus worker, 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.
• Utiliser un réseau de diffusion de contenu (CDN) : Un CDN distribue le contenu statique de votre site sur plusieurs nœuds edge (serveurs). Cela réduit la distance physique que les utilisateurs doivent parcourir pour accéder à votre contenu, ce qui accélère les temps de chargement 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 guide de mise en place pratique.
• Réduire 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 le traitement non essentiel 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.
• Utiliser 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 de la page et potentiellement les trois métriques Core Web Vitals (LCP, INP, CLS). En savoir plus sur l'optimisation de la durée de connexion.
• Configurer les en-têtes Server-Timing : Ces en-têtes fournissent des informations détaillées sur le temps de traitement des différentes parties de votre page côté 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 de Chrome DevTools et peuvent être capturés par des outils RUM comme CoreDash.
• Journaliser les requêtes de base de données lentes et les optimiser 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 cache pour les requêtes fréquentes peuvent réduire considérablement le TTFB.
• Utiliser 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 fichiers environ 70 % plus petits. Brotli atteint généralement une compression 15 à 20 % meilleure que GZIP. Des fichiers plus petits 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 des utilisateurs. Une interactivité médiocre est souvent causée par des tâches JavaScript longues 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émenter un pattern idle-until-urgent pour les scripts coûteux : Cette approche consiste à prioriser les tâches critiques et à différer l'exécution du JavaScript non essentiel 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 longs. Utilisez requestIdleCallback pour planifier le travail non urgent. En savoir plus sur l'optimisation du temps de traitement.
• Découper les longues tâches en cédant le 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 céder 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() (lorsque supporté) ou setTimeout(0) pour découper les longues tâches. Consultez notre guide sur l'amélioration de l'INP en abandonnant le scrolling JavaScript.
• Fournir un retour immédiat après une interaction : Les utilisateurs s'attendent à une réactivité immédiate après avoir interagi avec votre site. Fournissez des indices visuels ou accusez réception de la saisie utilisateur rapidement, même pendant que des tâches longues 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 est figé.
• Utiliser des écouteurs d'événements passifs pour le scroll et le tactile : Ajoutez { passive: true } aux écouteurs d'événements de scroll et tactiles. Les écouteurs passifs indiquent au navigateur que le handler n'appellera jamais preventDefault(), lui permettant de commencer à scroller 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 scroll.

Suivi des Core Web Vitals

Surveiller vos Core Web Vitals en continu est essentiel pour détecter les régressions tôt et valider que les optimisations ont l'impact attendu. Utilisez une combinaison d'outils de lab, de données terrain et de Real User Monitoring pour une vision complète.

• Vérifier Lighthouse régulièrement : Lighthouse est un outil d'audit gratuit et open-source de Google qui aide à identifier les problèmes de performance sur vos pages web. Bien que Lighthouse ne mesure pas directement les Core Web Vitals dans un contexte d'utilisateur réel, c'est un excellent outil pour tester et comparer périodiquement votre site 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érifier régulièrement les données historiques CrUX : CrUX (Chrome User Experience Report) est un jeu de données public de Google qui fournit des données de performance du monde réel. 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 tableau de bord CrUX ou l'API CrUX.
• Mettre en place un suivi RUM : Le RUM (Real User Monitoring) consiste à suivre les expériences réelles des utilisateurs sur votre site. Les outils RUM collectent des données sur le temps de chargement réel des pages pour vos visiteurs dans différents endroits 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éfinir des budgets de performance : Les budgets de performance fixent des objectifs de performance spécifiques (par exemple, LCP sous 2,5 secondes, INP sous 200 ms, CLS sous 0,1) pour différentes métriques. Ils servent de références pour guider vos efforts d'optimisation. Vérifier régulièrement vos performances par rapport à ces budgets aide à identifier les domaines nécessitant une attention immédiate et à prioriser les optimisations.
• Utiliser la segmentation : Utilisez la segmentation pour suivre vos types de visiteurs les plus précieux et les différents types de pages. De grands volumes de trafic peuvent masquer des problèmes de performance affectant spécifiquement ces groupes vitaux. Segmentez par type d'appareil, vitesse de connexion, géographie et template de page pour découvrir des problèmes cachés.

Optimiser le chemin de rendu critique

Le chemin de rendu critique est la séquence d'étapes que le navigateur effectue 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.

• Minimiser le nombre de ressources critiques : Chaque ressource bloquante pour 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.
• Optimiser 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éduire 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 lorsque c'est possible. Une structure DOM plus plate améliore à la fois les performances de peinture et le délai de présentation de l'INP.
• Privilégier les classes et les IDs plutôt que les sélecteurs d'éléments et d'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 de styles, résultant en un recalcul de styles plus rapide.
• Éviter l'imbrication profonde des sélecteurs : Plus vous imbriquez les sélecteurs CSS, 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.
• Minimiser 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.
• Consolider les sélecteurs avec 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 une sortie CSS plus petite.

Optimiser le consentement aux cookies

Les bannières de consentement aux cookies sont requises par le RGPD et les réglementations similaires, mais elles peuvent impacter significativement 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, causer du CLS et augmenter l'INP. Pour plus de détails, consultez l'article sur l'optimisation des widgets tiers pour les Core Web Vitals.

• Envisager le 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 de script.
• Charger les scripts de consentement aux cookies en async sur les pages en cache : Pour les pages en cache, chargez votre script de consentement aux cookies en async et envisagez d'ajouter fetchpriority="high" au script pour garantir un chargement suffisamment précoce avant l'interaction utilisateur.
• Garder le texte de consentement court pour éviter l'interférence avec le LCP : Les textes d'avis de cookies longs 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 zone visible plus petite.
• Auto-héberger les scripts de notification de cookies : Mettez en cache et auto-hébergez les scripts et feuilles de style de notification de cookies chaque fois que possible. Cela élimine les résolutions DNS et la surcharge de connexion vers les plateformes de gestion de consentement tierces 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 Core Web Vitals uniques. Le rendu côté client peut retarder à la fois le FCP et le LCP, tandis que l'hydratation peut bloquer l'INP.

• Toujours utiliser 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érer les pré-rendus statiques à la génération dynamique : Les pré-rendus statiques (générés lors 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.
• Charger les scripts tiers après l'hydratation : Pendant l'hydratation, le framework consomme déjà un temps significatif du thread principal pour rendre la page interactive. Charger des scripts tiers simultanément aggrave le problème et dégrade le délai d'entrée. Différez tous les scripts non essentiels jusqu'à la fin du processus d'hydratation.

É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 à la fois le délai de présentation de l'INP et les métriques de peinture. Consultez comment corriger une taille de DOM excessive.

• Réduire les éléments DOM inutiles : Auditez votre HTML à la recherche d'éléments wrapper 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.
• Utiliser 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 chaque fois que possible.
• Utiliser content-visibility: auto pour le contenu hors écran : La propriété CSS content-visibility: auto indique au navigateur de passer le rendu des éléments hors écran jusqu'à ce qu'ils soient scrollés dans la vue. 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 impacter négativement 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.

• Minimiser 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 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 batching de données (combiner plusieurs requêtes en une) et GraphQL peuvent réduire les allers-retours.
• Utiliser 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écharger les requêtes API critiques : Comme pour le préchargement de ressources critiques telles que les images, précharger les requêtes API essentielles peut améliorer significativement les performances perçues. Utilisez <link rel="preload" as="fetch"> pour indiquer au navigateur de récupérer les API critiques tôt, minimisant les retards 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 fréquente 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.

• Charger 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 scroll.
• Empêcher les décalages de mise en page des widgets de chat : Si les widgets de chat causent 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 positionner en arrière-plan sans faire sauter le contenu visible. Utilisez une transition CSS pour faire apparaître le widget en douceur.
• Choisir 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 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épétées en mettant en cache les assets 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.

• Mettre en cache les assets critiques dans le Service Worker : Utilisez une stratégie cache-first pour les assets statiques comme le CSS, le JavaScript, les polices et les images. Cela permet aux visiteurs réguliers de charger votre site presque instantanément depuis le cache local. Pré-mettez en cache les ressources les plus importantes lors de l'événement d'installation du Service Worker.
• Optimiser le code du Service Worker : Gardez votre Service Worker léger et efficace. Évitez la logique de routage complexe, 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 large dans le viewport. Les vidéos volumineuses et non optimisées monopolisent également la bande passante au détriment d'autres ressources critiques.

• Compresser et optimiser 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 qui s'affiche à 400 px de large n'a pas besoin d'être encodée à 1920 px. Utilisez l'encodage en deux passes pour le meilleur rapport qualité/taille de fichier.
• Utiliser le lazy loading 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 scrolle à proximité.
• Héberger 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 vidéo dédié 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 la livraison optimisée.
• Utiliser 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 n'importe quelle autre image LCP.