Optimiser l'image Largest Contentful Paint

Optimiser l'image Largest Contentful Paint

Selon Google, seulement 65% de toutes les pages vues sur internet (ce qui inclut aussi bien le desktop que le mobile) ont un 'bon' score Largest Contentful Paint. Cela signifie que 35% des pages vues échouent et c'est en partie à cause d'erreurs commises avec les images. Cet article décompose les bonnes pratiques courantes et les erreurs lorsque les 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 !), il existe des étapes simples que vous pouvez suivre pour vous assurer qu'elle se charge aussi vite que possible !

Expériences avec le Largest Contentful Paint

Je dis toujours : écoutez et apprenez mais ne croyez personne sur parole. Il y a trop de 'gourous' qui prêchent de fausses informations. C'est pourquoi j'ai créé une expérience LCP entièrement automatique 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 Test LCP sur github ou essayez la démo live ! 

Il testera automatiquement plusieurs scénarios LCP pour vous et vous montrera les résultats. Je discuterai de ces scénarios ci-dessous et expliquerai comment et pourquoi cela accélérera ou ralentira l'élément image LCP.

1. Contrôler le candidat LCP : La stratégie Text-First

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 se résume au pipeline de requête. Un nœud de texte (comme un <h1> ou <p>) fait partie du document HTML principal. Il n'a pas de requête de ressource séparée ; son rendu est seulement bloqué par le CSS. Une image, en revanche, est une ressource externe qui nécessite sa propre requête HTTP. Cela introduit une latence réseau (DNS, TCP, TLS, et temps de téléchargement) en plus d'être bloqué par le CSS. Cette distinction est la raison principale de la différence de performance et pourquoi contrôler le candidat LCP est une stratégie puissante de niveau expert.

Alors, quel est l'argument pour les images par rapport au texte ? Les images sont importantes, elles rendent votre site visuellement attrayant. Mais les Core Web Vitals ne se soucient pas de quel élément devient le LCP. Lorsque l'élément LCP est un élément basé sur du texte, il coïncide généralement avec le First Contentful Paint.

Alors devriez-vous passer à un élément Largest Contentful Paint basé sur du texte ? Cela dépend ! Les images comptent et  elles rendent votre site visuellement attrayant. Cela signifie que vous ne m'entendrez pas plaider pour passer à de vieux éléments de texte ennuyeux. Mais des erreurs arrivent aussi ! Si j'avais un dollar pour chaque page de catégorie victime de l'anti-pattern **"LCP Accidentel"**. C'est là qu'une page "oublie" d'ajouter un texte de catégorie descriptif au-dessus de la ligne de flottaison, causant une image produit chargée en lazy-load de devenir le LCP et retardant les temps de chargement de plusieurs secondes. Cela arrive souvent lorsque les designers placent une grande bannière héro tout en haut du DOM, avant tout titre significatif, ne laissant au navigateur 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 houleux sur l'économie du dernier octet ou les réglages parfaits pour WebP vs AVIF, mettons-nous d'accord sur une chose : les formats plus anciens comme JPEG et PNG sont plus lourds et plus lents comparés aux formats modernes comme WebP ou AVIF. Si vous voulez approfondir, cet article détaille le tout.

En règle générale, vous devriez 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 sur le LCP ici). Avec le support WebP à environ 95% et le support AVIF à 92%, il est toujours sensé de servir des images de fallback plus anciennes également. Pour ce faire, utilisez simplement des 'améliorations progressives' où nous servons ces formats modernes uniquement aux navigateurs qui les supportent.

Vitesse de décodage vs compromis de compression

Bien que AVIF offre la meilleure compression (taille de fichier la plus petite), ses algorithmes complexes peuvent nécessiter plus de puissance CPU pour décoder en une image affichable comparé à WebP. C'est une tâche liée au CPU qui se produit sur les threads Rasterizer du navigateur et augmente directement le Délai de rendu de l'élément. Un fichier AVIF plus petit pourrait se télécharger plus vite, mais son temps de décodage plus long pourrait annuler cet avantage, surtout sur les appareils mobiles. Vous pouvez diagnostiquer cela dans le panneau Performance des Chrome DevTools en cherchant des tâches "Decode Image" de longue durée associées à votre élément LCP. Si vous voyez cela, c'est un signal clair que la vitesse de décodage est votre goulot d'étranglement, pas seulement le temps de téléchargement.

Avis d'expert : Le cas du JPEG-XL Un vrai guide expert doit aborder le JPEG XL. C'est un format techniquement remarquable, surtout pour sa capacité à recompresser sans perte des JPEG existants (une énorme victoire pour les sites existants) et son support du décodage progressif, ce qui manque à AVIF. Cependant, son inconvénient décisif est le manque de large support navigateur après avoir été abandonné par Chrome. Cela le rend non viable pour un usage web général pour l'instant, mais le positionne comme un format à surveiller pour l'avenir.

Utiliser l'élément <picture>: L'élément <picture> permet aux navigateurs d'ignorer les formats d'image non supportés, sélectionnant 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>

Utiliser la négociation de contenu : La négociation de contenu permet à votre serveur de servir différents formats d'image basés sur le support du navigateur. Les navigateurs annoncent les formats supportés via le header Accept. Par exemple, dans Chrome, le header Accept pour les images ressemble à ceci :

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

Ensuite, côté serveur, lisez le header accept et basé sur le header servez le 'meilleur format' 

3. Utilisez des images responsives

Quand il s'agit d'optimiser les images LCP, la taille compte vraiment. L'une des victoires les plus faciles est de servir des images avec les plus petites dimensions possibles qui paraissent toujours bien sur les écrans de vos utilisateurs. Les grandes images ne servent à rien du tout : elles gaspillent de la bande passante & ralentissent les temps de chargement, surtout pour les utilisateurs sur des connexions plus lentes ou des appareils mobiles.

Pour vous assurer que vous ne gaspillez pas de pixels, suivez ces étapes :

Images Responsives :

Utilisez l'attribut srcset pour servir différentes tailles d'image basées sur l'appareil de l'utilisateur. De cette façon, 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 mais omettre l'attribut sizes est une erreur courante et coûteuse. Sans l'attribut sizes, le navigateur est forcé d'assumer 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 500px. Vous avez fourni les bons ingrédients (srcset) mais oublié la recette (sizes), menant à une bande passante gaspillée et un LCP plus lent. L'attribut sizes fournit le contexte de mise en page crucial, disant au navigateur quelle sera 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 le 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 est utilisé avec l'attribut sizes pour laisser le navigateur choisir la meilleure image basée sur sa taille de rendu dans la mise en page. Le descripteur plus simple x (device-pixel-ratio) considère uniquement la densité de pixels de l'écran, ignorant la taille réelle de l'image dans la mise en page, le rendant approprié uniquement pour les 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">

Évitez de servir des images plus grandes que nécessaire. Si l'élément LCP fait seulement 600px de large dans le viewport, assurez-vous que l'image n'est pas plus grande que ça. Croyez-moi, je vois cela arriver tous les jours ! Pour vérifier faites juste ceci : inspectez l'image en faisant un clic droit sur l'image et sélectionnez 'inspecter'. Vous verrez maintenant les dev-tools et le html de l'image est surligné avec un fond bleu. Vous pouvez maintenant voir la taille de rendu de l'image (443 x 139px)  est beaucoup plus petite que la largeur intrinsèque de l'image  (1090x343px). C'est presque 3 fois plus grand et redimensionner l'image aurait pu économiser au moins 50% de la taille du fichier

5. Utilisez le chargement eager pour les images LCP

Pour obtenir la meilleure performance de votre LCP, vous devriez charger de manière eager (immédiate) l'élément LCP visible (et charger en lazy (différé) les images qui ne sont pas immédiatement visibles).

Chargement Eager : L'élément LCP (généralement le contenu au-dessus de la ligne de flottaison) devrait toujours être chargé de manière eager. Cela assure qu'il apparaît aussi vite que possible, réduisant le temps que cela prend pour votre Largest Contentful Paint de s'afficher. Par défaut, les images chargent de manière eager sauf indication contraire, mais vérifiez bien que vous n'avez pas mis loading="lazy" sur l'image LCP. Faire cela peut retarder significativement 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, donc omettre l'attribut entièrement a le même effet. L'action critique est de s'assurer que loading="lazy" n'est pas présent.

Alerte geek : les images lazy ne sont pas mises en file d'attente par le scanner de préchargement. Le scanner de préchargement est un scanner html secondaire super rapide qui met en file d'attente les ressources importantes immédiatement. Lorsque le scanner de préchargement est contourné le navigateur devra attendre que le moteur de rendu termine 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 parser tout le CSS bloquant le rendu pour construire l'arbre de rendu. Seulement après que la mise en page est calculée le navigateur peut déterminer si l'image est dans le viewport. Cela signifie que votre CSS entier devient une dépendance bloquante pour le téléchargement de l'image LCP, ce qui est un désastre de performance.

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

Pour les images qui apparaissent sous la ligne de flottaison (celles non visibles quand la page charge pour la première fois), le lazy loading est la voie à suivre. En retardant le chargement de ces images jusqu'à ce que l'utilisateur défile près d'elles, vous libérez de la bande passante pour du contenu plus important, comme votre élément LCP. De cette façon le lazy loading est une arme à double tranchant : Si utilisé correctement il accélérera votre contenu LCP, si utilisé incorrectement il le ralentira !

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

L'équilibre ? Chargez de manière eager le contenu critique (comme votre image LCP) et chargez en lazy les ressources moins critiques et les images sous la ligne de flottaison !

6. Précharger l'image LCP

Précharger l'image Largest Contentful Paint (LCP) est l'un des moyens les plus faciles d'accélérer son apparition sur la page. Cela dit au navigateur de prioriser le chargement de cette image, assurant qu'elle est prête aussi tôt que possible.

Pourquoi précharger l'image LCP ?

Lorsque 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, ce qui signifie que le navigateur y arrive plus tard qu'il ne le devrait. Précharger l'image LCP laisse le navigateur savoir dès le début que cette image est critique et devrait être chargée immédiatement, réduisant le délai dans le rendu de votre plus grand élément.

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 aussi tôt que possible dans le processus de chargement.

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

Cela assure que l'image LCP est dans la file d'attente du navigateur dès le départ, évitant l'attente qui se produit souvent si 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">

Rappelez-vous : Préchargez uniquement l'image LCP, car précharger trop de ressources peut submerger le navigateur et nuire à la performance. Tenez-vous en à ce qui compte le plus pour vos Core Web Vitals.

7. Supprimez les animations de fondu (fade-in) de l'image LCP

Les animations de fondu peuvent être visuellement attrayantes, mais quand il s'agit de votre Largest Contentful Paint, elles sont un goulot d'étranglement caché. Si l'élément LCP (souvent une image) utilise un effet de fondu, le navigateur ne comptera pas le LCP tant que l'animation n'est pas terminée. Cela retarde le timing LCP et peut significativement nuire à vos métriques de performance.

Le timing LCP se produit après la fin de l'animation : Le navigateur considère le LCP complet seulement quand l'élément est entièrement visible. Si vous avez une animation de fondu, le minuteur continue de tourner jusqu'à ce que l'image ou le contenu ait complètement fondu, ce qui peut facilement ajouter des secondes supplémentaires à votre score LCP.

Restez simple : Pour vous assurer que l'élément LCP apparaît aussi vite que possible, évitez d'utiliser des effets de fondu. Laissez l'image charger et s'afficher immédiatement, sans aucune transition ou animation.

En sautant les fondus sur l'image LCP, vous éviterez les délais inutiles et améliorerez vos Core Web Vitals, assurant une expérience plus rapide et fluide pour les utilisateurs.

8. Hébergez vous-même l'élément LCP

Pour obtenir la meilleure performance de votre Largest Contentful Paint, vous devriez toujours envisager d'héberger vous-même l'élément LCP, surtout si c'est une image ou une autre ressource critique. Dépendre de serveurs tiers peut introduire des délais qui sont complètement hors de votre contrôle, ce qui peut nuire à votre LCP et à la performance globale de la page.

Pensez-y comme ceci : Ne pas héberger soi-même son élément LCP c'est comme emprunter constamment du sucre à votre voisin. À chaque fois, vous devez marcher jusque là-bas, attendre à la porte, et espérer qu'ils sont à la maison. Dépendre d'un serveur tiers pour votre LCP fait attendre votre site web pour cette ressource externe, ralentissant les temps de chargement. L'auto-hébergement, c'est comme garder le sucre dans votre cuisine : "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 de ce serveur, de sa disponibilité, et de tout temps d'aller-retour supplémentaire (RTT). L'auto-hébergement élimine cette incertitude, vous permettant de servir l'image directement depuis votre propre serveur, assurant une livraison plus rapide et plus fiable.

Tirer parti de la mise en cache et des optimisations : En auto-hébergeant, vous pouvez tirer pleinement parti des stratégies de mise en 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 nécessaire pour charger l'élément LCP, résultant en un rendu plus rapide.

Contrôle sur l'optimisation de l'image : L'auto-hébergement vous donne le contrôle sur la façon dont l'image est optimisée, que ce soit la compression, le redimensionnement, ou la sélection de format—sans dépendre de la gestion tierce. De cette façon, vous pouvez vous assurer que l'image est parfaitement adaptée pour un chargement rapide.

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

Le rendu côté client (CSR) peut être un obstacle majeur quand il s'agit d'optimiser votre Largest Contentful Paint. 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 mène souvent à des temps LCP plus lents car le navigateur doit attendre que les scripts se téléchargent, se parsent, et s'exécutent avant d'afficher le contenu critique.

Délais dans le rendu : Avec le CSR, l'élément LCP est seulement affiché après que le navigateur ait traité le JavaScript, ce qui peut significativement retarder son apparition. Plus cela prend de temps, pire votre score LCP devient. 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 rendu côté serveur (SSR) ou au rendu statique : En rendant l'élément LCP côté serveur ou comme partie d'une réponse HTML statique, vous permettez au navigateur de charger et d'afficher celui-ci immédiatement, sans attendre que le JavaScript ne s'enclenche. Cela améliore drastiquement le timing LCP, car le navigateur peut rendre l'élément LCP tout de suite quand 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. Différez (defer) ou mettez en async 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, lui permettant de calculer le ratio d'aspect de l'image et de réserver la quantité correcte d'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 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 maintenir 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 de la seule propriété CSS aspect-ratio, car le navigateur peut réserver l'espace *avant* que tout CSS bloquant le rendu n'ait été téléchargé et parsé, lui donnant une longueur d'avance critique.

Gérer les images d'arrière-plan CSS

Ce principe s'applique aussi aux éléments qui servent de conteneurs pour une background-image CSS. Une source courante de layout shift est un <div> qui s'effondre à une hauteur de zéro initialement et ensuite saute à sa taille quand l'image d'arrière-plan est appliquée. Pour éviter cela, utilisez la propriété CSS aspect-ratio directement sur l'élément conteneur pour réserver l'espace nécessaire dès le début.

11. Auditer 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 thread principal du navigateur est occupé à exécuter du lourd JavaScript. Souvent, la source de ce blocage sont les scripts tiers pour l'analytique, les publicités, ou les widgets de support client. Ces scripts peuvent monopoliser le CPU, augmentant le Délai de rendu de l'élément. Utilisez le panneau Performance dans les Chrome DevTools pour identifier les tâches de longue durée pendant le chargement initial, attribuez-les à leur source, et différez ou supprimez tout ce qui n'est pas critique pour le rendu initial.