Lazy loading : définition, mise en place et limites
Définition
En bref
Le lazy loading, ou chargement différé, retarde le téléchargement des images, vidéos et iframes situées hors de l'écran jusqu'à ce que le visiteur s'en approche. Il s'active nativement avec l'attribut loading="lazy" et réduit nettement le poids du chargement initial d'une page.
Par défaut, un navigateur télécharge toutes les images référencées dans la page, y compris celles que personne ne verra jamais. Le chargement différé corrige ce gaspillage et fait gagner du temps de chargement sur les pages longues. Mal appliqué, il produit l'effet inverse et dégrade le LCP : la règle d'or est de ne jamais différer l'image principale. Cette seule exception suffit à distinguer un réglage utile d'un réglage qui pénalise vos pages.
Deux méthodes de mise en oeuvre
La méthode native est la plus simple : ajoutez loading="lazy" sur vos balises img et iframe. Tous les navigateurs modernes la prennent en charge, sans bibliothèque ni script supplémentaire. Le navigateur décide lui-même du moment de déclenchement, en fonction de la position de l'élément et de la vitesse de défilement. Pour la majorité des sites, cette seule ligne suffit et se déploie en quelques heures.
La méthode JavaScript repose sur l'API IntersectionObserver, qui détecte l'entrée d'un élément dans la zone visible et déclenche alors son chargement. Elle est plus souple : elle permet de différer n'importe quel type de contenu, d'afficher une image floue en attendant, ou d'ajuster la marge de déclenchement. Elle demande en revanche du code à maintenir et un test attentif sur connexion lente.
- Images sous la ligne de flottaison : loading="lazy" avec width et height déclarés.
- Image principale du haut de page : loading="eager" et fetchpriority="high".
- Iframes de vidéos et de cartes : lazy systématique, avec un conteneur à dimensions fixes.
- Gain typique sur le chargement initial d'une page longue : 30 à 60 % de poids en moins.
Quand il ne faut surtout pas différer
L'erreur la plus fréquente consiste à appliquer le chargement différé à toutes les images d'un coup, extension activée sans réglage. L'image de bannière, qui est presque toujours l'élément LCP, se charge alors avec un retard de plusieurs centaines de millisecondes et fait basculer la page hors des seuils Google. Le remède est simple : exclure explicitement le premier visuel de chaque gabarit et lui donner la priorité de chargement.
Deuxième précaution : toujours déclarer les dimensions ou un rapport d'aspect. Une image différée sans espace réservé provoque un décalage de mise en page au moment où elle apparaît, ce qui dégrade le CLS. Testez enfin le rendu en connexion 3G simulée : si des zones restent blanches pendant le défilement, la marge de déclenchement est trop courte. Ce contrôle prend cinq minutes et évite la plupart des mauvaises surprises en production.
Ce que nous vérifions chez DGL Agency
Notre contrôle porte sur trois points. Le premier visuel de chaque gabarit est-il exclu du chargement différé ? Les dimensions sont-elles déclarées partout, y compris dans les blocs éditoriaux ? Les scripts tiers lourds (cartes, vidéos, widgets d'avis) sont-ils eux aussi différés, car ils pèsent souvent plus que les images ? Ces trois vérifications règlent la plupart des situations rencontrées sur WordPress.
Le chargement différé n'est qu'un levier parmi d'autres. Il se combine avec la conversion des visuels en WebP ou AVIF, le dimensionnement aux tailles réellement affichées et la mise en cache. Pris isolément, il améliore rarement un site vraiment lent : c'est l'addition des correctifs qui fait passer une page sous la barre des deux secondes. Commencez donc par le poids des visuels, puis affinez le réglage du chargement différé.
Une page produit allégée de 2,4 Mo
Une page produit affiche 28 visuels, dont 4 seulement sont visibles à l'ouverture. Sans chargement différé, le navigateur télécharge 3,1 Mo d'images au premier rendu. Avec loading="lazy" sur les 24 visuels situés plus bas et fetchpriority="high" sur la photo principale, le poids initial tombe à 0,7 Mo. Le LCP mesuré sur mobile passe de 4,1 s à 2,3 s, et la page repasse dans le vert des Core Web Vitals en trois semaines.
Pour aller plus loin
L'outil gratuit associé
Lancez une analyse gratuite pour savoir quelles images gagneraient à être différées, lesquelles doivent au contraire rester prioritaires, et le temps récupérable. Le relevé distingue le mobile et l'ordinateur, gabarit par gabarit.