Lazy loading : quand il accélère le site et quand il le pénalise

Un site e-commerce affiche 47 images sur sa page catégorie. Sans lazy loading, le navigateur tente de toutes les charger d’un coup : 8,3 Mo transférés avant même que le visiteur ne commence à scroller. Avec l’attribut loading="lazy", seules les images visibles se chargent immédiatement, et le reste suit à la demande. Résultat : un First Contentful Paint divisé par deux. Pourtant, sur la page d’accueil du même site, ce même attribut appliqué sans discernement retarde l’affichage du hero banner et fait chuter le score Largest Contentful Paint. Le lazy loading n’est pas un interrupteur magique : il faut savoir où le placer et où l’éviter.

Le principe du lazy loading en quelques lignes

Le lazy loading, ou chargement différé, consiste à retarder le téléchargement d’une ressource jusqu’à ce qu’elle soit sur le point d’entrer dans la zone visible du navigateur (le viewport). Au lieu de télécharger toutes les images dès l’ouverture de la page, le navigateur ne récupère que celles qui sont immédiatement visibles, puis charge les suivantes au fur et à mesure que l’utilisateur défile.

Le mécanisme repose sur l’API Intersection Observer. Le navigateur surveille la position de chaque élément marqué comme lazy. Quand un élément s’approche du viewport (généralement à quelques centaines de pixels de distance), le téléchargement se déclenche. Cette marge de sécurité évite que l’image apparaisse vide au moment précis où elle entre dans le champ de vision.

Historiquement, ce comportement nécessitait des bibliothèques JavaScript comme lazysizes ou lozad.js. Depuis 2019, l’attribut HTML natif loading="lazy" permet d’obtenir le même résultat sans une seule ligne de JavaScript. C’est aujourd’hui la méthode recommandée par le guide technique de web.dev sur le lazy loading natif.

Le concept s’applique aux images (<img>), aux iframes (<iframe>) et, via JavaScript, à peu près n’importe quel élément lourd : vidéos, cartes interactives, widgets tiers. Dans cet article, je me concentre sur les images, car c’est là que le lazy loading images intérêt se mesure le plus directement en performance.

Quand le lazy loading accélère réellement le site

Le lazy loading donne ses meilleurs résultats dans des cas bien précis. Si votre page ne contient que deux ou trois images, le gain sera négligeable. En revanche, dans les scénarios suivants, l’impact est mesurable :

Pages longues avec beaucoup d’images sous la ligne de flottaison

Les articles de blog illustrés, les portfolios photo, les fiches produit avec galeries : toutes ces pages affichent des dizaines d’images dont la majorité se trouve en dessous du premier écran. Sur un article contenant 20 images, seules 2 ou 3 sont visibles à l’arrivée. Le lazy loading évite de télécharger les 17 autres immédiatement, ce qui réduit le volume de données initial de manière significative. Sur des connexions mobiles 3G/4G, cette différence se traduit par plusieurs secondes de chargement en moins.

Pages catégories et résultats de recherche

Une page de catalogue e-commerce affichant 30 à 60 produits avec vignettes représente un cas d’école. J’ai mesuré sur un projet client un passage de 6,2 secondes à 2,8 secondes de temps de chargement initial simplement en activant le lazy loading sur les vignettes situées en dessous de la troisième ligne de produits. Le serveur consommait aussi moins de bande passante, un avantage non négligeable sur un hébergement mutualisé.

Pages avec iframes et contenus embarqués

Les vidéos YouTube intégrées, les cartes Google Maps ou les widgets de réseaux sociaux sont souvent plus lourds que les images. Un seul embed YouTube charge environ 500 Ko de ressources. Si votre page en contient trois, le lazy loading sur ces iframes évite 1,5 Mo de transfert inutile au chargement initial.

Sites consultés majoritairement sur mobile

Sur mobile, l’écran est plus petit, donc moins d’images sont visibles simultanément. Le ratio entre images visibles et images hors écran est plus favorable au lazy loading. De plus, la bande passante mobile reste souvent inférieure à celle du Wi-Fi. Le lazy loading images intérêt est donc maximal sur les audiences mobiles, qui représentent aujourd’hui plus de 60 % du trafic web en France selon les données de StatCounter sur la répartition mobile/desktop en France.

Quand le lazy loading pénalise les performances

C’est le point que la plupart des guides oublient de traiter en profondeur. Le lazy loading peut dégrader l’expérience utilisateur et les Core Web Vitals s’il est appliqué sans réflexion.

Le piège du Largest Contentful Paint (LCP)

Le LCP mesure le temps nécessaire pour afficher le plus grand élément visible dans le viewport initial. Dans la majorité des cas, cet élément est une image : le hero banner, la photo produit principale, la miniature d’un article. Si vous appliquez loading="lazy" à cette image, le navigateur retarde volontairement son téléchargement au lieu de le prioriser. Résultat : le LCP augmente, parfois de 5 à 15 %, et votre score PageSpeed chute.

La règle est simple : toute image visible sans scroller ne doit jamais être en lazy loading. Cela concerne le logo, le hero banner, la première image d’un article, la photo principale d’une fiche produit. Ces images doivent rester en loading="eager" (le comportement par défaut) ou, mieux encore, recevoir l’attribut fetchpriority="high" pour signaler au navigateur qu’elles sont prioritaires. Pour aller plus loin sur le diagnostic, consultez mon guide sur comment diagnostiquer un site lent.

Le problème du Cumulative Layout Shift (CLS)

Quand une image en lazy loading se charge, elle passe d’une hauteur nulle à sa hauteur réelle. Si les attributs width et height ne sont pas déclarés dans le HTML, le navigateur ne peut pas réserver l’espace à l’avance. Le contenu en dessous se décale brutalement : c’est le layout shift. Ce décalage dégrade le score CLS, l’un des trois Core Web Vitals.

La solution est systématique : toujours déclarer les dimensions de l’image dans le HTML, soit via les attributs width et height, soit via un aspect-ratio en CSS. Le navigateur réserve alors l’espace avant même de télécharger l’image.

Pages courtes : un gain inexistant

Sur une page qui ne contient que deux images, toutes deux visibles dans le viewport, le lazy loading n’a aucune image à différer. Il ajoute simplement une couche de logique inutile. Pire, si l’une de ces images est l’élément LCP, il la retarde. Sur les pages courtes, mieux vaut laisser le comportement par défaut.

Comparatif lazy vs eager : quel attribut pour quel usage

L’attribut loading accepte deux valeurs : lazy et eager. Voici un tableau récapitulatif pour trancher rapidement :

Une erreur que je vois régulièrement : appliquer loading="lazy" à toutes les images du site via un script global. C’est exactement ce qu’il ne faut pas faire. La démarche correcte consiste à identifier les images above the fold, les exclure du lazy loading, puis appliquer le chargement différé au reste.

Implémentation native en HTML : la méthode recommandée

L’implémentation native du lazy loading est d’une simplicité remarquable. Aucune bibliothèque, aucun plugin, aucun fichier JavaScript supplémentaire :

<!-- Image sous la ligne de flottaison : lazy -->
<img src="photo-produit.webp"
     alt="Description du produit"
     width="800"
     height="600"
     loading="lazy">

<!-- Image hero : eager avec priorité haute -->
<img src="hero-banner.webp"
     alt="Bannière principale"
     width="1200"
     height="675"
     loading="eager"
     fetchpriority="high">

Quelques points techniques à respecter :

• Toujours déclarer width et height : cela permet au navigateur de calculer le ratio et réserver l’espace, évitant ainsi les sauts de mise en page
• Utiliser des formats modernes : le lazy loading fonctionne avec tous les formats, mais couplé au WebP ou à l’AVIF, le gain de poids est encore plus important
• Ne pas combiner avec un polyfill JS : les navigateurs modernes gèrent nativement l’attribut. Ajouter lazysizes par-dessus crée une double logique inutile
• Tester avec l’onglet Network de Chrome DevTools : filtrez par images, scrollez lentement et vérifiez que les images se chargent bien au bon moment

Pour les images de fond en CSS, l’attribut loading ne s’applique pas. Il faut alors utiliser l’Intersection Observer en JavaScript ou, plus simplement, convertir ces fonds en balises <img> avec du CSS object-fit pour profiter du lazy loading natif.

La balise picture et le lazy loading

Avec la balise <picture>, l’attribut loading se place sur le <img> de fallback, pas sur les <source> :

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg"
       alt="Description"
       width="800"
       height="600"
       loading="lazy">
</picture>

Lazy loading et WordPress : ce que le CMS fait automatiquement

Depuis WordPress 5.5 (août 2020), le CMS ajoute automatiquement loading="lazy" à toutes les images insérées via l’éditeur. Depuis WordPress 5.9, le comportement a été affiné : la première image de contenu reçoit loading="eager" pour protéger le LCP. Cependant, cette logique n’est pas toujours fiable.

Les cas où WordPress se trompe

• Le hero banner du thème : s’il est codé dans le template PHP et non inséré via l’éditeur de contenu, WordPress ne le détecte pas comme première image. Il reste en lazy par défaut du thème
• Les images ajoutées par des builders : Elementor, Divi ou WPBakery ajoutent parfois leur propre lazy loading en plus de celui de WordPress, créant des conflits
• Les vignettes WooCommerce : la première image produit peut être traitée comme lazy alors qu’elle est l’élément LCP de la fiche

Corriger manuellement dans WordPress

Pour forcer le comportement eager sur une image critique, ajoutez ce filtre dans votre fichier functions.php :

// Retirer le lazy loading sur l'image mise en avant
add_filter('wp_img_tag_add_loading_attr', function($value, $image, $context) {
    if ($context === 'the_content') {
        // Conserver lazy pour les images du contenu
        return $value;
    }
    // Eager pour le reste (header, featured image)
    return 'eager';
}, 10, 3);

Si vous utilisez un plugin de cache, vérifiez qu’il ne réécrit pas les attributs loading que vous avez définis. Certains plugins comme WP Rocket ou LiteSpeed Cache proposent leur propre gestion du lazy loading qui peut écraser la configuration native.

Mon conseil après avoir travaillé sur des dizaines de sites WordPress : désactivez le lazy loading des plugins tiers et reposez-vous sur le comportement natif du navigateur. C’est plus léger, plus fiable et plus facile à déboguer. Pour optimiser davantage, pensez aussi à mettre à jour votre version de PHP, ce qui impacte directement le temps de génération des pages.

Lazy loading et SEO : ce que Google en dit vraiment

La question revient systématiquement : le lazy loading empêche-t-il Google d’indexer les images ? La réponse courte est non, à condition d’utiliser la méthode native. Voici pourquoi.

Googlebot utilise un moteur de rendu basé sur Chrome à jour. Il exécute le JavaScript, il comprend l’Intersection Observer, et il supporte l’attribut loading="lazy". Les images en lazy loading natif sont donc correctement découvertes et indexées par Google, comme le confirme la documentation officielle de Google sur le rendu JavaScript.

En revanche, certaines implémentations JavaScript personnalisées peuvent poser problème :

• Les scripts qui utilisent un placeholder dans src et déplacent l’URL réelle dans un attribut data-src : si le script ne s’exécute pas correctement côté Googlebot, l’image reste invisible
• Les bibliothèques qui nécessitent un scroll pour déclencher le chargement : Googlebot ne simule pas toujours le défilement complet de la page
• Les implémentations sans noscript : même si c’est de moins en moins pertinent, un fallback <noscript> reste une bonne pratique

Pour le référencement naturel, le lazy loading natif est donc sans risque. Il améliore même indirectement le SEO en améliorant les Core Web Vitals (à condition de ne pas dégrader le LCP, comme expliqué plus haut).

Impact sur Google Images

Les images en lazy loading apparaissent normalement dans Google Images si elles remplissent ces conditions : un attribut src valide (pas un placeholder transparent), un attribut alt descriptif, et des dimensions déclarées. Le sitemap images reste recommandé pour les sites où les visuels constituent un levier de trafic important.

Les erreurs fréquentes qui ruinent le bénéfice

En auditant des sites clients, je retrouve régulièrement les mêmes erreurs. Voici les plus courantes :

1. Lazy loading sur toutes les images sans exception

C’est l’erreur numéro un. Un plugin ou un script applique loading="lazy" à 100 % des images, y compris le logo, le hero et la première image du contenu. Le LCP s’effondre. La correction est simple : exclure les 2 à 4 premières images visibles.

2. Absence de dimensions déclarées

Sans width et height, chaque image qui se charge provoque un saut de layout. Sur une page avec 15 images en lazy, cela crée 15 micro-décalages qui s’accumulent dans le score CLS. C’est particulièrement visible sur mobile.

3. Double lazy loading

WordPress ajoute loading="lazy" nativement. Le thème ajoute lazysizes.js. Le plugin de cache ajoute sa propre surcouche. Résultat : trois mécanismes concurrents qui se marchent dessus, avec parfois des images qui ne se chargent jamais parce que chaque script attend que l’autre déclenche le chargement.

4. Images critiques avec src placeholder

Certaines bibliothèques JS remplacent le src par un pixel transparent et stockent l’URL réelle dans data-src. Si le JavaScript échoue (erreur réseau, bloqueur de pub), l’image reste un pixel vide. L’attribut natif loading="lazy" n’a pas ce problème car l’URL reste dans src.

5. Lazy loading sur les images CSS background

L’attribut loading ne fonctionne pas sur les images de fond CSS. Certains développeurs l’ajoutent sur un <div> en pensant que cela aura un effet : ce n’est pas le cas. Pour les fonds CSS, il faut passer par l’Intersection Observer ou repenser le markup.

6. Seuil de déclenchement trop court

Si le navigateur déclenche le chargement trop tard (quand l’image est déjà dans le viewport), l’utilisateur voit un espace vide le temps du téléchargement. Les navigateurs modernes gèrent cela avec une marge automatique d’environ 1 250 pixels sur connexion rapide et davantage sur connexion lente. Les anciennes bibliothèques JS avec un seuil fixe de 100 px n’offrent pas cette adaptation.

Checklist pour auditer le lazy loading de votre site

Avant de modifier quoi que ce soit, un audit rapide permet d’identifier les problèmes. Voici la démarche que je suis systématiquement :

1. Ouvrir Chrome DevTools (F12), onglet Network, filtrer par “Img”
2. Recharger la page en cache vide (Ctrl+Maj+R) et observer combien d’images se chargent avant tout scroll
3. Identifier l’élément LCP via l’onglet Performance ou Lighthouse : est-ce une image ? A-t-elle loading="lazy" ? Si oui, c’est un problème
4. Scroller lentement et vérifier que les images se chargent avant d’apparaître (pas de flash blanc)
5. Vérifier le CLS dans Lighthouse : si des images provoquent des sauts, vérifier que width et height sont déclarés
6. Compter les mécanismes de lazy loading : inspecter le HTML pour repérer si loading="lazy", data-src et un script JS coexistent
7. Tester sur mobile : utiliser la simulation mobile de DevTools pour vérifier que le seuil de déclenchement est correct sur petit écran

Pour un diagnostic plus complet, mon guide sur les causes d’un site lent couvre d’autres pistes au-delà du lazy loading. Et si vos images sont trop lourdes avant même d’être chargées, la compression en WebP ou AVIF est le complément indispensable.

Pour les sites servis via un CDN, vérifiez que le lazy loading n’entre pas en conflit avec les mécanismes de cache et de transformation d’images du CDN. Certains CDN comme Cloudflare proposent leur propre système de lazy loading côté serveur.