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

Qu'est-ce que 'différer les images hors écran' ?

L'avertissement différer les images hors écran était un audit Lighthouse qui signalait les pages avec des images pouvant bénéficier d'un lazy loading. Lighthouse signalait les images qui répondaient à tous ces critères :

• L'image se termine en dessous de 3 fois la hauteur de la fenêtre (viewport).
  Lorsqu'une image n'est pas en lazy loading 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 fait plus de 0,02 Mo ou prend plus de 50 ms à charger.
  Les images qui sont soit petites soit intégrées (inlined) sont ignorées. Les scripts de lazy loading utilisent souvent de petites images de remplacement qui se situent en dessous de ce seuil.
• L'image n'a pas d'attribut loading défini.
  Lighthouse ignore les images qui ont l'attribut loading="lazy" ou loading="eager".

Cet audit a été supprimé dans Lighthouse 13

Depuis 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, de sorte que l'audit générait plus de bruit que de retours utiles.

Mais voici le problème : l'optimisation en elle-même reste importante. Le 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 pour trouver les 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 permet d'économiser de la bande passante et permet au navigateur de se concentrer sur les ressources qui comptent vraiment pour le rendu initial.

Quelles sont les causes des images hors écran chargées de manière anticipée (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 parce que l'attribut loading est manquant ou que l'image n'est pas gérée par une bibliothèque de lazy loading. Les causes courantes :

• Plugins mal codés dans votre CMS.
• Plugins qui désactivent le lazy loading natif.
• Images d'arrière-plan (elles nécessitent une approche différente de loading="lazy").
• Constructeurs de pages (page builders) qui génèrent un mauvais HTML (par exemple : Elementor ou WP Bakery).
• Texte copié et collé dans un éditeur WYSIWYG (comme TinyMCE).
• Mauvais codage de modèle (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 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 en mode 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 entrent en compétition pour la bande passante avec les ressources qui sont réellement nécessaires pour le rendu, comme votre CSS et votre image LCP.
• Utilisation plus élevée de la mémoire. Le décodage d'images vers lesquelles l'utilisateur n'a pas encore fait défiler la page 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 percentile, ce nombre grimpe à 52. Sur les pages riches en images, le lazy loading de celles hors écran peut faire une réelle différence. Sur les sites surveillés par CoreDash, 76 % des pages qui appliquent correctement le lazy loading aux images hors écran réussissent le test LCP, contre 59 % pour les pages qui ne le font pas.

Comment corriger 'différer les images hors écran'

Pour corriger les images hors écran chargées en mode eager, ajoutez loading="lazy" à chaque image qui se trouve sous la ligne de flottaison. Le lazy loading natif est désormais 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 en lazy loading natif"
     width="300" height="300">

Retracez les origines de vos images chargées en mode eager. 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. Plugins mal codés dans votre CMS.
   Certains plugins ajoutent du HTML directement à la page et n'utilisent pas les bons hooks qui permettent le lazy loading.
2. 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. Constructeurs de pages qui génèrent un mauvais HTML.
   Les constructeurs de pages (page builders) comme Elementor ou WP Bakery créent souvent un code gonflé qui est loin d'être parfait. Il n'y a pas de solution de facilité pour cela. La solution implique de nettoyer votre code et de modifier votre flux de travail (workflow).
4. Texte copié et collé dans un éditeur WYSIWYG.
   La plupart des éditeurs WYSIWYG comme TinyMCE font un mauvais travail de nettoyage du code collé, en particulier lorsqu'il est collé à partir d'une autre source de texte riche comme Microsoft Word. Ces éditeurs peuvent ne pas ajouter le lazy loading à vos images.
5. Mauvais codage de modèle.
   Même lorsque le lazy loading est activé, les images codées en dur dans vos modèles (templates) peuvent ne pas être en lazy loading. Vérifiez vos modèles pour trouver les images hors écran et appliquez-leur le lazy loading.

N'appliquez pas de lazy loading à votre image LCP

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

Au lieu de cela, faites le contraire 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="Image hero"
     width="1200" height="600">

Si vous avez accidentellement appliqué un lazy loading à votre image LCP, lisez comment corriger une image LCP chargée en lazy loading. Pour un guide complet sur l'optimisation des images, consultez optimiser les images pour les Core Web Vitals.

Aide-mémoire sur le chargement des 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 natif est supporté par tous les navigateurs majeurs, y compris Safari (depuis la version 15.4), couvrant 95 % des utilisateurs dans le monde. Il ne nécessite aucun JavaScript, n'ajoute aucune surcharge et fonctionne immédiatement.

Les bibliothèques comme lazysizes étaient essentielles avant que les navigateurs ne supportent 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 d'arrière-plan CSS. Le lazy loading natif ne fonctionne que sur les éléments <img> et <iframe>. Pour les images d'arrière-plan, vous avez besoin d'IntersectionObserver ou de content-visibility: auto.
• Seuils de chargement personnalisés. Chrome commence à charger les images "lazy" à environ 1250px sous la fenêtre (viewport) sur les connexions rapides et 2500px 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 supporte les images d'arrière-plan.

Prévenir le décalage de mise en page (layout shift) sur les images en lazy loading

Incluez toujours les attributs width et height sur les images en lazy loading. Sans dimensions explicites, le navigateur ne sait pas combien d'espace réserver. Lorsque l'image se charge enfin, elle repousse 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 décalage de mise en page -->
<img loading="lazy" src="photo.webp" alt="Photo">

<!-- Bon : les dimensions réservent 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 pourriez ne pas avoir accès au modèle (template) ou votre CMS pourrait ne pas supporter le lazy loading. Il existe quelques solutions de contournement pour atténuer l'impact. Elles sont loin d'être parfaites et pourraient introduire de nouveaux défis.

• Compressez vos images. Les petites images ont moins d'impact sur les performances de chargement que les grandes images. Utilisez des techniques de compression modernes pour réduire la taille des fichiers.
• Utilisez des formats d'image plus rapides. Passez du PNG et JPEG au WebP ou AVIF. Le WebP compresse à environ 1,3 bits par pixel comparé à 2,0 pour le JPEG selon le chapitre Média 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 une seule fois.
• 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 considérablement accélérer le chargement initial.

Pour les considérations spécifiques aux mobiles, les images hors écran sont un problème encore plus important car les connexions mobiles sont plus lentes et les fenêtres (viewports) mobiles sont plus petites, 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 les Core Web Vitals globaux sur le terrain.