Lazy loading

Le lazy loading diffère le chargement d’une ressource non critique jusqu’au moment où elle est nécessaire, ce qui réduit le travail initial lorsque le contenu différé reste découvrable, utilisable et accessible aux crawlers.

Le lazy loading diffère le chargement d’une ressource non critique jusqu’au moment où elle est nécessaire, ce qui réduit le travail initial lorsque le contenu différé reste découvrable, utilisable et accessible aux crawlers.

Illustration du mécanisme abordé dans l’article sur le lazy loading.

Choisir ce qui peut attendre

Le lazy loading convient aux contenus situés bien sous la ligne de flottaison, comme les images des galeries inférieures, les intégrations ou les vignettes d’une longue liste. C’est un mauvais réglage par défaut pour l’image principale (hero), une image produit dont l’acheteur a besoin immédiatement, l’élément le plus grand (LCP) ou un composant nécessaire à la navigation au clavier. Différer une ressource située au-dessus de la ligne de flottaison peut retarder le moment précis où la page devient utile.

Faites l’inventaire de la zone visible initiale sur les largeurs courantes, mobile et bureau. Repérez le candidat LCP probable avant d’ajouter des attributs de chargement. Utilisez une largeur et une hauteur explicites, ou un ratio d’affichage réservé équivalent, pour que les images ne repoussent pas le texte à leur arrivée.

Utiliser un balisage robuste

Pour les images ordinaires, l’attribut natif loading="lazy" du navigateur suffit souvent. Conservez une valeur alt significative pour les médias informatifs, un alt vide uniquement pour les éléments décoratifs, et une source d’image réelle qui reste disponible sans script déclenché par le défilement. Pour les images adaptatives, fournissez les attributs srcset et sizes appropriés afin que le navigateur ne télécharge pas par défaut une ressource surdimensionnée.

Ne placez pas de liens, titres ou informations produit essentiels uniquement dans un composant lazy côté client. Un crawler, ainsi qu’un utilisateur dont le script ne s’exécute pas, doivent quand même découvrir le contenu principal de la page. Les Intersection Observer peuvent être utiles pour des widgets spécialisés, mais ils ajoutent des modes de défaillance que le balisage natif évite.

Tester la limite du viewport

Utilisez un test mobile avec bridage réseau et un chargement de navigateur normal. Vérifiez si l’image principale démarre rapidement, si les médias situés sous la ligne de flottaison sont bien différés, et si chaque ressource apparaît au défilement sans espaces réservés vides ni décalages de mise en page. Inspectez le DOM et la cascade réseau : une image marquée lazy mais chargée immédiatement est peut-être proche de la zone visible ; une image chargée trop tard a peut-être été différée de façon trop agressive.

Pour un article dont un schéma suit l’introduction, le lazy loading peut être raisonnable si le schéma n’est pas l’élément LCP et si ses dimensions sont réservées. Pour une fiche produit, l’image principale du produit est en général un mauvais candidat, car elle intervient dans la première décision.

Limites et vérification

Un nombre de requêtes initiales plus faible ne prouve pas à lui seul une page plus rapide ou meilleure. Mesurez séparément le temps de réponse du document, le LCP, la stabilité de la mise en page et l’interaction. Après une modification de gabarit, vérifiez à nouveau le HTML après rendu et un échantillon d’URL parcourues par un crawler, afin que les médias différés conservent leur texte alt prévu, le contexte de la page canonique et leurs liens internes.

FAQ

L’image principale (hero) de la page d’accueil doit-elle être chargée en lazy loading ?
En général non. Si elle est nécessaire dans la première zone visible ou si elle constitue l’élément LCP, la différer peut retarder la page utile.
Comment les images chargées en lazy loading peuvent-elles éviter les décalages de mise en page ?
Réservez leur espace avec width et height, ou avec un ratio d’affichage approprié, avant l’arrivée de l’image.