Optimisez l'image du Largest Contentful Paint

Optimisez l'image du Largest Contentful Paint

Ce guide fait partie du hub Largest Contentful Paint (LCP). Sur la plupart des sites, l'élément LCP est une image. Ratez l'image et votre score LCP en souffrira. Cet article détaille toutes les techniques pour la rendre rapide.

Selon Google, seulement 65 % de toutes les pages vues sur internet (ordinateur et mobile inclus) ont un « bon » score Largest Contentful Paint. Cela signifie que 35 % des pages vues échouent. C'est en partie à cause d'erreurs liées aux images. Cet article détaille les bonnes pratiques et les erreurs courantes lorsque des images deviennent l'élément Largest Contentful Paint.

Bien que tous ces facteurs comptent, si votre élément LCP est une image (et c'est souvent le cas !), vous pouvez prendre des mesures simples pour qu'elle charge aussi vite que possible.

Expériences avec le Largest Contentful Paint

Je dis toujours : écoutez et apprenez, mais ne croyez personne sur parole. Trop de « gourous » diffusent de fausses informations. C'est pourquoi j'ai créé une expérience LCP entièrement automatisée. Vous pouvez y vérifier par vous-même ce qui se passe quand l'élément LCP n'est pas chargé de manière optimale. Consultez mon LCP Test sur GitHub ou essayez la démo en direct !

Elle testera automatiquement plusieurs scénarios LCP pour vous et affichera les résultats. Je discuterai de ces scénarios ci-dessous et j'expliquerai comment et pourquoi ils accélèrent ou ralentissent l'élément LCP image.

1. Contrôlez le candidat LCP : la stratégie « Text-First »

Le moyen le plus rapide d'améliorer un Largest Contentful Paint basé sur une image ? N'utilisez pas d'image. Oui, vous avez bien lu. Je vous explique.

Pourquoi le texte est plus rapide qu'une image. La différence de performance réside dans le pipeline de requêtes. Un nœud texte (comme un <h1> ou un <p>) fait partie du document HTML principal. Il ne nécessite aucune requête de ressource distincte ; son rendu n'est bloqué que par le CSS. Une image, en revanche, est une ressource externe qui nécessite sa propre requête HTTP. Cela ajoute de la latence réseau (DNS, TCP, TLS et temps de téléchargement) en plus d'être bloqué par le CSS. Cette différence est la raison principale de l'écart de performance. C'est pourquoi contrôler le candidat LCP est une stratégie puissante de niveau expert.

Alors, images ou texte ? Les images sont importantes ; elles rendent votre site visuellement attrayant. Mais les Core Web Vitals se moquent de savoir quel élément devient le LCP. Quand l'élément LCP est basé sur du texte, il se produit généralement en même temps que le First Contentful Paint.

Devez-vous passer à un élément Largest Contentful Paint textuel ? Cela dépend. Les images comptent et rendent votre site esthétique. Je ne vous conseillerai donc pas de revenir à des éléments textuels ennuyeux. Mais des erreurs se produisent. Si j'avais un euro pour chaque page de catégorie victime de l'anti-pattern du « LCP accidentel »... Cela se produit quand une page « oublie » d'ajouter un texte de catégorie descriptif au-dessus de la ligne de flottaison. Une image de produit en lazy loading devient alors le LCP et retarde les temps de chargement de plusieurs secondes. Cela arrive souvent quand les designers placent une grande bannière hero tout en haut du DOM, avant le moindre titre important. Le navigateur n'a d'autre choix que de sélectionner un candidat LCP plus lent.

2. Utilisez le format d'image le plus rapide disponible

Sans entrer dans un débat passionné pour grappiller le dernier octet ou trouver les réglages parfaits pour WebP contre AVIF, soyons d'accord sur un point. Les anciens formats comme JPEG et PNG sont plus lourds et plus lents que les formats modernes comme WebP ou AVIF. Pour un aperçu complet des techniques d'optimisation d'images, consultez notre guide sur l'optimisation des images.

En règle générale, vous devez servir une version WebP ou AVIF avec perte de votre image LCP (mieux encore, utilisez ces formats pour toutes vos images, mais nous nous concentrons ici sur le LCP). Avec un support de WebP d'environ 95 % et un support d'AVIF de 92 %, il est toujours judicieux de servir aussi d'anciennes images en fallback. Pour ce faire, utilisez l'« amélioration progressive » en ne servant ces formats modernes qu'aux navigateurs qui les supportent.

Compromis entre vitesse de décodage et compression

Bien qu'AVIF offre la meilleure compression (taille de fichier la plus petite), ses algorithmes complexes peuvent exiger plus de puissance CPU que WebP pour être décodés en une image affichable. Il s'agit d'une tâche liée au CPU qui s'exécute sur les threads du Rasterizer du navigateur. Cela augmente directement l'Element Render Delay. Un AVIF plus petit se téléchargera peut-être plus vite, mais son temps de décodage plus long peut annuler cet avantage, surtout sur mobile. Vous pouvez diagnostiquer cela dans le panneau Performance des Chrome DevTools. Cherchez les tâches « Decode Image » longues associées à votre élément LCP. Si vous en voyez, c'est le signe clair que la vitesse de décodage est votre goulot d'étranglement, et pas seulement le temps de téléchargement.

Avis d'expert : le cas de JPEG XL. Un véritable guide d'expert se doit d'aborder le JPEG XL. C'est un format techniquement remarquable. Il est particulièrement intéressant pour sa capacité à recompresser sans perte les JPEG existants (un atout majeur pour les sites legacy) et son support du décodage progressif, ce qui manque à AVIF. Son inconvénient décisif reste cependant le manque de support étendu par les navigateurs depuis son abandon par Chrome. Cela le rend pour l'instant non viable pour un usage web général. C'est néanmoins un format à suivre pour l'avenir.

Utiliser l'élément <picture> : L'élément <picture> permet aux navigateurs d'ignorer les formats d'image non supportés et de sélectionner le premier qu'ils peuvent gérer. Voici comment faire :

<picture>
<source srcset="img.avif" type="image/avif">
<source srcset="img.webp" type="image/webp">
<img src="img.jpg" alt="Image" width="123" height="123">
</picture>

Combiner la négociation de format avec des tailles responsives

Pour des performances maximales, combinez la sélection du format avec des tailles d'image responsives dans un seul élément <picture>. Cela garantit que chaque utilisateur obtient le format optimal et la taille optimale pour son appareil. Le navigateur évalue les éléments <source> de haut en bas et sélectionne le premier format qu'il supporte. Il utilise ensuite les attributs srcset et sizes pour choisir la bonne résolution.

<picture>
  <source
    type="image/avif"
    srcset="hero-400w.avif 400w, hero-800w.avif 800w, hero-1200w.avif 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <source
    type="image/webp"
    srcset="hero-400w.webp 400w, hero-800w.webp 800w, hero-1200w.webp 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <img
    src="hero-800w.jpg"
    srcset="hero-400w.jpg 400w, hero-800w.jpg 800w, hero-1200w.jpg 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px"
    alt="Descriptive alt text for hero image"
    width="1200" height="675"
    fetchpriority="high">
</picture>

Ce modèle donne au navigateur une liberté totale pour choisir la meilleure combinaison de format et de résolution. Un utilisateur mobile sur un navigateur compatible obtiendra un petit fichier AVIF, tandis qu'un ancien navigateur de bureau se rabattra sur un JPEG à la bonne taille.

Utiliser la négociation de contenu

La négociation de contenu permet à votre serveur de servir différents formats d'image selon le support du navigateur. Les navigateurs annoncent les formats supportés via l'en-tête Accept. Par exemple, dans Chrome, l'en-tête Accept pour les images ressemble à ceci :

Accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8

Ensuite, côté serveur, lisez l'en-tête Accept et servez le « meilleur format » en fonction de celui-ci.

3. Utilisez des images responsives

Quand il s'agit d'optimiser les images LCP, la taille compte vraiment. L'un des gains les plus simples consiste à servir des images avec les dimensions les plus petites possibles, tout en gardant un bon rendu sur les écrans de vos utilisateurs. Les grandes images ne servent à rien. Elles gaspillent de la bande passante et ralentissent les temps de chargement, particulièrement pour les utilisateurs avec des connexions lentes ou sur mobile.

Pour être sûr de ne pas gaspiller de pixels, suivez ces étapes :

Images responsives :

Utilisez l'attribut srcset pour servir différentes tailles d'image en fonction de l'appareil de l'utilisateur. Ainsi, les petits appareils reçoivent des images plus petites, ce qui aide à accélérer le LCP.

Pourquoi l'attribut sizes est critique

Utiliser srcset avec des descripteurs w en omettant l'attribut sizes est une erreur courante et coûteuse. Sans l'attribut sizes, le navigateur est forcé de supposer une valeur par défaut de 100vw (100 % de la largeur du viewport). Cela signifie que sur un grand écran de bureau, le navigateur téléchargera une image massive de votre liste srcset, même si l'image n'est affichée que dans une petite colonne de 500 px. Vous avez fourni les bons ingrédients (srcset) mais oublié la recette (sizes). Résultat : bande passante gaspillée et LCP plus lent. L'attribut sizes fournit le contexte de layout nécessaire. Il indique au navigateur la largeur réelle de l'image à différents points de rupture du viewport, lui permettant de faire un choix de téléchargement intelligent.

Comprendre les descripteurs w vs x

L'attribut srcset supporte deux types de descripteurs. Pour un design responsive où la taille d'une image change avec le viewport, le descripteur w (largeur) est le choix supérieur et nécessaire. Il s'utilise avec l'attribut sizes pour laisser le navigateur choisir la meilleure image selon sa taille de rendu dans le layout. Le descripteur x (device-pixel-ratio), plus simple, ne prend en compte que la densité de pixels de l'écran. Il ignore la taille réelle de l'image dans le layout. Cela le rend adapté uniquement aux images de taille fixe comme les icônes.

<img
  src="img.jpg"
  srcset="img-400px.jpg 400w, img-800px.jpg 800w, img-1200px.jpg 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
  alt="Image" width="123" height="123">

4. Mettez vos images à l'échelle de l'écran !

Évitez de servir des images plus grandes que nécessaire. Si l'élément LCP ne fait que 600 px de large dans le viewport, assurez-vous que l'image ne dépasse pas cette taille. Je vois cela tous les jours. Pour vérifier, inspectez l'image. Faites un clic droit dessus et sélectionnez « inspecter l'élément ». Vous verrez alors les DevTools et le code HTML de l'image surligné en bleu. Vous remarquerez que la taille de rendu de l'image (443 x 139 px) est bien inférieure à sa largeur intrinsèque (1090 x 343 px). C'est presque 3 fois plus grand. Redimensionner l'image aurait pu faire économiser au moins 50 % de la taille du fichier.

5. Utilisez le chargement Eager pour les images LCP

Pour tirer les meilleures performances de votre LCP, vous devez charger l'élément LCP visible en mode eager (et utiliser le lazy loading pour les images qui ne sont pas immédiatement visibles). C'est l'une des erreurs les plus fréquentes dans l'optimisation du LCP. Nous la couvrons en détail dans notre article sur la correction des images LCP en lazy loading.

Chargement Eager : L'élément LCP (généralement du contenu au-dessus de la ligne de flottaison) doit toujours être chargé en mode eager. Cela garantit son apparition le plus vite possible, réduisant le temps de rendu de votre Largest Contentful Paint. Par défaut, les images se chargent en mode eager sauf indication contraire. Vérifiez tout de même que vous n'avez pas mis loading="lazy" sur l'image LCP. Cela peut retarder considérablement le LCP et nuire à votre score Core Web Vitals. Comprenez bien que loading="eager" est le comportement par défaut du navigateur. Omettre totalement l'attribut a le même effet. L'action critique est de s'assurer que loading="lazy" n'est pas présent.

Alerte geek : Les images en lazy loading ne sont pas mises en file d'attente par le preload scanner. Ce dernier est un scanner HTML secondaire ultra rapide qui met immédiatement en file d'attente les ressources importantes. S'il est contourné, le navigateur devra attendre que le moteur de rendu ait terminé pour mettre en file d'attente les « images visibles ». Pour que le navigateur évalue le loading="lazy" natif, il doit d'abord télécharger et analyser tout le CSS render blocking afin de construire l'arbre de rendu. Le navigateur ne peut déterminer si l'image est dans le viewport qu'une fois le layout calculé. Cela signifie que tout votre CSS devient une dépendance bloquante pour le téléchargement de l'image LCP. C'est un désastre pour les performances.

<img src="lcp-image.jpg" alt="Main image" width="800" height="400">

Pour les images sous la ligne de flottaison (non visibles au chargement initial), le lazy loading est la solution. En retardant le chargement de ces images jusqu'à ce que l'utilisateur défile à proximité, vous libérez de la bande passante pour du contenu plus important, comme votre élément LCP. Le lazy loading est à double tranchant : bien utilisé, il accélère votre contenu LCP ; mal utilisé, il le ralentit !

<img src="non-visible-image.jpg"
     alt="Secondary image"
     
     width="800" height="400">

L'équilibre ? Chargez le contenu critique (comme votre image LCP) en mode eager. Utilisez le lazy loading pour les ressources moins importantes et les images sous la ligne de flottaison.

6. Préchargez l'image LCP

Précharger l'image LCP indique au navigateur de la récupérer immédiatement, avant sa découverte naturelle dans le HTML. Pour un guide complet sur le préchargement, consultez notre article dédié sur le préchargement de l'image LCP.

Pourquoi précharger l'image LCP ?

Quand le navigateur charge une page, il traite le HTML, les feuilles de style et les scripts dans un certain ordre. Parfois, l'image LCP est référencée plus bas dans la chaîne. Le navigateur l'atteint plus tard qu'il ne le devrait. Précharger l'image LCP indique d'emblée au navigateur que cette image est critique et doit être chargée immédiatement. Cela réduit le délai de rendu de votre plus grand élément.

Comment précharger l'image LCP

En utilisant la balise <link rel="preload">, vous vous assurez que le navigateur commence à récupérer l'image LCP le plus tôt possible lors du chargement.

<link rel="preload" href="lcp-image.jpg" as="image" type="image/jpeg">

Cela garantit que l'image LCP est dans la file d'attente du navigateur dès le départ. Vous évitez ainsi l'attente fréquente si l'image est enfouie dans le CSS ou les scripts.

<!-- In the <head> -->
<link rel="preload" as="image"
      href="lcp-image-800w.jpg"
      imagesrcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
      imagesizes="(max-width: 600px) 400px, 800px">

<!-- In the <body> -->
<img src="lcp-image-800w.jpg"
     srcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
     sizes="(max-width: 600px) 400px, 800px"
     alt="..." width="800" height="450" fetchpriority="high">

Rappelez-vous : Ne préchargez que l'image LCP. Précharger trop de ressources peut surcharger le navigateur et nuire aux performances. Concentrez-vous sur ce qui compte le plus pour vos Core Web Vitals.

7. Supprimez les animations d'apparition (Fade-In) de l'image LCP

Les animations d'apparition peuvent être visuellement attrayantes, mais elles constituent un goulot d'étranglement LCP caché. Si l'élément LCP (souvent une image) utilise un effet de fade-in, le navigateur ne comptabilisera le LCP qu'à la fin de l'animation. Cela retarde le LCP et peut nuire fortement à vos métriques de performance.

Le calcul du LCP s'effectue après la fin de l'animation : Le navigateur considère le LCP comme terminé uniquement lorsque l'élément est entièrement visible. Si vous avez une animation de fade-in, le chrono tourne jusqu'à ce que l'image ou le contenu soit complètement apparu. Cela peut facilement ajouter des secondes supplémentaires à votre score LCP.

Restez simple : Pour garantir l'apparition de l'élément LCP aussi vite que possible, évitez les effets de fade-in. Laissez l'image se charger et s'afficher immédiatement, sans aucune transition ni animation.

Oubliez les fade-ins sur l'image LCP. L'effet visuel ne vaut pas le coût en performance.

8. Auto-hébergez l'élément LCP

Auto-hébergez votre image LCP. Dépendre de serveurs tiers introduit des délais totalement hors de votre contrôle. Cela peut nuire à votre LCP et aux performances globales de la page.

Voyez les choses ainsi : Ne pas auto-héberger votre élément LCP revient à toujours emprunter du sucre à votre voisin. À chaque fois, vous devez vous déplacer, attendre à la porte et espérer qu'il soit là. Utiliser un serveur tiers pour votre LCP oblige votre site web à attendre cette ressource externe. Les temps de chargement ralentissent. L'auto-hébergement, c'est comme garder le sucre dans votre cuisine : rapide, direct et fiable.

Réduisez les dépendances externes : Quand votre élément LCP (comme une image) est hébergé sur un serveur tiers, vous êtes à la merci de la vitesse et de la disponibilité de ce serveur, ainsi que des éventuels allers-retours supplémentaires (RTT). L'auto-hébergement élimine cette incertitude. Il vous permet de servir l'image directement depuis votre propre serveur. Vous garantissez ainsi une livraison plus rapide et plus fiable.

Utilisez la mise en cache et les optimisations : En auto-hébergeant, vous tirez pleinement parti des stratégies de mise en cache. Vous servez l'image depuis le serveur le plus proche de l'utilisateur, surtout avec un CDN. Cela réduit le temps de chargement de l'élément LCP et permet un rendu plus rapide.

Contrôle de l'optimisation de l'image : L'auto-hébergement vous donne le contrôle sur l'optimisation de l'image. Compression, redimensionnement, sélection du format : vous ne dépendez plus d'un traitement tiers. Vous pouvez ainsi vous assurer que l'image est parfaitement adaptée pour un chargement rapide.

9. Évitez le rendu côté client pour l'élément LCP

Le rendu côté client (CSR) est l'une des pires choses que vous puissiez faire à votre LCP. Si votre élément LCP (souvent une grande image, un bloc de texte ou une vidéo) est rendu côté client via JavaScript, cela entraîne souvent des temps LCP plus lents. Le navigateur doit attendre de télécharger, d'analyser et d'exécuter les scripts avant d'afficher le contenu critique.

Délais de rendu : Avec le CSR, l'élément LCP n'est affiché qu'après le traitement du JavaScript par le navigateur, ce qui peut retarder considérablement son apparition. Plus c'est long, plus votre score LCP se dégrade. Chaque seconde supplémentaire passée à traiter des scripts se traduit par une attente plus longue pour vos utilisateurs avant de voir le contenu le plus important.

Passez au Server-Side Rendering (SSR) ou au Static Rendering : En rendant l'élément LCP côté serveur ou dans le cadre d'une réponse HTML statique, vous permettez au navigateur de le charger et de l'afficher immédiatement. Pas besoin d'attendre que JavaScript prenne le relais. Cela améliore considérablement le timing du LCP. Le navigateur peut rendre l'élément LCP tout de suite lorsqu'il commence à charger le HTML.

Minimisez le JavaScript sur le chemin critique : Si vous ne pouvez pas éviter certains scripts côté client, assurez-vous qu'ils ne bloquent pas le rendu de l'élément LCP. Utilisez defer ou async sur les scripts non critiques pour les empêcher de retarder l'apparition de votre LCP.

10. Réservez de l'espace pour éviter les Layout Shifts

Incluez toujours des attributs width et height explicites sur vos balises <img>. C'est une instruction critique pour le navigateur. Cela lui permet de calculer le ratio d'aspect de l'image et de réserver le bon espace dans le layout avant son téléchargement.

Avis d'expert : comportement moderne de width et height

Une idée fausse courante est que ces attributs rendent une image non responsive. Ce n'est plus vrai dans les navigateurs modernes. Le navigateur utilise ces attributs HTML pour calculer un ratio d'aspect et conserver l'espace, mais l'image sera toujours parfaitement responsive si son CSS est réglé sur width: 100%; height: auto;. Fournir ces attributs est supérieur à l'utilisation exclusive de la propriété CSS aspect-ratio. Le navigateur peut en effet réserver l'espace avant que le moindre CSS render blocking ne soit téléchargé et analysé. Cela lui donne une avance critique.

Gérer les images de fond CSS

Ce principe s'applique également aux éléments servant de conteneurs pour une background-image CSS. Une source fréquente de layout shift est une <div> qui s'effondre initialement à une hauteur de zéro, puis prend sa taille quand l'image de fond est appliquée. Pour éviter cela, utilisez directement la propriété CSS aspect-ratio sur l'élément conteneur pour réserver l'espace nécessaire dès le départ.

11. Auditez le blocage du main thread

Même si votre image LCP est parfaitement optimisée et priorisée, son rendu final peut être retardé si le main thread du navigateur est occupé à exécuter du JavaScript lourd. Souvent, la source de ce blocage vient de scripts tiers pour l'analytics, la publicité ou les widgets de support client. Ces scripts peuvent monopoliser le CPU, augmentant l'Element Render Delay. Utilisez le panneau Performance dans les Chrome DevTools pour identifier les long tasks pendant le chargement initial. Attribuez-les à leur source et différez ou supprimez tout ce qui n'est pas critique pour le rendu initial. Pour en savoir plus, consultez notre guide sur l'Element Render Delay.

Guide étape par étape : Diagnostiquer le LCP avec le panneau Performance des Chrome DevTools montre comment enregistrer une trace bridée et repérer ces long tasks dans la piste Main.

Guides d'optimisation LCP associés

L'optimisation des images n'est qu'une pièce du puzzle. Chaque phase du LCP a son propre guide :

• Corriger et identifier les problèmes LCP : La méthodologie de diagnostic complète pour trouver et corriger les problèmes LCP avec des field data et des outils de laboratoire.
• Resource Load Delay : Assurez-vous que le navigateur découvre votre ressource LCP le plus tôt possible avec preload, fetchpriority et une structure HTML optimale.
• Resource Load Duration : Réduisez le temps de téléchargement grâce à la compression, la configuration CDN et l'optimisation réseau.
• Element Render Delay : Libérez le main thread pour que le navigateur puisse peindre l'élément LCP immédiatement après le téléchargement.