Le lazy loading diffère le téléchargement des images hors écran jusqu’à ce que l’utilisateur s’en approche en scrollant. La règle qui compte vraiment : ne jamais l’appliquer à l’image visible au chargement, en particulier l’image LCP, et toujours déclarer ses dimensions. L’attribut natif loading="lazy" suffit dans la grande majorité des cas.
En bref:
- Le lazy loading doit exclure l’image visible au chargement, notamment celle du LCP, qui doit aussi recevoir une priorité de chargement élevée.
- Déclarer systématiquement les dimensions ou l’aspect rationnel des images lazy-loadées pour éviter les décalages et optimiser le rendu.
- L’API Intersection Observer reste une méthode complémentaire efficace pour différer le chargement des images en background ou hors viewport.
- Appliquer le lazy loading à toutes les images d’un site sans exception peut réduire la performance en retardant le chargement de l’image LCP.
- Tester en laboratoire avec Chrome DevTools et en conditions réelles assure une implémentation efficace et évite les erreurs courantes.
Table des matières
- Pourquoi et quand activer le chargement différé d’images
- Comment implémenter le lazy loading avec l’attribut natif loading
- Quand le natif ne suffit pas : Intersection Observer et cas particuliers
- Comment le lazy loading affecte le LCP et le CLS
- Comment tester le lazy loading en laboratoire et en production
- Checklist avant mise en production
- Perspective AUDA : ce que l’expérience terrain enseigne
- Comment AUDA vous accompagne sur la performance de vos images
- Sources
Pourquoi et quand activer le chargement différé d’images
Sur une fiche produit avec de nombreuses photos, un carrousel d’avis ou une page catégorie e-commerce, charger toutes les images dès l’arrivée sur la page est un gaspillage pur. La technique lazy loading permet de ne télécharger que ce que l’internaute va réellement voir, ce qui réduit le poids initial de la page et raccourcit ce que les ingénieurs appellent le chemin critique de rendu, la séquence de calculs que le navigateur doit boucler avant d’afficher quoi que ce soit à l’écran (Web).
L’effet est particulièrement net sur mobile et sur les connexions 4G dégradées, là où chaque kilooctet économisé se traduit directement en secondes gagnées. Les contextes où l’optimisation change la donne :
- Galeries photo, portfolios et pages catégorie avec un grand nombre de vignettes
- Fiches produit e-commerce avec plusieurs photos et zoom
- Flux d’actualités ou blogs avec pagination longue et images d’illustration variées
- Pages de destination très longues (landing pages storytelling) qui contiennent de nombreuses images
À l’inverse, une page d’accueil courte avec deux ou trois visuels tous visibles au premier écran n’a presque rien à gagner à activer le lazy loading, et risque même d’y perdre si l’implémentation est mal calibrée.
Comment implémenter le lazy loading avec l’attribut natif loading
Trois valeurs sont disponibles pour l’attribut loading sur une balise <img> : lazy, eager et auto. lazy diffère le chargement jusqu’à l’approche du viewport, eager force un chargement immédiat, et auto laisse le navigateur décider seul, ce qui revient en pratique à un comportement proche de eager sur la plupart des moteurs. C’est aujourd’hui la méthode recommandée par MDN pour différer les images hors écran, et elle dispense la plupart des sites d’une librairie JavaScript dédiée (MDN).
Une balise bien construite ressemble à ceci :
<img
src="produit-vue-face.jpg"
srcset="produit-400.jpg 400w, produit-800.jpg 800w, produit-1200.jpg 1200w"
sizes="(max-width: 600px) 400px, 800px"
width="800"
height="600"
loading="lazy"
alt="Chaussure de running vue de face"
/>
Les points qui font la différence en production :
widthetheightréservent l’espace avant même que l’image ne soit chargée.srcsetetsizesservent des images de résolution adaptée à chaque appareil, un principe classique des images responsives qui reste indissociable d’une bonne optimisation des images.- Pour l’image visible au chargement, remplacez
loading="lazy"parloading="eager"ou, mieux, ajoutezfetchpriority="high"et unrel="preload"dans le<head>pour la faire arriver en priorité.
Conseil de pro : ne mettez jamais loading="lazy" par défaut sur toutes les images d’un template. C’est l’erreur la plus fréquente sur les sites qui utilisent un CMS et l’une des principales causes de régression du LCP.
Quand le natif ne suffit pas : Intersection Observer et cas particuliers
L’attribut loading couvre les balises <img> et <iframe>, mais pas les images posées en background-image CSS, ni certains posters vidéo ou widgets tiers. Pour ces cas, l’API Intersection Observer reste la méthode de référence : elle observe quand un élément entre dans une zone de marge définie (rootMargin) autour du viewport et déclenche le chargement à ce moment précis, avant même que l’utilisateur ne voie l’élément apparaître brutalement.
Quelques repères pratiques pour ces cas avancés :
- Un
rootMarginde 200 à 300 pixels anticipe suffisamment le scroll sans charger trop tôt. - Pour un
background-image, on bascule généralement une classe CSS ou l’attributstyleune fois l’observateur déclenché, plutôt que d’attendre un support natif qui n’existe pas. - Une librairie comme lazysizes reste pertinente en complément du natif, notamment pour contrôler finement les seuils ou couvrir les navigateurs plus anciens (web.dev).
Le chargement différé natif dépend en réalité de JavaScript pour fonctionner en pratique : sans script actif, certains navigateurs ne peuvent pas suivre le scroll pour déclencher le chargement au bon moment, une considération à garder en tête si votre site cible des environnements très restrictifs en matière de scripts ou de traqueurs.
Comment le lazy loading affecte le LCP et le CLS
Le piège numéro un du lazy loading n’est pas technique, c’est stratégique : appliquer l’attribut sans distinction retarde le téléchargement de l’image LCP elle-même, ce qui dégrade directement le score Largest Contentful Paint que Google utilise pour évaluer la rapidité perçue d’une page (web.dev). Des observations de terrain confirment que l’activation aveugle du lazy loading peut faire empirer le temps de chargement perçu plutôt que l’améliorer (Webhosting).
Trois actions concrètes à appliquer systématiquement :
- Identifiez l’image LCP avec les outils de diagnostic, puis excluez-la explicitement du lazy loading.
- Ajoutez
rel="preload"etfetchpriority="high"sur cette image pour qu’elle arrive en tête de file de téléchargement. - Déclarez
width/heightou une propriété CSSaspect-ratiosur chaque image, y compris les lazy-loadées, pour réserver leur espace et éviter les sauts de mise en page.
Une image lazy-loaded sans dimensions déclarées provoque un décalage visuel quand elle apparaît, ce qui fait grimper le Cumulative Layout Shift (MDN). Combiner ces deux réflexes, exclusion du LCP et dimensions systématiques, reste le compromis le plus fiable entre performance et confort d’affichage. Notre article sur les Core Web Vitals détaille comment ces indicateurs sont mesurés et pondérés par Google.
Comment tester le lazy loading en laboratoire et en production
Chrome DevTools reste l’outil de base : ouvrez l’onglet Performance, activez le filmstrip pour visualiser image par image le rendu, et repérez sur la waterfall network le moment exact où chaque image se déclenche. C’est souvent là qu’on découvre qu’une image censée être différée part en réalité dès le chargement initial.
- Lighthouse et PageSpeed Insights donnent une mesure en laboratoire, reproductible mais artificielle.
- Les données de terrain issues du Chrome UX Report (CrUX) montrent ce que vivent réellement vos visiteurs, avec leurs appareils et connexions variés.
- Chromium ajuste ses seuils de déclenchement selon la vitesse réseau détectée, ce qui signifie qu’un même site peut se comporter différemment selon le profil de connexion testé (web.dev).
- Testez systématiquement avec JavaScript désactivé pour vérifier qu’aucune image critique ne reste invisible.
Checklist avant mise en production
L’erreur la plus coûteuse reste l’application globale du lazy loading via un plugin ou un thème, sans exception pour les images visibles au chargement. Avant de déployer :
- Vérifiez qu’aucune image du premier écran ne porte
loading="lazy". - Confirmez que chaque balise
<img>a ses dimensions ou sonaspect-ratiodéclarés. - Testez l’ordre de priorité des requêtes CDN pour l’image LCP.
- Validez le rendu sur mobile, desktop, et avec JavaScript désactivé.
- Vérifiez spécifiquement les carrousels : seule la première slide devrait charger en mode
eager.
| Piège fréquent | Conséquence | Correction |
|---|---|---|
| Lazy appliqué à toutes les images sans exception | Dégradation du LCP | Exclure l’image visible au chargement |
| Dimensions absentes sur les images différées | Cumulative Layout Shift élevé | Déclarer width/height ou aspect-ratio |
| Carrousel entièrement lazy-loadé | Slide active invisible au chargement | Charger la première slide en eager |
Perspective AUDA : ce que l’expérience terrain enseigne
C’est cette approche croisée, image, technique et visibilité, qui distingue une intégration pensée pour optimiser la performance d’une simple case cochée dans un plugin.
— David
Comment AUDA vous accompagne sur la performance de vos images
Nous auditons les Core Web Vitals, identifions l’image LCP qui impacte le score, et corrigeons le CLS pour améliorer l’expérience utilisateur. L’approche recommande d’associer l’implémentation native (loading, fetchpriority, dimensions systématiques) et une solution JavaScript lorsque le contexte l’exige, par exemple pour carrousel, background CSS, ou support d’anciens navigateurs.
Pour une refonte complète intégrant ces optimisations dès la conception, découvrez notre offre de création de site internet sur mesure. Si votre catalogue produit souffre particulièrement de galeries lourdes, notre pôle e-commerce intègre ces réglages dès le lancement. Un contact rapide permet de cadrer un audit et d’obtenir un plan d’action chiffré.
Sources
Pour approfondir : les guides MDN sur le lazy loading et sur les performances multimédia, ainsi que les articles web.dev sur le LCP et la vitesse comme choix de design, et l’analyse de Babylovegrowth sur vitesse et conversions.
- Web
