Faut-il vraiment utiliser l'attribut HTML loading pour le lazy-loading ?

Pourquoi Google communique-t-il sur un attribut HTML standard ?

Cette prise de position de Splitt peut paraître anodine — après tout, on parle d'un attribut standardisé. Mais elle intervient dans un contexte où beaucoup de sites utilisent encore des solutions JavaScript lourdes pour gérer le lazy-loading, héritées d'une époque où le support natif n'existait pas.

Google confirme ici que l'attribut loading="lazy" n'est plus une option expérimentale. C'est un signal clair pour les praticiens : la solution native est stable, et il n'y a plus de raison technique de maintenir des polyfills ou des scripts tiers complexes.

Qu'est-ce que cet attribut apporte concrètement ?

L'attribut loading permet de différer le chargement des images et iframes jusqu'à ce qu'elles approchent du viewport. Le navigateur gère tout — pas de JavaScript, pas de librairie externe, pas de calcul de position manuel.

Les anciens navigateurs qui ne reconnaissent pas l'attribut le traitent comme n'importe quel attribut inconnu : ils l'ignorent et chargent l'image normalement. Pas de bug, pas de contenu invisible, pas de risque pour l'expérience utilisateur.

Quels sont les avantages pour le SEO et la performance ?

• Performance améliorée : réduction du poids initial de la page et du temps de chargement perçu
• Core Web Vitals : impact direct sur LCP (Largest Contentful Paint) en priorisant les ressources above-the-fold
• Crawl optimisé : Googlebot comprend nativement cet attribut et ne le considère pas comme du cloaking
• Maintenance simplifiée : aucune dépendance JavaScript à maintenir ou mettre à jour
• Compatibilité progressive : dégradation élégante sur les vieux navigateurs sans intervention

Cette recommandation est-elle cohérente avec les observations terrain ?

Oui, sans réserve. Les tests montrent que loading="lazy" fonctionne exactement comme annoncé depuis que Chrome 76 l'a introduit. Firefox et Safari ont suivi, et la couverture navigateur dépasse désormais 95% du trafic mondial.

Ce qui change ici, c'est la validation explicite de Google. Beaucoup de sites hésitaient encore, craignant un impact négatif sur le crawl ou l'indexation. Splitt met fin à cette incertitude : l'attribut est non seulement sûr, il est recommandé.

Y a-t-il des cas où cette approche pose problème ?

Un seul piège récurrent : appliquer loading="lazy" aux images above-the-fold. Si votre hero image ou votre LCP portent cet attribut, vous dégradez artificiellement votre performance — exactement l'inverse de l'objectif.

Le lazy-loading natif est conçu pour les ressources hors viewport initial. Tout ce qui est visible au chargement doit charger immédiatement, voire avec fetchpriority="high" pour les éléments critiques.

Faut-il migrer immédiatement depuis une solution JavaScript ?

Si votre solution actuelle fonctionne bien et ne pèse pas lourd, ce n'est pas une urgence absolue. Mais lors du prochain refactoring, migrer vers l'attribut natif simplifiera votre stack et réduira votre dette technique.

Pour les nouveaux projets, la question ne se pose même pas. L'attribut natif devrait être le choix par défaut, sauf besoin métier très particulier.

Que faut-il faire concrètement sur son site ?

Premier réflexe : identifier toutes les images et iframes de votre site qui sont en dessous de la ligne de flottaison. Ces éléments sont candidats parfaits pour loading="lazy".

Ensuite, vérifier que vos images critiques — celles qui participent au LCP notamment — ne portent jamais cet attribut. C'est une erreur courante après une implémentation globale mal ciblée.

Comment auditer l'implémentation actuelle ?

Utilisez Lighthouse ou PageSpeed Insights pour repérer les images lazy-loadées qui impactent négativement le LCP. Le rapport vous indiquera explicitement si une ressource critique a été différée à tort.

Côté crawl, vérifiez dans Search Console que vos images importantes sont bien indexées. Un lazy-loading mal configuré peut théoriquement rendre certaines ressources invisibles à Googlebot, bien que l'attribut natif n'ait pas ce problème.

• Ajouter loading="lazy" à toutes les images en dessous du viewport initial
• Vérifier que les images above-the-fold n'ont PAS cet attribut
• Envisager fetchpriority="high" pour l'image LCP si elle est identifiée
• Tester sur navigateurs anciens (IE11, Safari 14) pour confirmer la dégradation élégante
• Auditer les Core Web Vitals avant/après pour mesurer l'impact réel
• Nettoyer les anciennes librairies JavaScript de lazy-loading devenues inutiles