Lazy loading des images : quand l'utiliser, quand l'éviter

Le lazy loading des images est un réglage qui demande au navigateur de ne télécharger une image qu'au moment où elle approche de l'écran, au lieu de la charger avec le reste de la page. En HTML, il tient dans un attribut : loading="lazy". Bien posé, il allège les pages longues. Mal posé, il retarde l'affichage du contenu principal et dégrade la mesure que Google regarde. Voici la règle d'arbitrage, et les cas où il faut s'en abstenir.

La règle en une phrase

Différez généreusement tout ce qui est loin de l'écran, jamais ce qui est visible à l'ouverture. C'est la conclusion de l'étude publiée sur web.dev par Felix Arntz et Rick Viscomi le 31 mars 2022, et elle n'a pas bougé depuis. Leur mesure sur les données HTTP Archive est la seule chose à retenir si vous ne lisez rien d'autre : la médiane du LCP des pages qui utilisent le lazy loading était de 3 546 ms, contre 2 922 ms pour celles qui ne l'utilisent pas. Soit 621 ms de retard, sur des pages censées être plus rapides.

La cause tient en peu de mots. Le lazy loading ne trie pas les images à votre place. Appliqué sans arbitrage, il touche aussi celle qui occupe le premier écran, donc celle qui déclenche le Largest Contentful Paint. Le navigateur doit alors savoir où l'image se situe avant de décider de la télécharger, ce qui ajoute un aller-retour là où il n'en fallait aucun.

Combien de sites se tirent une balle dans le pied

Le Web Almanac 2025 de HTTP Archive chiffre l'ampleur du problème. Entre 16 et 17 % des pages appliquent le lazy loading à leur propre image LCP. Dans le détail, 10,4 % des pages mobiles et 11,5 % des pages desktop posent l'attribut natif sur cet élément, et 5,9 % des pages mobiles passent par une approche maison de type data-src.

Le même rapport rappelle pourquoi l'enjeu se concentre sur les images : 85,3 % des pages desktop et 76 % des pages mobiles ont une image comme élément LCP. Sur la grande majorité des sites, la vitesse perçue se joue donc sur un seul visuel, et une page sur six le fait attendre volontairement.

En face, l'attribut qui sert à accélérer cette image reste peu employé : fetchpriority="high" n'est présent que sur 16,3 % des pages desktop et 17,3 % des pages mobiles, en hausse de deux points par rapport à 2024.

Ce que fait exactement l'attribut loading

Il accepte deux valeurs. lazy repousse le téléchargement jusqu'à ce que la ressource atteigne une distance calculée du viewport. eager est le comportement par défaut du navigateur : l'image part immédiatement, quelle que soit sa position.

La distance de déclenchement n'est pas la ligne de flottaison, contrairement à ce qu'on lit souvent. Chrome anticipe : environ 1 250 px sur une connexion 4G, environ 2 500 px en 3G ou moins. Le navigateur lance donc le chargement bien avant que l'image entre à l'écran, ce qui explique que le gain visible soit souvent plus faible qu'espéré sur une page courte.

Côté support, la documentation web.dev mise à jour le 13 août 2024 donne Chrome 77 et supérieur, Edge 79, Firefox 75, Safari 15.4. Le sujet de la compatibilité est clos. Il n'y a plus de raison de charger une bibliothèque JavaScript pour faire ce travail.

Deux limites à connaître. L'attribut ne fonctionne que sur les balises img et iframe : une image de fond déclarée en CSS lui échappe complètement. Et il faut poser width et height sur chaque image, sinon le navigateur ne réserve pas la place et la page saute au moment où l'image arrive, ce qui dégrade le Cumulative Layout Shift.

Quelle image différer, quelle image charger tout de suite

La décision se prend image par image, en regardant la page au format téléphone plutôt qu'au format écran large. Voici la grille que nous appliquons en audit.

Le piège le plus courant est celui de la troisième ligne. Un visuel placé à droite d'un bloc de texte en desktop se retrouve empilé sous ce texte en mobile, ou l'inverse. Le réglage correct en desktop devient alors un réglage faux en mobile, et c'est la version mobile qui pèse dans la mesure.

Ce que Google demande côté indexation

La documentation Google Search Central sur le contenu différé, mise à jour le 10 décembre 2025, pose une seule exigence de fond : votre implémentation doit charger tout le contenu pertinent dès lors qu'il est visible dans le viewport. Google reconnaît explicitement trois méthodes, le lazy loading natif du navigateur, l'API IntersectionObserver, et les bibliothèques qui chargent le contenu entrant dans le viewport.

La contrainte qui fait échouer les implémentations maison tient en une phrase : Google Search n'interagit pas avec la page, il ne fait ni défiler ni cliquer. Un chargement déclenché par une action utilisateur, un bouton "voir plus" ou un défilement réel, ne sera jamais atteint par le robot.

Pour vérifier, Google renvoie vers l'outil d'inspection d'URL de la Search Console : regardez le HTML rendu et confirmez que les URL d'images figurent bien dans l'attribut src des balises img. C'est un contrôle de trois minutes, à faire une fois par modèle de page plutôt qu'une fois par page. Il a sa place dans tout audit technique SEO sérieux.

Une précision utile sur le défilement infini : Google demande une URL unique et stable par bloc de contenu, avec un numéro de page absolu du type ?page=12, et des liens séquentiels entre ces URL. Une page qui empile ses résultats sans jamais changer d'URL n'expose qu'un seul document à l'indexation.

Le cas Webflow

Webflow applique le chargement différé par défaut à toute nouvelle image depuis une mise à jour publiée le 27 août 2020. Cette bascule n'a pas touché les images déjà en place sur les sites existants, et le réglage se change image par image dans le panneau de paramètres.

La conséquence pratique sur un projet Webflow est contre-intuitive : le travail ne consiste pas à activer le lazy loading, il est déjà actif. Il consiste à le désactiver sur le visuel du premier écran de chaque modèle de page. Sur un site CMS, cela veut dire le modèle d'article, le modèle de page de liste, la home et les pages de service. Cinq à dix corrections, pas davantage, pour un gain qui se lit directement dans PageSpeed Insights.

Le réglage ne couvre pas les images de fond posées en style. Sur un site chargé en visuels de fond, l'arbitrage se déplace vers le poids des fichiers et leur format, un sujet traité dans notre guide sur les images et le SEO et dans nos étapes d'optimisation SEO sur Webflow.

Ce que ça change sur un projet réel

Pour Les Fermes de Marie, hôtellerie de luxe à Megève, nous avons mené un audit SEO qui a donné lieu à plus de 50 corrections techniques. Sur ce type de site, où le visuel porte la promesse commerciale, le réglage de chargement des images n'est pas un détail de développeur. C'est ce qui sépare une page d'accueil qui s'affiche avant que le visiteur décroche d'une page qui s'affiche après. Synqro est une agence Webflow Premium Partner à Paris, et ce contrôle fait partie de nos livraisons standard.

Les quatre erreurs qui reviennent

Tout différer par principe. C'est le cas le plus fréquent, et celui que mesure le Web Almanac. Le lazy loading n'est pas une optimisation qu'on ajoute, c'est un arbitrage qu'on pose.

Oublier width et height. Le gain de poids est réel, le CLS se dégrade, le bilan est négatif. Ces deux attributs coûtent dix secondes par image.

Empiler une bibliothèque JavaScript sur l'attribut natif. Les deux mécanismes se gênent, et le script ajoute du travail au thread principal. Depuis Safari 15.4, le natif suffit.

Régler sur desktop et ne jamais vérifier en mobile. Le premier écran mobile contient presque toujours plus d'images, en proportion de sa hauteur, que le premier écran desktop.

La vérification, en trois étapes

Ouvrez PageSpeed Insights sur la page et notez quel élément est désigné comme LCP. Ouvrez le code de cet élément et vérifiez qu'il ne porte pas loading="lazy". Si Lighthouse remonte l'audit sur l'image LCP différée, vous avez la réponse sans chercher.

Passez ensuite l'URL dans l'outil d'inspection de la Search Console et lisez le HTML rendu : chaque image du corps doit avoir un src réel. Enfin, refaites le test en simulant un écran de téléphone, parce que c'est cette version que Google indexe.

Pour mémoire, les seuils Core Web Vitals au 75e centile, tels que définis par l'équipe Chrome et mis à jour le 7 mai 2025 : LCP bon jusqu'à 2 500 ms, à améliorer entre 2 500 et 4 000 ms, mauvais au-delà. INP bon jusqu'à 200 ms. CLS bon jusqu'à 0,1.

FAQ

Le lazy loading pénalise-t-il le SEO ?

Non, tant que l'image finit dans le code rendu de la page. Google documente les méthodes qu'il sait suivre, l'attribut natif et l'API IntersectionObserver, et rappelle que Search n'interagit pas avec la page : il ne fait ni défiler ni cliquer. Une image qui n'apparaît qu'après un scroll réel ne sera jamais vue.

Faut-il encore ajouter une balise noscript autour des images différées ?

C'était le conseil de l'époque où le lazy loading reposait uniquement sur du JavaScript maison. Avec l'attribut natif, l'image reste une balise img avec son src dans le HTML : il n'y a rien à rattraper. Cette recommandation traîne encore dans beaucoup d'articles francophones, elle n'a plus d'objet.

Comment savoir quelle image est mon LCP ?

PageSpeed Insights et l'onglet Performance de Chrome DevTools nomment l'élément LCP de la page. Lighthouse remonte en plus un audit dédié quand cet élément porte loading="lazy". C'est le contrôle le plus rentable avant une mise en ligne.

L'attribut fonctionne-t-il sur les images de fond CSS ?

Non. Il ne s'applique qu'aux balises img et iframe. Pour une image de fond, il faut soit la basculer en balise img, soit la charger conditionnellement, soit accepter qu'elle parte avec la feuille de style.

Le lazy loading améliore-t-il les Core Web Vitals ?

Il réduit le poids transféré et peut aider indirectement. Sur le LCP, l'effet devient négatif dès qu'il touche l'image principale. Sur le CLS, il est neutre si les dimensions sont posées, et néfaste si elles ne le sont pas.

Faut-il différer toutes les images sauf la première ?

C'est une bonne approximation en desktop et une mauvaise en mobile. Sur téléphone, le premier écran affiche souvent deux ou trois visuels. Le réflexe correct est de regarder la page au format mobile et de charger en eager tout ce qui est visible sans faire défiler.

Webflow gère-t-il le lazy loading tout seul ?

Webflow applique le chargement différé par défaut aux nouvelles images depuis août 2020, et le réglage se change image par image dans le panneau de paramètres. Le défaut est donc à corriger sur les visuels du premier écran, pas à laisser tel quel.

Combien de temps peut-on gagner ?

Aucun chiffre général n'est fiable, cela dépend du poids des images et du réseau. Ce qui est documenté, c'est l'inverse : sur l'échantillon HTTP Archive, la médiane du LCP des pages qui pratiquent le lazy loading était plus mauvaise que celle des pages qui ne le pratiquent pas.

Pour aller plus loin

Le chargement des images est un des rares chantiers où une demi-journée de travail se lit directement dans la mesure. Si vous voulez que ce contrôle soit fait sur votre site et intégré à vos modèles de page plutôt que refait à chaque publication, notre agence SEO Webflow le prend en charge, et notre équipe d'expert Webflow intervient directement dans le Designer. Parlons de votre projet.