Chargement différé des images : quand l’utiliser et quand l’éviter

Que change le chargement différé ?

Le chargement différé, ou lazy loading, change le moment où le navigateur demande une image. Il ne modifie ni ses dimensions, ni son format, ni sa compression. Sur une longue recette, le visiteur a besoin du début rapidement, mais ne verra peut-être jamais les quinze photos de la fin. Attendre avant de les demander peut éviter des téléchargements inutiles à l’ouverture.

Il faut distinguer trois tâches : redimensionner réduit le nombre de pixels, compresser réduit la quantité de données, et différer repousse la demande. Une grande image reste lourde lorsqu’elle finit par charger. Une petite image peut apparaître tard si sa demande a été retardée.

Préparez les dimensions avec l’outil de redimensionnement et comparez la compression si nécessaire. Décidez ensuite quelles images sont utiles dès l’ouverture. Le guide sur la taille des fichiers couvre la préparation ; celui-ci concerne le moment du chargement.

Commencer sans toucher au code

Vous pouvez choisir les images à charger en premier sans modifier le HTML. Commencez par une page produit ou un long article. La vue initiale désigne la partie visible avant tout défilement.

1. Cherchez le réglage existant. Dans l’administration du site, consultez le thème, les images ou les performances. Cherchez « lazy loading » ou « chargement différé ». Le nom et l’emplacement varient ; certains services le gèrent automatiquement. Demandez au responsable du site avant d’installer une autre extension.
2. Préservez la vue initiale. L’image principale et les autres images immédiatement visibles doivent charger normalement. Si des exclusions existent, demandez comment les définir. N’activez pas une règle générale avant de savoir ce qu’elle fait à l’image principale.
3. Essayez sur les images plus bas. Les illustrations de la suite d’un article sont un bon début. Utilisez si possible un aperçu ou une page de test, puis contrôlez la page publiée. Testez les galeries séparément, car on peut les parcourir rapidement.
4. Vérifiez le confort de lecture. Sur téléphone et ordinateur, l’image principale apparaît-elle vite ? Les autres arrivent-elles à temps quand vous faites défiler lentement puis rapidement ? Le texte saute-t-il à leur apparition ? Essayez aussi un lien vers une section plus bas.

Si un problème apparaît, annulez le dernier réglage et demandez de l’aide pour cette page. Ces vérifications révèlent les retards ou déplacements évidents, mais ne prouvent pas un gain de vitesse. Il faut des mesures ; la section de test précise lesquelles relever.

Voici une demande à transmettre : « Vérifiez le chargement différé sur cette page. Laissez charger normalement l’image principale et les images visibles à l’ouverture. Différez les images adaptées plus bas et réservez leur espace pour éviter les sauts de texte. Testez sur mobile et ordinateur, puis comparez le temps de chargement de l’image principale avant et après. » Ajoutez le lien de la page et signalez les images qui arrivent tard.

Quelles images charger plus tard ?

Ouvrez une page représentative sans la faire défiler. Repérez les images visibles et celles qui aident à comprendre le contenu. Recommencez sur un téléphone étroit et un grand écran : bannière, titre et galerie de produits peuvent occuper des places différentes.

Choisissez selon la position réelle, pas selon le nom du fichier ou l’ordre d’importation. La première image de la médiathèque n’est pas forcément la première de la page. Une photo après une longue introduction peut aussi apparaître dès l’ouverture dans un autre modèle.

Si la même image est visible immédiatement sur ordinateur mais plus bas sur mobile, commencez par un chargement normal. L’attribut loading n’offre pas de requête média comme picture. N’ajoutez pas un script qui vérifie la taille de l’écran uniquement pour économiser une demande : évaluez d’abord son coût réel.

Une image cachée dans une galerie ne sera pas forcément téléchargée plus tard. Le script de la galerie peut la précharger indépendamment des attributs. Testez les changements rapides et le retour à une image précédente, pas seulement le défilement.

Pourquoi l’image principale ne doit pas attendre

Largest Contentful Paint (LCP) mesure le délai d’apparition du plus grand élément de contenu visible à l’ouverture. Il s’agit souvent de la photo principale, parfois d’un bloc de texte. Identifiez-le dans le rapport de performance. Si c’est une image, évitez de différer son chargement. Une adresse présente dans le HTML initial permet au navigateur de commencer tôt ; une adresse ajoutée après l’exécution d’un script peut créer un délai supplémentaire.

Retirer le chargement différé ne corrige pas tout. La réponse du serveur, la taille du téléchargement ou l’affichage peuvent encore ralentir l’image. Le guide Google d’optimisation du LCP distingue ces étapes. Le guide Pixilo sur les Core Web Vitals sépare les problèmes de chargement des déplacements de contenu.

Réservez fetchpriority="high" à une image dont vous avez établi l’importance. Donner cette priorité à toute la galerie ne crée pas d’ordre utile. Ce réglage n’annule pas non plus le report d’une image chargée en mode lazy.

Vérifier ce que font déjà le CMS et la galerie

Avant d’installer une extension, inspectez l’image publiée. Le CMS, le thème ou un service peut déjà ajouter l’attribut. Regardez le HTML obtenu et la demande réelle, pas seulement un nom tel qu’« optimisation des images ».

Gérez ce comportement à un seul endroit. Si un script remplace les adresses, ajoute des éléments autour des images ou précharge les diapositives, un second mécanisme complique le diagnostic. Commencez sur une page et excluez l’image principale du report.

Un fond CSS est un autre cas : l’attribut de chargement de img ne s’applique pas à une déclaration d’arrière-plan. Demandez au responsable du modèle comment cette ressource est découverte. Coller du HTML dans un bloc de contenu ne change pas le fond du thème.

Ajouter le chargement différé natif en HTML

Pour une illustration nettement sous la vue initiale, gardez l’adresse réelle dans src et ajoutez l’attribut de chargement. Remplacez les chemins d’exemple par vos fichiers. Le texte alternatif décrit ce que montre l’image ; les consignes de recette restent dans le texte. Une image purement décorative reçoit alt="".

<img
  src="/images/recipe-step-04.webp"
  width="1200"
  height="800"
  loading="lazy"
  alt="Pâte repliée sur la garniture, avec les bords encore ouverts"
>

Une photo identifiée comme élément LCP dans la vue initiale demande un autre choix :

<img
  src="/images/finished-loaf.webp"
  width="1200"
  height="800"
  loading="eager"
  fetchpriority="high"
  alt="Pain tout juste sorti du four, à la croûte dorée"
>

eager demande un chargement normal, comme l’absence de loading en général. Le préciser peut aider si le modèle ajoute autrement le mode lazy. Cela ne signifie pas un téléchargement instantané. La référence MDN de l’élément image explique ces attributs.

Le navigateur décide quand une image est assez proche pour la demander, parfois avant qu’elle soit visible. Une demande hors écran ne prouve donc pas un échec. Ne fixez pas un seuil de défilement pour valider le test. Consultez le guide web.dev du chargement différé natif.

Réserver l’espace et garder les variantes adaptées

Indiquez dans width et height les dimensions du fichier source, ici 1200 × 800 pixels. Elles définissent ses proportions ; le CSS peut l’afficher plus petit. Copier ces nombres sur une autre forme réserverait un espace incorrect. Pour réduire l’image sans la recadrer :

.article-image {
  display: block;
  max-width: 100%;
  height: auto;
}

Ajoutez class="article-image" à l’image ou adaptez une règle existante. Pour un recadrage fixe, réservez la surface affichée. Vérifiez la mise en page : d’autres règles CSS peuvent modifier le résultat.

Le chargement différé ne remplace pas srcset et sizes. Gardez les variantes utiles au choix du fichier. Dans picture, le réglage se place sur img. Le guide des images adaptatives donne des exemples complets.

Tester la page publiée

1. Relevez la situation initiale. Notez URL, taille de la fenêtre, élément et temps LCP, début de la demande de l’image principale et données d’images transférées avant défilement. Précisez si le test simule une première visite ou utilise le cache.
2. Examinez les demandes. Ouvrez Network avant de recharger et filtrez les images. Quels fichiers sont demandés au début, et à quel moment ?
3. Changez une seule règle. Retirez par exemple le report de l’image principale ou activez-le pour les illustrations suivantes.
4. Confirmez le résultat publié. Vérifiez les attributs et les adresses après l’actualisation nécessaire des caches. Une modification locale ne change pas encore le site en ligne.
5. Recommencez et faites défiler. Comparez des essais équivalents, puis parcourez la page lentement et vite, utilisez les galeries et les liens de section. Repérez les zones vides et les sauts de contenu.

« Disable cache » écarte le cache du navigateur tant que les outils de développement sont ouverts, mais ne vide pas celui du serveur ou du CDN. La documentation Chrome du panneau Network explique l’inspection. Gardez les mêmes conditions réseau et comparez plusieurs essais, pas seulement le meilleur.

Commencez en haut de page avec les mêmes dimensions et la même durée d’observation avant défilement. Notez les résultats initiaux avant de descendre, sinon les nouvelles demandes brouillent le comparatif. Une position de défilement restaurée peut aussi faire charger immédiatement une image plus bas.

Une bonne modification rend le début disponible rapidement et les images suivantes au bon moment. Réduire les demandes initiales n’aide que si lecture et navigation restent fluides. Le guide PageSpeed aide à comparer les résultats.

Exemple : une couverture et douze illustrations

Un long article comporte une couverture visible à l’ouverture et douze photos plus bas. Une règle globale diffère les treize. Sur téléphone, la couverture apparaît tard malgré un fichier léger. Il s’agit d’un scénario illustratif, pas d’un gain mesuré.

Vérifiez si la couverture est l’élément LCP. Retirez son report et testez ce seul changement. Gardez un report sélectif pour les images suivantes en réservant leur espace. Si la première illustration est visible immédiatement sur ordinateur, laissez-la aussi charger normalement.

Après publication, comparez le début de la demande et le LCP dans des conditions similaires. Parcourez les douze images et ouvrez un lien de section. Si la couverture arrive tôt mais reste cachée par une animation, examinez ce délai d’affichage plutôt que de modifier encore l’attribut.

Garder les images accessibles aux moteurs de recherche

Utilisez un texte alternatif pertinent et une vraie adresse. Un script qui garde un espace réservé jusqu’à un clic ou un défilement demande une vérification. Les conseils Google sur le contenu différé recommandent un chargement à l’entrée dans la zone visible sans dépendre d’une action de l’utilisateur.

Si nécessaire, examinez la page rendue avec l’inspection d’URL de Search Console. Les adresses importantes figurent-elles dans le HTML rendu ? Un réglage de performance ne garantit ni l’indexation de toutes les images ni un meilleur classement.

Questions fréquentes

Faut-il différer toutes les images ?

Non. Choisissez selon leur place et leur importance. Celles utiles dès l’ouverture, surtout l’image LCP, ne doivent pas attendre.

Le fichier devient-il plus petit ?

Non, seule l’heure de la demande change. Redimensionnez ou compressez une copie si les dimensions ou le poids sont excessifs.

Faut-il une bibliothèque JavaScript ?

Pas pour le chargement différé natif d’images HTML ordinaires. Si JavaScript est désactivé, le report est désactivé et les images ayant une vraie adresse chargent normalement. Un script qui garde l’unique adresse dans data-src nécessite une solution de repli. Réservez une solution personnalisée à un besoin précis et testez-la.

Pourquoi certaines images hors écran chargent-elles tout de suite ?

Elles sont peut-être assez proches, ou un autre composant les précharge. Vérifiez l’origine de la demande ainsi que les réglages du thème et de la galerie.

Le décodage asynchrone remplace-t-il le chargement différé ?

Non. decoding concerne le décodage et l’affichage, loading le report. L’un ne confirme pas le réglage de l’autre.

Résumer avecChatGPT (s’ouvre dans un nouvel onglet)Grok (s’ouvre dans un nouvel onglet)Google (s’ouvre dans un nouvel onglet)Perplexity (s’ouvre dans un nouvel onglet)Claude (s’ouvre dans un nouvel onglet)