Corriger 'Defer Offscreen Images' : Guide de lazy loading pour les Core Web Vitals

Qu'est-ce que 'defer offscreen images' ?

L'avertissement defer offscreen images était un audit de Lighthouse qui signalait les pages avec des images pouvant être chargées paresseusement (lazy loaded). Lighthouse signalait les images qui répondaient à tous ces critères :

• L'image se termine en dessous de 3 fois la hauteur du viewport.
  Lorsqu'une image n'est pas chargée paresseusement et se termine en dessous de 3 fois la hauteur de la partie visible de la page, et commence en dessous de la partie visible de la page.
• L'image est plus grande que 0,02 Mo ou met plus de 50 ms à se charger.
  Les images qui sont soit petites soit inlined sont ignorées. Les scripts de lazy loading utilisent souvent de petites images de remplacement (placeholder) qui tombent en dessous de ce seuil.
• L'image n'a pas d'attribut de chargement (loading) défini.
  Lighthouse ignore les images qui ont soit l'attribut loading="lazy" soit loading="eager".

Cet audit a été supprimé dans Lighthouse 13

À partir de Lighthouse 13 (octobre 2025), cet audit a été entièrement supprimé. L'équipe Chrome a déterminé que les navigateurs modernes dépriorisent déjà les images hors écran, donc l'audit générait plus de bruit que de commentaires utiles.

Mais voici la chose : l'optimisation elle-même compte toujours. Le chargement paresseux (lazy loading) des images hors écran réduit la bande passante, libère des connexions réseau pour les ressources critiques et améliore votre Largest Contentful Paint (LCP). Le fait que Lighthouse ne le signale plus signifie que vous devez le vérifier vous-même. Utilisez le Real User Monitoring ou auditez manuellement vos pages à la recherche d'images qui se chargent sans loading="lazy".

Un petit rappel : qu'est-ce que le lazy loading ?

Le lazy loading signifie que les images qui ne sont pas dans la partie visible de la page sont chargées ultérieurement, généralement juste avant qu'elles ne défilent dans la vue. Le navigateur ne récupère l'image que lorsque l'utilisateur s'en approche. Cela économise de la bande passante et permet au navigateur de se concentrer sur les ressources qui comptent vraiment pour le rendu initial.

Qu'est-ce qui cause les images hors écran chargées de manière hâtive (eager) ?

Les images ne sont pas différées par défaut. Les images hors écran qui ne sont pas différées se retrouvent sur la page car l'attribut loading est manquant ou l'image n'est pas gérée par une bibliothèque de lazy loading. Causes courantes :

• Des plugins mal codés dans votre CMS.
• Des plugins qui désactivent le lazy loading nativo.
• Les images de fond (Background images) (celles-ci nécessitent une approche différente de loading="lazy").
• Des constructeurs de pages (Page builders) qui génèrent du mauvais HTML (par exemple : Elementor ou WP Bakery).
• Du texte copié et collé dans un éditeur WYSIWYG (comme TinyMCE).
• Un mauvais codage de template.

Comment les images hors écran affectent-elles vos Core Web Vitals ?

Les images hors écran n'ont pas d'impact direct sur les métriques de Lighthouse. Mais elles rendent le rendu d'une page Web inutilement compliqué. Votre navigateur devra télécharger plus de ressources avant que la page puisse être affichée à l'écran. Il y a 3 problèmes avec les images hors écran chargées de manière eager :

• Plus de téléchargements avant le rendu. Votre navigateur devra télécharger des images que l'utilisateur ne peut même pas encore voir.
• Les ressources critiques sont dépriorisées. Les images concurrencent la bande passante avec les ressources qui sont réellement nécessaires au rendu, comme votre CSS et votre image LCP.
• Utilisation plus élevée de la mémoire. Le décodage des images jusqu'auxquelles l'utilisateur n'a pas encore fait défiler gaspille de la mémoire, en particulier sur les appareils mobiles bas de gamme.

Selon le chapitre Page Weight du Web Almanac 2025, la page mobile médiane charge 15 images. Au 90ème centile, ce nombre grimpe à 52. Sur les pages riches en images, le chargement paresseux de celles hors écran peut faire une réelle différence. Sur les sites surveillés par CoreDash, [CD:placeholder] % des pages qui chargent correctement de manière paresseuse les images hors écran réussissent le LCP, contre [CD:placeholder] % des pages qui ne le font pas.

Comment corriger 'defer offscreen images'

Pour corriger les images hors écran chargées de manière eager, ajoutez loading="lazy" à chaque image qui se trouve sous la ligne de flottaison (below the fold). Le lazy loading natif est maintenant supporté par 95 % des navigateurs dans le monde, y compris Chrome, Firefox, Safari et Edge. Vous n'avez pas besoin d'une bibliothèque pour cela.

<img loading="lazy"
     src="image.webp"
     alt="une image native chargée paresseusement"
     width="300" height="300">

Retracez les origines de vos images chargées de manière hâtive. Vérifiez quelles images se chargent sans attribut loading et déterminez ce qui les place sur la page. Il y a 5 suspects habituels :

1. Des plugins mal codés dans votre CMS.
   Certains plugins ajoutent du HTML directement à la page et n'utilisent pas les bons hooks qui activent le lazy loading.
2. Des plugins qui désactivent le lazy loading natif.
   Certains plugins désactivent le lazy loading natif par défaut. Vérifiez les paramètres de votre plugin.
3. Des constructeurs de pages qui génèrent du mauvais HTML.
   Les constructeurs de pages comme Elementor ou WP Bakery créent souvent un code gonflé qui est loin d'être parfait. Il n'y a pas de solution facile pour cela. La solution comprend le nettoyage de votre code et la modification de votre flux de travail.
4. Du texte copié et collé dans un éditeur WYSIWYG.
   La plupart des éditeurs WYSIWYG comme TinyMCE font un mauvais travail de nettoyage du code collé, surtout s'il est collé depuis une autre source de texte riche comme Microsoft Word. Ces éditeurs peuvent ne pas ajouter le lazy loading à vos images.
5. Un mauvais codage de template.
   Même lorsque le lazy loading est activé, les images codées en dur (hardcoded) dans vos templates peuvent toujours ne pas être chargées de manière paresseuse. Vérifiez vos templates pour les images hors écran et chargez-les paresseusement.

Ne chargez pas paresseusement votre image LCP

C'est la règle la plus importante du lazy loading : n'appliquez jamais loading="lazy" à votre image de Largest Contentful Paint. L'image LCP est presque toujours l'image hero ou le plus grand élément visible dans le viewport. Selon le Web Almanac 2025, 16 % des pages mobiles chargent encore paresseusement leur image LCP. Ce seul attribut peut ajouter 200 à 500 millisecondes à votre LCP.

Faites plutôt l'inverse pour votre image LCP. Assurez-vous qu'elle se charge le plus rapidement possible avec fetchpriority="high" :

<img fetchpriority="high"
     loading="eager"
     src="hero.webp"
     alt="Hero image"
     width="1200" height="600">

Si vous avez accidentellement chargé paresseusement votre image LCP, lisez comment réparer une image LCP chargée paresseusement. Pour un guide complet sur l'optimisation des images, voir optimiser les images pour les Core Web Vitals.

Aide-mémoire (cheatsheet) de chargement d'images

Toutes les images ne doivent pas être traitées de la même manière. Voici comment gérer les 4 scénarios les plus courants :

Lazy loading natif vs scripts de lazy loading

Utilisez le loading="lazy" natif. En 2026, il n'y a aucune raison d'ajouter une bibliothèque JavaScript de lazy loading pour les éléments <img> standards. Le lazy loading nativo est pris en charge par tous les principaux navigateurs, y compris Safari (depuis la version 15.4), couvrant 95 % des utilisateurs dans le monde. Il ne nécessite aucun JavaScript, n'ajoute aucun overhead et fonctionne prêt à l'emploi (out of the box).

Les bibliothèques comme lazysizes étaient essentielles avant que les navigateurs ne prennent en charge le lazy loading natif. Elles ne sont plus maintenues et ne sont plus nécessaires pour la plupart des sites. Les seuls scénarios où vous pourriez encore avoir besoin d'une solution JavaScript :

• Images de fond CSS. Le lazy loading natif ne fonctionne que sur les éléments <img> et <iframe>. Pour les images de fond, vous avez besoin d'IntersectionObserver ou content-visibility: auto.
• Seuils de chargement personnalisés. Chrome commence à charger les images "paresseuses" à environ 1250 px sous le viewport sur les connexions rapides et à 2500 px sur les connexions lentes. Vous ne pouvez pas personnaliser cette distance. Si vous avez besoin d'un contrôle plus strict, un IntersectionObserver avec une rootMargin personnalisée vous l'offre.

Si vous avez vraiment besoin d'une bibliothèque, utilisez vanilla-lazyload au lieu de lazysizes. Elle est activement maintenue, utilise IntersectionObserver et prend en charge les images de fond.

Empêcher le layout shift sur les images chargées paresseusement

Incluez toujours les attributs width et height sur les images chargées paresseusement. Sans dimensions explicites, le navigateur ne sait pas combien d'espace réserver. Lorsque l'image se charge enfin, elle pousse le contenu environnant vers le bas, provoquant un Cumulative Layout Shift (CLS). Selon le Web Almanac 2025, 62 % des pages mobiles ont encore au moins une image sans dimensions.

<!-- Mauvais : cause un layout shift -->
<img loading="lazy" src="photo.webp" alt="Photo">

<!-- Bon : les dimensions réservent de l'espace -->
<img loading="lazy" src="photo.webp" alt="Photo" width="800" height="600">

Solutions de contournement lorsque vous ne pouvez pas utiliser le lazy loading

Parfois, il n'est pas possible de différer les images hors écran. Vous n'avez peut-être pas accès au template ou votre CMS peut ne pas prendre en charge le lazy loading. Il existe quelques solutions de contournement pour atténuer l'impact. Celles-ci sont loin d'être parfaites et pourraient introduire de nouveaux défis.

• Compressez vos images. Les images plus petites ont moins d'impact sur les performances de chargement que les grandes images. Utilisez des techniques de compression modernes pour réduire la taille du fichier.
• Utilisez des formats d'image plus rapides. Passez du PNG et JPEG au WebP ou AVIF. Le WebP compresse à environ 1,3 bit par pixel contre 2,0 pour le JPEG selon le chapitre Media du Web Almanac 2024.
• Divisez les grandes pages en plusieurs pages. Diviser les grandes pages réduit le nombre d'images qui doivent se charger en même temps.
• Implémentez le défilement infini (infinite scroll). Le défilement infini est fondamentalement du lazy loading, non pas pour les images mais pour des parties entières de la page web. Pour les pages avec de nombreux éléments répétés (pensez à Pinterest), le défilement infini peut accélérer considérablement le chargement initial.

Pour les considérations spécifiques au mobile, les images hors écran sont un problème encore plus important car les connexions mobiles sont plus lentes et les viewports mobiles sont plus petits, ce qui signifie que plus d'images se retrouvent hors écran.

Quelle que soit l'approche que vous adoptez, vérifiez qu'elle fonctionne avec de vrais utilisateurs. Configurez un Real User Monitoring pour suivre si vos modifications améliorent réellement le LCP et l'ensemble des Core Web Vitals sur le terrain (in the field).