Lazy Loading, des pages web plus rapides sans risque SEO

Les images sont au cœur de votre site web ? Si vous prenez la performance de votre site au sérieux, vous les avez probablement optimisées.

Mais avez-vous pensé à les charger en Lazy Load ? Le Lazy Load des images améliore l’expérience utilisateur en libérant de la bande passante pour le contenu important.

Certains rejettent la technique pour des questions de SEO. Mais un Lazy Load de vos images ne les empêche pas d’être indexées. Voyons pourquoi vous devriez implémenter un Lazy Load d’images et comment vous assurer qu’il soit compatible avec votre SEO.

Lazy loading : optimiser les images de votre site Web

Les images sont partout sur le Web, mais servir l’image la plus adaptée au contexte courant peut s’avérer très difficile. L’image doit être optimisée, adaptée à sa zone de rendu et chargée uniquement si nécessaire.

Le Lazy Loading d’images est un ensemble de techniques conçues pour répondre à ce dernier besoin en différant le téléchargement de chaque image jusqu’au moment où elle est nécessaire : après une interaction spécifique, à la suite d’un défilement… ou jamais. L’occasion de préserver de précieux octets sur les forfaits de vos visiteurs (dans certains pays, les forfaits sont très limités en volume de données), mais aussi d’économiser de nombreuses requêtes vers vos serveurs. Une optimisation bienvenue quand vous préparez vos infrastructures à gérer des pics de trafic.

Le rapport pour rester zen 🧘‍♂️ pendant la période du Pic de ventes 

Télécharger

Quelques cas d’usage du Lazy Loading

Il y a de nombreux cas concrets du Lazy Loading. Prenons quelques minutes pour citer quelques exemples.

Résultats de recherche E-commerce (mais pas que)

Ces pages contiennent souvent tellement de résultats que beaucoup de produits se trouvent en dehors de la fenêtre. Est-il utile de télécharger leurs images ? Avec le Lazy Loading, vous pouvez retarder leur chargement jusqu’à ce que la page soit déroulée.

Les carrousels

Pourquoi l’utilisateur devrait-il charger toutes les images alors qu’il ne visualise que la première pendant quelques secondes ? Utilisez le Lazy Loading afin que seule la première image soit chargée au plus vite, et lancez le téléchargement de l’image suivante en arrière-plan, quelques secondes avant l’animation du carrousel. Et ainsi de suite.

Menus et onglets

Les images contenues dans un menu ou un onglet sont souvent masquées, affichées seulement après un clic. Avec le Lazy Loading, vous pouvez retarder le chargement de ces images jusqu’à ce que le bouton affichant l’élément soit survolé ou cliqué.

… et bien d’autres situations

Suivant la nature de votre page, d’autres cas sont envisageables. Aucune image ne devrait être incluse à vos pages sans que vous ne vous soyez posé la question d’en retarder le téléchargement jusqu’à un moment pertinent. Car à la clé, il y a d’importants gains de performance.

Speed Analysis en vidéo

Plongez dans les pages et les parcours pour obtenir des informations et des alertes approfondies sur les performances Web !

Voir la vidéo

Il en faut peu pour être heureux

En retardant le chargement des images qui ne sont pas immédiatement nécessaires (ou, dans certains cas, en ne les chargeant pas du tout), le navigateur économise des ressources (bande passante aussi bien que CPU). Les ressources préservées peuvent être affectées au contenu plus critique : la page se charge plus rapidement et l’expérience utilisateur est améliorée.

Les gains sont aussi présents côté serveur : le processeur et la bande passante nécessaires pour fournir les ressources sont moins sollicités, réduisant les coûts d’hébergement et/ou de CDN.

Comme indiqué dans l’introduction, utiliser du Lazy Loading n’empêche pas vos images d’être indexées par les moteurs de recherche. Mais suivant les techniques utilisées, cela peut être compliqué.

Pour préserver votre référencement naturel et offrir une bonne expérience utilisateur, il est donc essentiel de comprendre comment le Lazy Loading fonctionne, et comment l’utiliser sans risque.

Le Lazy Loading natif pour les images et les iframes

Depuis quelques années, HTML propose un attribut “loading” qui indique au navigateur s’il doit récupérer une image (ou une iframe) immédiatement ou différer son chargement jusqu’à ce que certaines conditions soient remplies.Prenons une image décorative (notez que par souci d’accessibilité, nous plaçons une alternative vide pour que l’image soit ignorée par les outils de restitution) :<img alt=”” src=”/myDecorativeImage.jpg” width=”300″ height=”200″>Trois cas de figure se présentent alors :

1. Si cette image n’est pas dans la partie visible de la page et que nous souhaitons en accélérer le chargement, nous pouvons utiliser la valeur “eager” de l’attribut “loading” :<img alt=”” src=”/myDecorativeImage.jpg” loading=”eager” width=”300″ height=”200″>
2. Si cette image n’est pas dans la partie visible de la page et que nous souhaitons indiquer au navigateur d’utiliser du Lazy Loading, nous pouvons utiliser la valeur “lazy” de l’attribut “loading” :<img alt=”” src=”/myDecorativeImage.jpg” loading=”lazy” width=”300″ height=”200″>
3. Si cette image est dans la partie visible de la page, ne faites rien ! Le navigateur fonctionnera comme il le fait par défaut, et s’occupera de télécharger l’image de la meilleure manière possible.

Ce dernier point est particulièrement important : vous n’avez pas besoin –et ne devriez pas– appliquer un Lazy Loading aux images situées dans la partie visible de la page. Le résultat sera moins performant que si vous n’aviez rien fait.

Cette erreur est pourtant très commune ! D’après le Web Almanac 2021, sur 9.3% des pages, l’image la plus visible et la plus importante (qui sert notamment à mesurer le Largest Contentful Paint) est porteuse d’un attribut “loading=”lazy”, ce qui pénalise son téléchargement.**** AVEC CONTENTSQUARE

Besoin de déterminer quels sont les éléments visibles au chargement d’une page chez vos utilisateurs ? Chaque navigateur ayant une taille qui dépend du matériel utilisé, la question est légitime. Avec Contentsquare Zoning Analysis, la réponse vous sera accessible en quelques secondes via l’indication visuelle “Ligne de Flottaison”.

Heatmaps

> Visualisez les interactions des utilisateurs avec chaque élément de votre site
> Combinez plusieurs KPIs

Je découvre

***

Lazy Loading natif, une solution magique ?

Le Lazy Loading natif est une solution simple à implémenter, bien supportée et sans conséquence sur les navigateurs qui ne le supportent pas (qui chargeront les images comme avant). Son périmètre de fonctionnement s’étend aux iframes, ce qui en fait également un très bon outil pour différer le chargement de contenus web embarqués.

Cependant, son implémentation est grandement portée par le navigateur, qui choisit seul la quantité d’images à charger immédiatement et la manière de le faire.Par exemple, pour éviter une expérience déceptive lors du défilement, Chrome télécharge davantage d’images sur une connexion plus lente que sur une connexion plus rapide.

Sur une connexion 4G et supérieure, Chrome télécharge dès le chargement initial de la page toutes les images visibles, les images en “eager” mais aussi –et c’est plus surprenant– toutes les images en “lazy” située jusqu’à 1250 pixels du haut de la page. Sur une connexion 3G ou inférieur, Chrome considérera les images jusqu’à 2500 pixels du haut de la page.

La manière de télécharger les images est très simple : aucun élément visuel n’est affiché en lieu et place de l’image afin de permettre à l’utilisateur de comprendre qu’un téléchargement est en cours. Le téléchargement de l’image se produit quand le navigateur le souhaite et quand l’image est disponible, elle est affichée instantanément sans animation particulière.

Enfin, la Lazy Loading natif ne s’applique qu’aux éléments <iframe> et <img>. Il ne peut donc pas s’appliquer aux images de fond, qui dépendent souvent d’un “background” défini en CSS.

Speed Analysis en vidéo

Plongez dans les pages et les parcours pour obtenir des informations et des alertes approfondies sur les performances Web !

Voir la vidéo

Utiliser JavaScript pour le Lazy Loading

Si vous souhaitez mieux maîtriser le Lazy Loading de vos images et iframes, ou que vous souhaitez étendre le concept à des blocs entiers de votre interface, alors votre équipe de développement aura besoin de JavaScript.

Des librairies JavaScript comme lazysizes permettent de mieux maîtriser l’ensemble de l’expérience utilisateur. Elles permettent de mieux maîtriser les conditions de téléchargement, d’afficher des images temporaires aux couleurs de votre marque pour indiquer à vos utilisateurs que l’image finale est en cours de chargement, d’animer l’apparition des images quand elles sont téléchargées et plus encore.

Au cœur de ces librairies se trouve souvent le même élément technique que dans le Lazy Loading natif : l’API Intersection Observer, qui s’occupe de savoir quand un élément apparait dans la partie visible de la page (ou dans un autre élément).

Pour éviter que la syntaxe du Lazy Loading JS soit interprétée comme celle du Lazy Loading natif, ces solutions reposent souvent sur un code HTML légèrement différent. Si nous reprenons l’exemple précédent :<img alt=”” src=”/myDecorativeImage.jpg” width=”300″ height=”200″>

Alors une version lazy-loadée pourra avoir cet aspect :<img alt=”” data-lazy-animation=”blur” data-src=”/myDecorativeImage.jpg” src=”brandedPlaceholder.jpg” width=”300″ height=”200″>

Dans cet exemple, l’attribut “src” héberge l’URL de l’image temporaire qui sera immédiatement chargée. L’attribut “data-src” est utilisé par la librairie JavaScript pour télécharger la vraie image, et l’attribut “data-lazy-animation” pour comprendre qu’elle doit apparaître avec un effet de flou entrant (blur). Suivant la librairie que vous utilisez, les noms des attributs à utiliser pourront varier, mais les concepts resteront similaires et permettent, via le code HTML de transmettre aux JavaScript les instructions dont il a besoin pour offrir l’UX désiré.

Reste une question importante : que se passe-t-il si JavaScript n’est pas disponible ?

Pas de JavaScript  ? Contourner avec style (et <noscript>)

Il existe un certain nombre de cas dans lesquels JavaScript n’est pas disponible dans le navigateur. En 2018, Buzzfeed estimait qu’environ 1% de ses visiteurs avaient désactivé JavaScript, soit environ 13 millions de pages vues par mois.

Les robots d’indexation, comme les Googlebots, sont des logiciels qui parcourent le Web dans le but d’en indexer le contenu. Personne ne sait avec certitude quand les Googlebots vont exécuter le code JavaScript de leurs pages, et sous quelles contraintes mais comme démontré par Stephan Boyer en 2016 [EN] et confirmé plus tard par Tom Greenaway pendant Google IO 2018 [EN], il est possible que les Googlebots n’exécutent pas JavaScript durant leur première visite. Pour obtenir une indexation se basant sur un rendu complet (incluant JavaScript), il est parfois nécessaire d’attendre un nouveau passage, qui peut prendre plusieurs jours.

“Comme les Googlebots indexent le contenu web en deux temps, il est possible que certains détails nous échappent.”

TOM GREENAWAY, Product Lead chez Google

Si vous utilisez du Lazy Loading natif, ces situations ne poseront aucun problème. Quand JavaScript n’est pas supporté, la fonctionnalité est totalement désactivée et les images se chargent normalement.

Si vous utilisez une librairie JavaScript personnalisée, en revanche, vous utilisateurs concernés risquent de ne voir que l’image de placeholder. Parce que si JavaScript n’est pas disponible, les images qui devraient être chargées en Lazy Load ne le seront pas, car l’attribut “src” ne sera jamais remplacé par la valeur présente dans l’attribut “data-src”. Le navigateur ne démarerra pas le téléchargement des images cibles, et elles ne seront pas affichées.

Comment servir ces images malgré l’absence de JavaScript ? Il y a un élément HTML spécifique que vous pouvez utiliser : <noscript>. Le contenu d’un élément <noscript> n’est affiché que si les fonctions de script ne sont pas supportées ou sont désactivées. C’est exactement ce qu’il nous faut !

Donc si votre réponse HTML contient :

<img alt=”” data-lazy-animation=”blur” data-src=”/myDecorativeImage.jpg” src=”brandedPlaceholder.jpg” width=”300″ height=”200″>

<noscript>

<style>img[data-src] {display: none;}</style>

<img alt=”” src=”/myDecorativeImage.jpg” width=”300″ height=”200″>

</noscript>

alors :

• lorsque JavaScript est disponible, seul le premier élément <img> est affiché ;
• lorsque JavaScript n’est pas disponible, les deux éléments <img> sont pris en compte lors de l’affichage de la page. Le second (dans l’élément <noscript>), est affiché et indexé par les moteurs de recherche et grâce au contenu de la balise <style>, le premier élément <im>, porteur du Lazy Load interrompu par l’absence de JavaScript, est masqué.

Comme le code de chaque image est plus que dupliqué, vous pourriez craindre que cette implémentation ne produise un code HTML verbeux. Ne vous inquiétez pas, vos documents HTML sont normalement compressés avec gzip ou brotli avant d’être envoyés sur le réseau. Ces algorithmes excellent dans la compression de contenu contenant des chaînes de caractères répétées (HTML est littéralement un langage basé sur la répétition des balises ouvrantes et fermantes autour des contenus). L’impact de ces duplications sur le poids du transfert est donc négligeable.

Reste bien sûr que saisir toutes ces balises n’est pas évident. En gérant les images responsives, la direction artistique… le balisage des images peut être complexe. Vous ne devriez pas saisir ce code HTML à la main : gérer cette complexité automatiquement devrait être de la responsabilité de votre CMS, ou une tâche dédiée de votre processus de contribution.

Balisage d’une image de The Guardian, avant-même la mise en place d’un Lazy Loading

Tester l’implémentation du Lazy Loading

Une fois le Lazy Load implémenté, vous devrez tester qu’il fonctionne. La solution la plus simple est, bien sûr, d’exécuter un audit complet de performance web avec Speed Analysis pour détecter si les images sous la ligne de flottaison sont chargées tardivement ou à la demande. Si ce n’est pas le cas, l’outil vous remontera les URL des images pour lesquelles le chargement peut être reporté.

**** AVEC CONTENTSQUARE

Si vous avez conditionné le chargement de vos images à la survenue d’un événement personnalisé, n’hésitez pas à consulter la Waterfall de votre rapport pour vérifier que le chargement des images respecte votre chronologie. N’hésitez pas à utiliser un Custom Timing pour être en mesure de le retrouver dans la Waterfall.

Si vous avez conditionné le chargement de vos images au scroll (ce qui est le cas du Lazy Loading natif), vous pouvez utiliser la fonctionnalité “Scenario” de Speed Analysis pour tester le chargement initial de la page dans une première étape, puis le scroll jusqu’à une certaine hauteur dans une seconde étape. L’analyse de ce scénario vous permettra de vérifier le bon fonctionnement de votre Lazy Loading mais aussi d’en mesurer la vitesse.

Enfin, n’hésitez pas à analyser le taux d’exposition des éléments concernés dans notre module Zoning Analysis afin de vous assurer que les éléments ainsi chargés présentent le même Taux d’Exposition avec et sans Lazy Loading, et ajuster le seuil de téléchargement

***

Enfin, pour vérifier que les robots d’indexation verront également vos images, vous pouvez utiliser l’outil Inspecteur d’URL de la Google Search Console (si vous n’avez pas accès à la Google Search Console pour votre site, demandez à votre responsable ou prestataire SEO). Vous afficherez votre page exactement comme si elle avait été récupérée par un robot Google, cela vous permettra de confirmer que votre contournement <noscript> fonctionne comme prévu.

Vous savez maintenant tout ce qu’il y a à savoir sur le Lazy Loading d’images, son impact SEO et la meilleure façon de le contourner. Il est temps de faire un peu de ménage !