Définition du lazy loading
Le lazy loading est une technique de performance web qui retarde le chargement des ressources non critiques. En clair : la page n’essaie pas de tout télécharger dès l’ouverture. Elle garde pour plus tard ce qui se trouve plus bas, hors de l’écran, ou ce qui n’est pas encore utile. Elle complète l’optimisation des images pour le web et la minification CSS et JavaScript quand la page contient trop de ressources.
On parle aussi de chargement différé. Le cas le plus fréquent reste l’image placée sous la ligne de flottaison, mais le principe vaut aussi pour les iframes, certaines vidéos, des widgets tiers ou des morceaux de JavaScript. L’idée est simple, presque brutale : pourquoi envoyer 3 Mo d’images si l’utilisateur ne descend jamais jusque-là ?
À l’inverse, l’eager loading charge une ressource tout de suite. C’est utile pour le logo, l’image principale, les polices nécessaires à l’affichage ou le contenu visible dès l’arrivée sur la page. Lazy pour le reste, eager pour ce qui donne le premier écran. Bon, dans la vraie vie, c’est rarement aussi propre, mais c’est la règle de départ.
À quoi sert le lazy loading ?
Le lazy loading sert d’abord à afficher plus vite la partie utile d’une page. Le navigateur peut traiter moins de requêtes au démarrage, décoder moins d’images, exécuter moins de scripts et laisser l’utilisateur interagir plus tôt. Sur mobile, où la connexion et le processeur peuvent être limités, l’écart se voit vite.
- moins de poids chargé au premier affichage ;
- moins de bande passante consommée pour les contenus jamais vus ;
- une page plus confortable sur mobile ;
- un meilleur contrôle des ressources tierces, souvent trop bavardes ;
- une base plus saine pour une démarche de sobriété numérique.
Je préfère le dire franchement : le lazy loading ne répare pas une page obèse. Si une fiche produit contient quinze scripts marketing, un slider géant et des images non compressées, ajouter loading="lazy" ne transforme pas le site en modèle d’écoconception web. C’est un levier utile, pas une excuse pour empiler les ressources.
Comment fonctionne le chargement différé ?
Le navigateur raisonne autour du viewport, c’est-à-dire la zone visible de l’écran. Les ressources visibles au-dessus de la ligne de flottaison doivent arriver vite. Les autres peuvent attendre que l’utilisateur fasse défiler la page, ou qu’il s’approche de la zone où elles seront affichées.
Le déclenchement peut être natif, avec un attribut HTML, ou géré par JavaScript. Dans les deux cas, le piège est le même : attendre trop longtemps. Si l’image apparaît avec une seconde de retard au moment du scroll, l’utilisateur voit un trou, puis un saut. Le résultat ? Mauvais.
Lazy loading natif avec loading= »lazy »
Pour les images et les iframes, la méthode sobre est souvent l’attribut natif :
<img src="image.webp" alt="Description utile de l’image" loading="lazy">C’est lisible, supporté par les navigateurs modernes et sans librairie à ajouter. C’est exactement le type de solution que GreenCodeLab privilégie quand elle suffit : moins de code, moins de maintenance, moins de risques.
IntersectionObserver et scripts JavaScript
JavaScript se justifie quand le besoin dépasse l’attribut natif : animation progressive, composants dynamiques, images de fond CSS, règles fines selon le contexte, compatibilité particulière. L’API IntersectionObserver permet de détecter qu’un élément approche de la zone visible, puis de lancer son chargement.
Mais ajouter une librairie de lazy load pour deux images en bas de page, franchement, c’est souvent absurde. Vous gagnez quelques requêtes d’images et vous ajoutez un script. Mauvais arbitrage.
Quelles ressources charger en lazy loading ?
La bonne question n’est pas « peut-on le faire ? ». C’est « est-ce que cette ressource aide le premier affichage ? ». Si la réponse est non, le lazy loading mérite d’être testé.
| Ressource | Lazy loading conseillé ? | Pourquoi | Point de vigilance |
|---|---|---|---|
| Image hero ou visuel principal | Non, sauf cas très rare | Elle pèse souvent dans le Largest Contentful Paint | La charger en lazy peut ralentir le premier écran |
| Images sous la ligne de flottaison | Oui | Elles ne servent pas au démarrage | Réserver largeur et hauteur pour éviter les sauts |
| Iframe vidéo | Oui | Une iframe vidéo charge souvent beaucoup de code tiers | Prévoir une vignette légère si possible |
| Carrousel secondaire | Oui, ou à supprimer | Les slides invisibles sont rarement utiles au départ | Un carrousel lourd reste lourd, même différé |
| Widget tiers | Souvent oui | Chat, carte, avis ou tracking peuvent attendre | Vérifier l’impact sur mesure analytics et consentement |
| Script critique | Non | Il peut bloquer une fonction visible ou nécessaire | Différer seulement les modules non critiques |
Cette grille évite un réflexe que je vois trop souvent : tout passer en lazy parce que l’outil le propose. Non. Le premier écran doit rester prioritaire. Le reste doit être justifié.
Les erreurs à éviter
Première erreur : appliquer le lazy loading à l’image LCP. Si l’élément le plus grand du premier écran attend d’être « découvert », le navigateur perd du temps, puis Google le mesure. C’est exactement l’inverse de l’objectif.
Deuxième erreur : oublier les dimensions des images. Sans largeur et hauteur réservées, la page bouge quand l’image arrive. Le Cumulative Layout Shift grimpe, l’utilisateur clique parfois au mauvais endroit, et tout le monde s’énerve.
- Ne différez pas les contenus visibles dès l’ouverture.
- Gardez des attributs
altutiles sur les images, lazy ou non. - Vérifiez que le contenu important est présent dans le HTML rendu.
- Évitez les plugins qui ajoutent plus de code qu’ils n’en retirent.
- Testez le tracking après déploiement, surtout si des widgets se chargent plus tard.
Petite parenthèse : les plugins « performance » qui activent dix options en même temps sont pratiques pour cocher une case. Ils sont aussi très bons pour créer des bugs discrets. Une image produit qui ne charge pas sur mobile, un formulaire invisible, une vidéo bloquée par consentement. Bref, revenons à nos moutons : activez peu, mesurez vite.
Lazy loading, SEO et Core Web Vitals
Le lazy loading peut aider le SEO technique, mais il ne donne pas un bonus magique. Il agit indirectement, par la performance, l’expérience utilisateur et la qualité du rendu. Pour Google, une page rapide, stable et lisible reste plus saine qu’une page lourde qui tente de cacher son poids.
Attention au LCP
Sur les Core Web Vitals, deux points comptent surtout. Le Largest Contentful Paint (LCP) mesure le temps nécessaire pour afficher l’élément principal. Le CLS mesure la stabilité visuelle. Un lazy loading mal réglé peut abîmer les deux.
Côté crawl et indexation, le contenu important doit rester accessible. Les moteurs savent exécuter du JavaScript, mais ce n’est pas une raison pour cacher une information centrale derrière un chargement fragile. Pour une page lexique, une fiche produit ou un contenu éditorial, le texte clé doit être disponible sans scénario exotique.
Lazy loading et écoconception web
Le lien avec le numérique responsable est concret : une ressource non téléchargée consomme moins de bande passante, moins de calcul côté navigateur et parfois moins d’appels serveur. À l’échelle d’une page, le gain paraît modeste. À l’échelle d’un site avec beaucoup de trafic, il devient intéressant.
Mais la sobriété numérique demande de rester cohérent. Différer une vidéo YouTube intégrée, oui. Ajouter un script de 40 Ko pour différer une image déjà compressée, non. Remplacer vingt images inutiles par vingt images lazy-loadées, non plus. La meilleure ressource reste celle qu’on ne charge pas, et parfois celle qu’on ne met pas dans la page.
Dans un audit GreenCodeLab, le lazy loading se regarde avec le poids de page, le nombre de requêtes, le score Lighthouse, l’EcoIndex et le parcours réel. Une page sobre n’est pas seulement une page qui charge plus tard. C’est une page qui charge moins, mieux, et seulement quand l’usage le demande.
Comment vérifier qu’un lazy loading est bien configuré ?
Avant mise en production, je ferais ces contrôles. Pas dans trois semaines, pas après une chute de trafic. Avant.
Checklist de validation
Ajoutez un test manuel au clavier si le contenu différé est interactif. Un widget, un accordéon, une iframe ou un module produit ne doit pas devenir inaccessible parce qu’il arrive trop tard ou seulement au scroll souris. C’est un détail jusqu’au jour où il bloque un utilisateur.
Questions fréquentes
Le lazy loading améliore-t-il le SEO ?
Il peut améliorer la performance perçue et réduire le poids initial, ce qui aide le SEO technique si la configuration est propre. Il peut aussi dégrader le LCP, l’indexation ou la stabilité visuelle s’il est appliqué aux mauvais éléments.
Faut-il installer un plugin WordPress pour faire du lazy loading ?
Pas forcément. WordPress et les navigateurs modernes gèrent déjà beaucoup de cas avec le lazy loading natif. Un plugin se justifie si vous avez des besoins avancés, mais il faut vérifier ce qu’il ajoute comme JavaScript.
Quelle différence entre lazy loading et eager loading ?
L’eager loading charge une ressource immédiatement. Le lazy loading la charge plus tard, quand elle devient utile. Pour faire simple : eager pour le premier écran, lazy pour les ressources secondaires.
Termes liés
Pour replacer le lazy loading dans une stratégie web responsable, regardez aussi l’éco-conception web, les Core Web Vitals, le LCP, le poids d’une page web, les images responsives, WebP et EcoIndex. Ces sujets se répondent. Optimiser le chargement différé sans traiter les images, le JavaScript et les contenus tiers, c’est faire la moitié du travail.
GreenCodeLab accompagne les équipes qui veulent arbitrer entre performance, SEO et sobriété numérique sans empiler des rustines techniques. Le bon réglage n’est pas le plus spectaculaire. C’est celui qui rend la page plus rapide, plus stable et plus légère pour de vraies visites.