Optimisez l'image du Largest Contentful Paint

Optimiser l'image du Largest Contentful Paint

Ce guide fait partie du hub Largest Contentful Paint (LCP). Sur la plupart des sites web, l'élément LCP est une image. Si vous vous trompez sur l'image, votre score LCP en pâtira. Cet article détaille toutes les techniques pour la rendre rapide.

Selon Google, seulement 65 % de toutes les pages vues sur Internet (sur ordinateur comme sur mobile) ont un « bon » score de Largest Contentful Paint. Cela signifie que 35 % des pages vues échouent, en partie à cause d'erreurs commises avec les images. Cet article analyse les bonnes pratiques et les erreurs courantes lorsque les images deviennent l'élément Largest Contentful Paint.

Bien que tous ces facteurs comptent, si votre élément LCP est une image (ce qui est souvent le cas !), des étapes simples permettent de s'assurer qu'elle se charge le plus rapidement 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 où vous pouvez vérifier par vous-même ce qui se passe lorsque l'élément LCP n'est pas chargé de manière optimale. Découvrez mon LCP Test sur GitHub ou essayez la démo en direct !

Elle testera automatiquement plusieurs scénarios de LCP et vous présentera les résultats. J'analyse ces scénarios ci-dessous et j'explique comment et pourquoi ils accélèrent ou ralentissent l'élément image LCP.

1. Contrôler le candidat LCP : la stratégie du texte en premier

Le moyen le plus rapide d'améliorer votre Largest Contentful Paint basé sur une image ? N'utilisez pas d'image ! Attendez, quoi ? Oui, vous m'avez bien entendu. Laissez-moi vous expliquer.

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

Alors, quel est l'intérêt des images par rapport au texte ? Les images sont importantes ; elles rendent votre site attrayant visuellement. Mais les Core Web Vitals se moquent de savoir quel élément devient le LCP. Lorsque l'élément LCP est un élément textuel, il coïncide généralement avec le First Contentful Paint.

Devez-vous pour autant passer à un élément Largest Contentful Paint basé sur du texte ? Cela dépend ! Les images comptent et rendent votre site attrayant. Je ne vais donc pas vous conseiller de revenir à de vieux éléments textuels ennuyeux. Mais les erreurs existent ! Si j'avais un euro pour chaque page de catégorie victime de l'anti-pattern de « LCP accidentel ». C'est le cas lorsqu'une page « oublie » d'ajouter un texte descriptif de catégorie au-dessus de la ligne de flottaison, ce qui fait qu'une image de produit en lazy loading devient le LCP et retarde le chargement de plusieurs secondes. Cela arrive souvent lorsque les designers placent une grande bannière hero tout en haut du DOM, avant les titres principaux, ne laissant d'autre choix au navigateur que de sélectionner un candidat LCP plus lent.

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

Sans entrer dans un débat animé sur l'économie du dernier octet ou les réglages parfaits de WebP contre AVIF, accordons-nous 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 concentrons-nous sur le LCP ici). Avec un support de WebP d'environ 95 % et un support d'AVIF de 92 %, il reste logique de proposer également des images de fallback plus anciennes. Pour cela, utilisez l'« amélioration progressive » en ne servant ces formats modernes qu'aux navigateurs qui les prennent en charge.

Vitesse de décodage vs compromis de compression

Bien que l'AVIF offre la meilleure compression (taille de fichier la plus petite), ses algorithmes complexes peuvent nécessiter plus de puissance CPU pour décoder l'image par rapport au WebP. C'est une tâche limitée par le CPU qui s'exécute sur les threads de rasterisation du navigateur et augmente directement l'Element Render Delay. Un fichier AVIF plus petit peut se télécharger plus rapidement, mais son temps de décodage plus long peut annuler ce bénéfice, en particulier sur les appareils mobiles. Vous pouvez diagnostiquer cela dans le panneau Performance de Chrome DevTools en recherchant 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 du JPEG-XL. Un véritable guide d'expert doit aborder le JPEG XL. C'est un format techniquement remarquable, notamment pour sa capacité à recompresser sans perte les JPEG existants (un gain énorme pour les sites patrimoniaux) et son support du décodage progressif, ce qui manque à l'AVIF. Cependant, son inconvénient majeur est l'absence d'un large support des navigateurs après avoir été abandonné par Chrome. Cela le rend pour l'instant non viable pour le web généraliste, mais en fait 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 pris en charge en sélectionnant le premier qu'ils savent 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 un maximum de performances, vous devez combiner la sélection du format et les tailles d'image responsives dans un seul élément <picture>. Cela garantit que chaque utilisateur obtient le format optimal et la taille idéale pour son appareil. Le navigateur évalue les éléments <source> de haut en bas, sélectionne le premier format pris en charge, puis utilise 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="Texte alternatif descriptif pour l'image hero"
    width="1200" height="675"
    fetchpriority="high">
</picture>

Ce pattern donne au navigateur toute liberté pour choisir la meilleure combinaison de format et de résolution. Un utilisateur sur mobile avec un navigateur compatible recevra un petit fichier AVIF, tandis qu'un navigateur de bureau plus ancien se rabattra sur un JPEG correctement dimensionné.

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 pris en charge 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 conséquence.

3. Utiliser des images responsives

Pour optimiser les images LCP, la taille compte énormément. L'une des victoires les plus faciles consiste à servir des images avec les dimensions les plus petites possibles qui restent nettes sur les écrans de vos utilisateurs. Les images trop grandes ne servent à rien : elles gaspillent de la bande passante et ralentissent les temps de chargement, en particulier pour les utilisateurs ayant des connexions lentes ou sur mobile.

Pour éviter de gaspiller des pixels, suivez ces étapes :

Images responsives :

Utilisez l'attribut srcset pour servir différentes tailles d'image selon 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 tout en omettant l'attribut sizes est une erreur courante et coûteuse. Sans l'attribut sizes, le navigateur est contraint de supposer une valeur par défaut de 100vw (100 % de la largeur du viewport). Cela signifie que sur un grand écran d'ordinateur, le navigateur téléchargera une image énorme à partir 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), ce qui entraîne un gaspillage de bande passante et un LCP plus lent. L'attribut sizes fournit le contexte de mise en page nécessaire en indiquant au navigateur la largeur réelle de l'image selon les différents points de rupture (breakpoints) du viewport, lui permettant ainsi de faire un choix de téléchargement intelligent.

Comprendre les descripteurs w vs. x

L'attribut srcset prend en charge deux types de descripteurs. Pour le design responsive où la taille d'une image change avec le viewport, le descripteur w (largeur) est le choix requis et supérieur. On l'utilise avec l'attribut sizes pour laisser le navigateur choisir la meilleure image en fonction de sa taille affichée dans la mise en page. Le descripteur plus simple x (densité de pixels) prend uniquement en compte la densité de pixels de l'écran, sans tenir compte de la taille réelle de l'image dans la mise en page, ce qui ne convient qu'aux images à 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. Redimensionner vos images à la taille 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. Croyez-moi, je vois cela tous les jours ! Pour vérifier, faites un clic droit sur l'image et sélectionnez « inspecter l'élément ». Dans les outils de développement (DevTools), le code HTML de l'image est surligné en bleu. Vous pouvez voir que la taille d'affichage de l'image (443 x 139 px) est bien inférieure à sa largeur intrinsèque (1090 x 343 px). C'est presque 3 fois trop grand. Redimensionner cette image aurait permis d'économiser au moins 50 % de la taille du fichier.

5. Utiliser le chargement hâtif pour l'image LCP

Pour obtenir les meilleures performances de votre LCP, vous devez charger de manière hâtive (eager) l'élément LCP visible (et utiliser le lazy loading pour les images qui ne sont pas immédiatement visibles). C'est l'une des erreurs les plus courantes en optimisation LCP, et nous la détaillons dans notre article sur comment corriger les images LCP chargées en lazy loading.

Le chargement hâtif (eager) : l'élément LCP (généralement le contenu au-dessus de la ligne de flottaison) doit toujours être chargé de manière hâtive. Cela garantit qu'il s'affiche le plus vite possible, réduisant le temps nécessaire au rendu de votre Largest Contentful Paint. Par défaut, les images se chargent de manière hâtive sauf mention contraire, mais vérifiez bien que vous n'avez pas défini loading="lazy" sur l'image LCP. Cela peut retarder considérablement le LCP et nuire à votre score Core Web Vitals. Il est important de comprendre que loading="eager" est le comportement par défaut du navigateur ; omettre l'attribut a donc le même effet. L'action essentielle 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. Le preload scanner est un scanner HTML secondaire ultra-rapide qui met immédiatement en file d'attente les ressources importantes. Lorsque le preload scanner est contourné, le navigateur doit attendre que le moteur de rendu ait terminé avant de 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 (render tree). Ce n'est qu'après le calcul de la mise en page (layout) que le navigateur peut déterminer si l'image se trouve dans le viewport. Cela signifie que l'intégralité de votre CSS devient une dépendance bloquante pour le téléchargement de l'image LCP, ce qui est une catastrophe pour les performances.

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

Pour les images situées sous la ligne de flottaison (celles non visibles lors du chargement initial de la page), le lazy loading est la solution idéale. En différant le chargement de ces images jusqu'à ce que l'utilisateur s'en approche en faisant défiler la page, vous libérez de la bande passante pour le contenu plus important, comme votre élément LCP. En ce sens, le lazy loading est une arme à double tranchant : utilisé correctement, il accélère votre contenu LCP ; utilisé incorrectement, il le ralentit !

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

Le bon équilibre ? Chargez de manière hâtive le contenu critique (comme votre image LCP) et utilisez le lazy loading pour les ressources moins critiques et les images sous la ligne de flottaison !

6. Précharger l'image LCP

Précharger l'image LCP indique au navigateur de la récupérer immédiatement, avant de la découvrir naturellement 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 ?

Lors du chargement d'une page, le navigateur traite le HTML, les feuilles de style et les scripts dans un ordre précis. Parfois, l'image LCP est référencée plus tard dans la chaîne, ce qui signifie que le navigateur la découvre plus tard qu'il ne le devrait. Précharger l'image LCP permet d'indiquer d'emblée au navigateur que cette image est critique et doit être chargée immédiatement, réduisant ainsi le délai de rendu de votre élément le plus grand.

Comment précharger l'image LCP

En utilisant la balise <link rel="preload">, vous pouvez vous assurer que le navigateur commence à récupérer l'image LCP le plus tôt possible dans le processus de 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, évitant l'attente qui se produit souvent lorsque l'image est enfouie dans le CSS ou les scripts.

<!-- Dans le <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">

<!-- Dans le <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">

Rappel : préchargez uniquement 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. Supprimer les animations de fondu (fade-in) sur l'image LCP

Les animations de fondu (fade-in) peuvent être esthétiques, mais elles constituent un goulot d'étranglement invisible pour le LCP. Si l'élément LCP (souvent une image) utilise un effet de fondu, le navigateur ne comptabilisera pas le LCP avant la fin de l'animation. Cela retarde la mesure du LCP et peut nuire considérablement à vos métriques de performance.

La mesure du LCP intervient après la fin de l'animation : le navigateur ne considère le LCP comme terminé que lorsque l'élément est entièrement visible. Si vous utilisez une animation de fondu, le chronomètre continue de tourner jusqu'à ce que l'image ou le contenu soit complètement visible, ce qui peut facilement ajouter des secondes à votre score LCP.

Faites simple : pour vous assurer que l'élément LCP s'affiche le plus rapidement possible, évitez les effets de fondu. Laissez l'image se charger et s'afficher immédiatement, sans transition ni animation.

Évitez les fondus sur l'image LCP. L'effet visuel ne vaut pas le coût en termes de performances.

8. Auto-héberger 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, ce qui 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 à emprunter constamment du sucre à votre voisin. À chaque fois, vous devez vous déplacer, attendre à la porte et espérer qu'il soit là. Dépendre d'un serveur tiers pour votre LCP oblige votre site à attendre cette ressource externe, ce qui ralentit les temps de chargement. L'auto-hébergement, c'est comme avoir le sucre dans votre cuisine : c'est rapide, direct et fiable.

Réduire les dépendances externes : lorsque 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 temps d'aller-retour (RTT) supplémentaires. L'auto-hébergement élimine cette incertitude en vous permettant de servir l'image directement depuis votre propre serveur, garantissant une livraison plus rapide et plus fiable.

Utiliser la mise en cache et les optimisations : en auto-hébergeant, vous pouvez tirer pleinement parti des stratégies de cache et servir l'image depuis le serveur le plus proche de l'utilisateur, surtout si vous utilisez un CDN. Cela réduit le temps de chargement de l'élément LCP, accélérant ainsi son rendu.

Contrôle sur l'optimisation des images : l'auto-hébergement vous donne le contrôle sur la façon dont l'image est optimisée (qu'il s'agisse de compression, de redimensionnement ou du choix du format) sans dépendre d'un traitement tiers. Vous vous assurez ainsi que l'image est parfaitement adaptée pour un chargement rapide.

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

Le rendu côté client (CSR) est l'une des pires choses pour votre LCP. Si votre élément LCP (généralement une grande image, un bloc de texte ou une vidéo) est rendu côté client via JavaScript, cela ralentit souvent le LCP car le navigateur doit attendre que les scripts soient téléchargés, analysés et exécutés avant d'afficher le contenu critique.

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

Passer au rendu côté serveur (SSR) ou au rendu statique : en rendant l'élément LCP côté serveur ou dans une réponse HTML statique, vous permettez au navigateur de le charger et de l'afficher immédiatement, sans attendre l'exécution du JavaScript. Cela améliore considérablement le temps de LCP, car le navigateur peut afficher l'élément LCP dès le début du chargement du HTML.

Minimiser 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 les attributs defer ou async sur les scripts non critiques pour éviter qu'ils ne retardent l'apparition de votre LCP.

10. Réserver l'espace pour éviter les décalages de mise en page (layout shifts)

Ajoutez toujours des attributs width et height explicites sur vos balises <img>. C'est une instruction essentielle pour le navigateur, qui lui permet de calculer le ratio d'aspect (aspect ratio) de l'image et de réserver le bon espace dans la mise en page avant que l'image ne soit téléchargée.

Avis d'expert : comportement moderne de width et height

Une idée reçue courante est que ces attributs rendent une image non responsive. Ce n'est plus vrai avec les navigateurs modernes. Le navigateur utilise ces attributs HTML pour calculer un ratio d'aspect et réserver l'espace, mais l'image restera parfaitement responsive si son CSS est configuré avec width: 100%; height: auto;. Fournir ces attributs est préférable à l'utilisation de la seule propriété CSS aspect-ratio, car le navigateur peut réserver l'espace avant que tout CSS render blocking ne soit téléchargé et analysé, ce qui lui donne une avance précieuse.

Gérer les images de fond en CSS

Ce principe s'applique également aux éléments servant de conteneurs pour une background-image CSS. Une source courante de décalage de mise en page est un <div> qui s'effondre initialement à une hauteur de zéro, puis s'agrandit brusquement lorsque l'image de fond est appliquée. Pour éviter cela, utilisez la propriété CSS aspect-ratio directement sur l'élément conteneur afin de réserver l'espace nécessaire dès le départ.

11. Auditer les blocages du thread principal (main thread)

Même si votre image LCP est parfaitement optimisée et prioritaire, 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 réside dans les scripts tiers d'analytics, de publicité ou de widgets de support client. Ces scripts peuvent monopoliser le CPU, augmentant l'Element Render Delay. Utilisez le panneau Performance de Chrome DevTools pour identifier les long tasks (tâches longues) lors du chargement initial, attribuez-les à leur source, puis 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.

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 :

• Identifier et corriger les problèmes de LCP : la méthodologie de diagnostic complète pour identifier et corriger les problèmes de LCP à l'aide de field data et de lab data.
• Resource Load Delay : assurez-vous que le navigateur découvre votre ressource LCP le plus tôt possible grâce au préchargement, à fetchpriority et à une structure HTML optimale.
• Resource Load Duration : réduisez le temps de téléchargement grâce à la compression, la configuration du CDN et l'optimisation réseau.
• Element Render Delay : libérez le main thread pour que le navigateur puisse afficher (paint) l'élément LCP immédiatement après le téléchargement.