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 web fonts
  • Optimiser les scripts
  • Optimiser les styles
  • Optimiser les resource hints
  • Optimiser les icônes
  • Optimiser les temps de réponse du serveur
  • Optimiser l'interactivité
  • Surveillance des Core Web Vitals
  • Optimiser le chemin critique de rendu
  • Optimiser le consentement des cookies
  • Optimiser les Single Page Applications
  • Éviter une taille excessive du DOM
  • Optimiser les requêtes API
  • Optimiser les widgets de chat
  • Optimiser la performance des service workers
  • Optimiser le contenu vidéo

Optimiser les images

Les grandes images dans le viewport visible deviendront presque toujours l'élément Largest Contentful Paint. L'optimisation des images est l'une des actions les plus efficaces 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, lisez notre guide sur l'optimisation de l'image LCP.

• Redimensionnez les images pour correspondre aux dimensions maximales à l'écran: Cela garantit de ne jamais gaspiller d'octets en téléchargeant des images plus grandes que leur taille maximale affichée. Combinez cette pratique avec des images responsives pour les écrans plus petits. Servir des images à la bonne taille peut réduire la taille des fichiers de 50 % ou plus sans perte de qualité visible.
• Utilisez 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 apparaissent au défilement. Cela améliore le First Contentful Paint (FCP) et la vitesse globale de chargement de la page. N'appliquez jamais de lazy loading sur l'image LCP, car cela la retardera considérablement.
• Préchargez les images visuellement importantes comme l'élément LCP: Le préchargement ordonne au navigateur de récupérer les images critiques avant le reste du contenu. Cela priorise le LCP. Utilisez <link rel="preload" as="image"> combiné avec fetchpriority="high" pour de meilleurs résultats. C'est particulièrement important quand l'image LCP est référencée en CSS ou chargée via JavaScript.
• Définissez la largeur et la hauteur: Définir les dimensions de l'image à l'avance empêche les layout shifts causés par le navigateur qui attend le 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. Ils réservent ainsi l'espace correct.
• Utilisez des formats d'image modernes comme WebP ou AVIF: Ces formats offrent des fichiers plus petits que le JPEG ou le PNG en conservant une qualité similaire. Cela accélère les temps de chargement. Le WebP génère généralement des fichiers 25 à 34 % plus petits que le JPEG. L'AVIF peut réduire la taille de 50 %. Utilisez l'élément <picture> avec des fallbacks de format pour une compatibilité maximale entre navigateurs.
• Utilisez le lazy loading natif et désactivez le lazy loading basé sur JavaScript: Le lazy loading retarde le chargement des images hors du viewport jusqu'à ce qu'elles apparaissent au défilement. 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. Il ne nécessite ni parsing ni exécution de script supplémentaire.
• Utilisez des images responsives avec srcset: Cet attribut spécifie différentes versions d'image pour diverses tailles d'écran. Le navigateur affiche ainsi l'image optimale pour l'appareil de l'utilisateur. Vous évitez les téléchargements lourds 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 le reste du contenu pendant le décodage d'une image. Le moteur de rendu peut continuer à peindre d'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 aux images ajoutent 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 lors de votre processus de build.
• Évitez les images de fond CSS pour les éléments LCP: Le navigateur découvre les images de fond CSS plus tard que les éléments <img> dans le HTML. Si vous devez utiliser une image de fond comme élément LCP, préchargez-la avec une balise <link rel="preload"> pour assurer une découverte précoce. Apprenez-en plus sur le retard de chargement de la ressource LCP.

Optimiser les web fonts

Les web fonts peuvent retarder le First Contentful Paint, causer des layout shifts et concurrencer les ressources réseau initiales. Utilisez cette checklist pour garantir une expérience fluide avec les web fonts. 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 first paint 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 un fallback pendant le chargement de la web font en arrière-plan. Une fois la police prête, il la remplace de manière fluide. Apprenez-en plus sur comment garder le texte visible pendant le chargement de la webfont.
• Utilisez font-display: optional combiné au préchargement pour éliminer les layout shifts causés par les polices: Combiner font-display: optional avec le préchargement offre un bon équilibre entre la vitesse et les potentiels layout shifts. La valeur optional masque brièvement le texte (environ 100 ms) avant d'utiliser un fallback. Le préchargement ordonne au navigateur de récupérer la web font tôt. Cela minimise le temps passé sur les fallbacks et réduit les layout shifts.
• Utilisez des descripteurs font-face pour faire correspondre le fallback aux dimensions de la web font: Cela assure un CLS minimal lorsque la web font s'affiche. En spécifiant des métriques similaires avec size-adjust, ascent-override, descent-override et line-gap-override pour le fallback, vous empêchez le contenu de sauter pendant le chargement de la police.
• Créez des sous-ensembles (subsets) de polices pour n'inclure que les caractères nécessaires: Réduisez la taille du fichier de police en créant des sous-ensembles de polices. N'incluez que les caractères nécessaires à votre contenu. Des outils comme Font Squirrel, pyftsubset ou glyphhanger peuvent vous aider. Une police contenant le jeu complet de caractères latins passe souvent de plus de 100 Ko à moins de 20 Ko avec un sous-échantillonnage approprié.
• Limitez 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 chargées tardivement (chargées après le rendu initial). Chaque graisse de police supplémentaire ajoute 15 à 50 Ko au poids 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 initiaux optimisés et relativement inoffensifs peuvent concurrencer les ressources et retarder les métriques de rendu (LCP et FCP). Pour un guide complet, voir 14 méthodes pour différer le JavaScript.

• Supprimez le JavaScript inutile: Identifiez et éliminez le code JavaScript inutilisé 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 temps de traitement sur le main thread.
• Priorisez les scripts selon leur fonction et leur importance: Les scripts qui modifient considérablement le viewport visible doivent être render blocking. Les scripts importants doivent être différés ou chargés en asynchrone. Les scripts non essentiels doivent charger quand le navigateur est inactif. Consultez notre guide de priorisation des ressources pour une stratégie détaillée.
• Divisez le code et utilisez le lazy loading: Découpez les gros bundles JavaScript en plus petits morceaux. Chargez-les uniquement lorsque c'est nécessaire. Cela réduit le temps de chargement initial. Les bundlers modernes comme webpack, Rollup et esbuild gèrent la division automatique du code en se basant 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 introduisent une surcharge de performance importante. Évaluez leur nécessité. Cherchez des alternatives si possible. Chaque script tiers ajoute des requêtes DNS, un surcoût de connexion et du temps de traitement sur le main thread. Auditez régulièrement les scripts tiers avec l'onglet Network des Chrome DevTools.
• Chargez les scripts tiers de manière asynchrone: En raison de la nature imprévisible des scripts tiers, ne les laissez jamais bloquer le rendu. Utilisez l'attribut async ou defer sur toutes les balises de scripts tiers.
• Surveillez la performance 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 render blocking par défaut. Optimiser les styles améliorera directement les métriques de rendu. Suivez cette checklist pour améliorer la performance des styles de votre page. Le CSS render blocking impacte directement le First Contentful Paint et le retard 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 cela.
• 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 parser, améliorant ainsi la performance. Des outils comme PurgeCSS ou l'onglet Coverage des Chrome DevTools aident à identifier le CSS inutilisé.
• Inlinez le CSS critique: Servez les styles essentiels au rendu du contenu initial directement dans le HTML pour améliorer les métriques de rendu. 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 uniformément la taille des 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 équilibrée (10 à 15 Ko chacun). Cela optimise le chargement et permet au navigateur de traiter les styles progressivement.
• Chargez en asynchrone les styles hors écran: Pour les styles qui s'appliquent aux éléments hors du viewport initial, envisagez un chargement asynchrone via le modèle 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 resource hints

Les resource hints aident à prioriser les téléchargements des ressources critiques. Les ressources préchargées sont généralement mises en file d'attente et rendues disponibles pour le navigateur bien plus tôt que sans préchargement. Une utilisation efficace des resource hints peut réduire considérablement le retard de chargement de la ressource LCP. Pour une implémentation avancée, lisez notre article sur les 103 Early Hints.

• Supprimez les resource hints non critiques: Supprimez les hints de préchargement pour les ressources qui ne sont pas essentielles au chargement initial de la page. Cela empêche les téléchargements inutiles ou les connexions réseau de concurrencer ces ressources initiales limitées en bande passante. Chaque préchargement inutile consomme de la bande passante qui pourrait servir aux ressources critiques.
• Préconnectez-vous aux domaines critiques: Établissez très tôt des connexions avec des domaines importants (comme les CDN ou les fournisseurs de polices). 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 signale au navigateur des connexions potentielles. Cependant, preconnect priorise l'établissement complet de la connexion, tandis que DNS prefetch demande juste au navigateur de résoudre le nom de domaine à l'avance. Utilisez <link rel="dns-prefetch"> quand le surcoût d'une connexion complète preconnect n'est pas justifié.
• Préchargez l'élément LCP: Le LCP mesure le temps nécessaire au chargement du contenu principal. Précharger l'élément LCP ordonne au navigateur de prioriser le téléchargement de cette ressource critique. Cela réduit le temps avant que les utilisateurs ne voient 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. Cela évite les retards d'affichage du texte et améliore les layout shifts causés par le changement de police. 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 resource hints: Le code d'état HTTP 103 Early Hints permet au serveur d'envoyer des resource hints avant que la réponse complète ne soit prête. Si votre serveur ne supporte pas 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 fallback. Une livraison plus précoce des hints signifie une découverte plus rapide des ressources.
• 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> HTML, vous éliminez la dépendance à l'analyse CSS et permettez aux polices de charger en parallèle. Cela réduit à la fois le FCP et le risque de layout shift.

Optimiser les icônes

Les icônes peuvent alourdir considérablement votre page si elles ne sont pas optimisées. Les grandes icônes SVG en ligne gonflent votre HTML. Les polices d'icônes incluent souvent des milliers de glyphes inutilisés. Optimiser les icônes impacte à la fois le LCP (poids HTML/CSS réduit) et le CLS (réservation des dimensions correctes).

• Évitez les icônes SVG en ligne dans le HTML: Inliner de grandes icônes SVG peut augmenter la taille de votre code HTML et ralentir le temps de 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 précaution). Cela minimise la taille du HTML et permet la mise en cache des icônes par le navigateur. Une sprite sheet SVG externe est souvent le meilleur équilibre entre performance et flexibilité.
• Évitez les grandes polices d'icônes: N'utilisez jamais de grands ensembles 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. Vous réduirez la taille globale de la page web et améliorerez la vitesse de chargement. Un ensemble complet Font Awesome peut dépasser 100 Ko. Un sous-ensemble de 20 icônes peut peser 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. Cela empêche les layout shifts pendant leur chargement. Utilisez les attributs width et height sur les éléments SVG ou définissez des dimensions explicites en CSS.
• Dé-priorisez les ensembles d'icônes non critiques: Si les icônes ne sont pas critiques pour le rendu initial de votre page, chargez-les avec une priorité moindre. Cela garantit le chargement prioritaire du contenu essentiel et minimise l'impact sur les métriques Core Web Vitals. Utilisez le lazy loading ou chargez les feuilles de style d'icônes en asynchrone après le rendu initial.

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 rendu. 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 fournisseur d'hébergement rapide et fiable: Un fournisseur d'hébergement rapide avec une infrastructure solide peut considérablement améliorer les temps de réponse du serveur et la performance globale du site web. Évaluez les hébergeurs en utilisant des mesures TTFB réelles, pas des arguments marketing synthétiques.
• Optimisez le code côté serveur et les requêtes de base de données: Enregistrez fréquemment le temps d'exécution du code et des requêtes de base de données pour trouver les goulots d'étranglement. Améliorez la vitesse globale. Utilisez des outils de profilage de requêtes et de surveillance de la performance des applications (APM) pour identifier les endpoints lents.
• Implémentez des stratégies de mise en cache: Utilisez la mise en cache du navigateur et du serveur pour stocker les données fréquemment consultées. Vous réduisez le besoin de récupérer les données plusieurs fois et améliorez les temps de chargement. La mise en cache de la page complète peut réduire le TTFB de plusieurs secondes à moins de 100 ms. Apprenez-en plus sur l'optimisation de la durée de cache.
• Rendu côté client ou à l'edge pour la personnalisation: Envisagez un rendu côté client ou à l'edge (edge rendering) pour les petites personnalisations comme le nombre d'articles dans le panier, le statut de connexion ou les modifications mineures du menu. Vous conservez ainsi 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.
• Optimisez les configurations du serveur: Révisez et ajustez les paramètres de votre serveur web pour la performance. Cela inclut les paramètres keep-alive de connexion, le nombre de processus worker, l'allocation de 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 Content Delivery Network (CDN): Un CDN distribue le contenu statique de votre site web sur de multiples nœuds (serveurs) à l'edge. Cela réduit la distance physique que les utilisateurs doivent parcourir pour accéder à votre contenu. Les temps de chargement sont plus rapides pour les audiences mondiales. 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 tutoriel d'installation pratique.
• Réduisez le traitement côté serveur: Minimisez la quantité de travail effectuée par votre serveur pour chaque requête. Précalculez les opérations coûteuses. Utilisez des algorithmes efficaces. 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 HTTP. HTTP/3 est plus rapide et plus efficace que HTTP/2 et considérablement 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). Apprenez-en 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 le temps de traitement des différentes parties de votre page sur le serveur. Avec ces données, vous pouvez cibler les goulots d'étranglement et les zones à améliorer. Concentrez-vous spécifiquement sur l'amélioration du Largest Contentful Paint (LCP). Les en-têtes Server-Timing sont visibles dans l'onglet 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 revoyez les journaux 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.
• Utilisez la compression GZIP ou Brotli: GZIP, ou le plus récent Brotli, compresse à la volée les ressources textuelles (HTML, CSS, JavaScript) avant leur transmission. Cela réduit la taille des fichiers d'environ 70 %. Brotli obtient 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 mauvaise interactivité est souvent causée par de longues tâches JavaScript qui bloquent le main thread. Pour une analyse 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 modèle idle-until-urgent pour les scripts lourds: Cette approche consiste à prioriser les tâches critiques et à différer l'exécution du JavaScript non essentiel jusqu'à ce que le main thread 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 les tâches non urgentes. Apprenez-en plus sur l'optimisation du temps de traitement.
• Découpez les long tasks en utilisant le yielding sur le main thread: Les tâches JavaScript complexes peuvent bloquer le main thread et retarder la réactivité. Découpez ces tâches en morceaux plus petits. Utilisez le yielding pour redonner le contrôle au main thread entre chaque morceau. Le navigateur peut alors gérer les interactions utilisateur et maintenir une expérience fluide. Utilisez scheduler.yield() (si supporté) ou setTimeout(0) pour diviser les long tasks. Consultez notre guide sur l'amélioration de l'INP en abandonnant le défilement JavaScript.
• Fournissez un retour immédiat après l'interaction: Les utilisateurs s'attendent à une réactivité immédiate après avoir interagi avec votre site. Fournissez des indications visuelles ou acquittez l'interaction de l'utilisateur rapidement, même si des tâches longues s'exécutent 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 évite que les utilisateurs ne pensent que le site est figé.
• Utilisez des event listeners passifs pour le scroll et le touch: Ajoutez { passive: true } aux event listeners de défilement (scroll) et de toucher (touch). Les listeners passifs indiquent au navigateur que le gestionnaire n'appellera jamais preventDefault(). Il peut alors commencer le défilement immédiatement sans attendre le JavaScript. C'est particulièrement efficace sur mobile et améliore directement l'INP pour les interactions liées au défilement.

Surveillance 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 lab data, de field data et de RUM pour obtenir une vue complète.

• Vérifiez Lighthouse régulièrement: Lighthouse est un outil d'audit open-source et gratuit de Google. Il vous 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 utilisateur réel, c'est un excellent outil pour tester périodiquement et comparer votre site dans des conditions régulées et standardisées. Exécutez Lighthouse dans vos 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 ensemble 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 passez ou non les Core Web Vitals. Utilisez l'historique des données 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.
• Mettez 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 qu'il faut réellement pour charger les pages chez vos visiteurs à différents endroits et sur divers appareils. Cela fournit des informations précieuses sur la performance en conditions réelles, complétant les données simulées de Lighthouse et de CrUX. Nous recommandons CoreDash comme outil de suivi RUM pour obtenir des données d'attribution détaillées sur les Core Web Vitals.
• Définissez des budgets de performance: Les budgets de performance fixent des cibles spécifiques (par exemple, un LCP inférieur à 2,5 secondes, un INP inférieur à 200 ms, un CLS inférieur à 0,1) pour différentes métriques. Ils servent de références pour guider vos efforts d'optimisation. Vérifier régulièrement votre performance par rapport à ces budgets vous aide à identifier les zones 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 vos différents types de pages. De gros volumes de trafic pourraient autrement masquer des problèmes de performance affectant spécifiquement ces groupes vitaux. Segmentez par type d'appareil, vitesse de connexion, géographie et modèle de page pour découvrir les problèmes cachés.

Optimiser le chemin critique de rendu

Le chemin critique de rendu 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 retard de rendu de l'élément LCP. Consultez également comment éviter une taille excessive du DOM.

• Minimisez le nombre de ressources critiques: Chaque ressource render blocking (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 et les polices critiques chargent en premier, suivis des images au-dessus de la ligne de flottaison, puis des scripts différés. Utilisez l'attribut fetchpriority et nos conseils de priorisation des ressources pour communiquer l'importance au navigateur.
• Réduisez la profondeur de l'arbre DOM: Des arbres DOM profondément imbriqués augmentent le temps de calcul des styles et le travail de layout. Visez une profondeur maximale de 32 niveaux et moins de 1 500 éléments DOM au total si possible. Une structure DOM plus plate améliore la performance de rendu et le délai de présentation INP.
• Privilégiez les classes et les IDs aux balises d'éléments et attributs: Au lieu de p.important, utilisez .important. Le navigateur n'a plus besoin de chercher à travers tous les éléments de ce type pour appliquer le style. Le recalcul des styles est plus rapide.
• Évitez d'imbriquer profondément les sélecteurs: Plus vous imbriquez vos sélecteurs CSS, plus le navigateur effectue 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 dans le 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 la convention de nommage BEM (Block Element Modifier). Vous obtiendrez une meilleure maintenabilité et un fichier CSS plus petit.

Optimiser le consentement des cookies

Les bannières de consentement des cookies sont exigées par le RGPD et les réglementations similaires. Elles peuvent cependant fortement impacter les Core Web Vitals si elles sont mal implémentées. Une bannière mal chargée peut retarder le LCP, causer un CLS et augmenter l'INP. Pour plus de détails, lisez comment optimiser les widgets tiers pour les Core Web Vitals.

• Envisagez un consentement des 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 dans la réponse HTML initiale est souvent plus rapide que de charger une solution JavaScript. Cela élimine la requête réseau supplémentaire et le surcoût d'évaluation du script.
• Chargez en asynchrone les scripts de consentement sur les pages mises en cache: Pour les pages mises en cache, chargez votre script de consentement de cookies en asynchrone. Envisagez d'ajouter fetchpriority="high" au script pour vous assurer qu'il charge assez tôt pour s'afficher avant l'interaction de l'utilisateur.
• Gardez le texte de consentement court pour éviter les interférences avec le LCP: Les textes d'avis de cookies trop longs peuvent s'accaparer l'élément LCP. Le navigateur considère le plus grand bloc de texte visible comme un candidat LCP potentiel. Rédigez des textes plus courts ou divisez-les en plusieurs paragraphes avec une zone 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 requêtes DNS et les surcoûts de connexion vers les plateformes tierces de gestion du consentement. Vous obtenez un contrôle total sur le comportement de chargement.

Optimiser les Single Page Applications

Les Single Page Applications (SPA) construites avec React, Vue, Angular ou des frameworks similaires rencontrent des défis Core Web Vitals uniques. Le rendu côté client peut retarder à la fois le FCP et le LCP. 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, parser et exécuter le JavaScript avant que le moindre contenu ne soit visible. Utilisez le SSR (Next.js, Nuxt, SvelteKit) ou le prérendu statique pour servir un 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 lors du build) sont beaucoup plus rapides que les prérendus générés dynamiquement. 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 important sur le main thread 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 excessive du DOM

Un grand DOM (plus de 1 500 éléments ou une profondeur dépassant 32 niveaux) augmente l'utilisation de la mémoire, ralentit les calculs de style et provoque des reflows de layout coûteux. Cela impacte directement le délai de présentation INP et les métriques de rendu. Lisez comment corriger une taille de DOM excessive.

• Réduisez les éléments DOM inutiles: Auditez votre HTML pour trouver les éléments conteneurs (wrappers) qui n'ont aucune utilité structurelle ou de style. Remplacez les structures <div> profondément imbriquées par des éléments HTML sémantiques. Envisagez de virtualiser les longues listes avec des bibliothèques comme react-window ou virtual-scroller pour garder le DOM actif de petite taille.
• Utilisez des sélecteurs CSS et JavaScript efficaces: Les sélecteurs CSS complexes et les requêtes DOM JavaScript (comme querySelectorAll avec des modèles larges) deviennent exponentiellement plus lents à mesure que la taille du DOM augmente. Utilisez des sélecteurs de classe spécifiques. Limitez la portée des requêtes DOM aux sous-arbres chaque fois que possible.
• Utilisez content-visibility: auto pour le contenu hors écran: La propriété CSS content-visibility: auto indique au navigateur d'ignorer le rendu des éléments hors écran jusqu'à ce qu'ils apparaissent au 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 impacter négativement le LCP et le TTFB. La récupération de données côté client est une cause fréquente de LCP lent dans les Single Page Applications.

• 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. Identifiez les opportunités de réduire le nombre de requêtes API nécessaires pour rendre le contenu initial. Des techniques comme le data batching (regrouper plusieurs requêtes en une seule) 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 impactent les performances. Assurez-vous d'utiliser des API bien conçues, optimisées pour la vitesse et l'efficacité. Implémentez des mécanismes de mise en cache du côté de l'API pour réduire les temps de réponse des données fréquemment demandées.
• Préchargez les requêtes API critiques: Tout comme le préchargement de ressources critiques comme les images, le préchargement des requêtes API essentielles peut considérablement améliorer les performances perçues. Utilisez <link rel="preload" as="fetch"> pour ordonner au navigateur de récupérer les API critiques tôt. Vous minimisez les retards lorsqu'elles sont nécessaires pour le rendu du contenu initial. Consultez notre guide de priorisation des ressources pour d'autres techniques.

Optimiser les widgets de chat

Les widgets de chat sont une cause fréquente de layout shifts et peuvent même poser des problèmes avec le LCP s'ils sont chargés tôt. Pour une approche étape par étape, lisez 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. Utilisez requestIdleCallback ou un déclencheur basé sur le défilement.
• Empêchez les layout shifts du widget de chat: Si les widgets de chat provoquent un layout shift, il est judicieux de les masquer avec opacity: 0 jusqu'à ce qu'ils soient entièrement rendus sur la page. Le widget s'organise en arrière-plan sans faire sauter le contenu visible. Utilisez une transition CSS pour faire apparaître le widget en douceur.
• 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 de différents fournisseurs avant de vous engager.

Optimiser la performance des service workers

Les service workers peuvent considérablement améliorer la performance des visites récurrentes en mettant en cache les assets et même les réponses de pages complètes. Cela réduit le TTFB pour les visiteurs qui reviennent. Cependant, un service worker mal implémenté peut en réalité ralentir la navigation. Apprenez-en plus sur l'optimisation de la durée de cache.

• Mettez 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. Les visiteurs récurrents chargent ainsi votre site presque instantanément depuis le cache local. Préchargez (precache) les ressources les plus importantes lors de 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 grands manifestes de préchargement qui ralentissent l'installation. Utilisez le modèle 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 constituent le plus grand contenu visible dans le viewport. Les grandes vidéos non optimisées concurrencent également la bande passante des autres ressources critiques.

• Compressez et optimisez les vidéos: Utilisez des codecs modernes comme le H.264, VP9 ou AV1 avec des paramètres de qualité appropriés. Réduisez la résolution de la vidéo pour correspondre à la taille d'affichage maximale. Une vidéo affichée à 400 pixels de large n'a pas besoin d'être encodée à 1920 pixels. Utilisez un encodage en deux passes pour obtenir le meilleur ratio qualité/taille de fichier.
• Utilisez 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 de la vidéo avec l'API Intersection Observer. Remplacez les vidéos de fond en lecture automatique par des images poster. Chargez la vidéo uniquement lorsque l'utilisateur fait défiler la page vers celle-ci.
• Hébergez les vidéos sur un CDN rapide: Les fichiers vidéo sont volumineux et bénéficient grandement de la distribution par CDN. Utilisez un CDN ou un service d'hébergement dédié à la vidéo (comme Cloudflare Stream, Mux ou Bunny.net) qui fournit un streaming à bitrate adaptatif, une 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 n'importe quelle autre image LCP.