Hybrid Lazy Loading : la fausse bonne idée !
Comme on vous l’avait annoncé le lazy loading en JavaScript va disparaitre (enfin!). En effet, un lazy loading « natif » a vu le jour et devrait être implémentée dans les prochaines versions de Chrome et de Firefox (qui connait quelques pannes). Toutefois pour le moment, cette technique n’est pas encore reconnue par les navigateurs.
Dès lors, le site smashingmagazine.com a proposé dans un de ses derniers articles, une solution hybride pour faire fonctionner ensemble, selon le navigateur qui consulte la page, les 2 techniques de Lazy Loading. Nous pensons que c’est une mauvaise idée en terme de web performance et on va vous dire pourquoi.
Le lazy loading natif
Annoncé en avril 2019 – et oui c’est tout récent – le principe du lazy loading natif est le suivant : le navigateur détecte si l’image est ou va bientôt être visible dans la fenêtre navigateur avant de la charger. Ainsi Chrome et Firefox se sont désormais mis d’accord sur un nouvel attribut « loading ».
Cet attribut « loading »permet à un navigateur de différer le chargement des images et des iframes hors écran jusqu’à ce que les utilisateurs défilent à proximité. Il peut prendre 3 valeurs :
- lazy : est un bon candidat pour le chargement paresseux.
- eager : n’est pas un bon candidat . Chargez tout de suite.
- auto : le navigateur déterminera s’il faut charger paresseusement ou non.
Enfin j’attire votre attention sur le fait que ne pas spécifier l’attribut aura le même impact que le fait de définir loading=auto.
Bien qu’attendu pour cette été dans Chrome 76, les principes évoquées ci-dessus sont en cours de spécification au WHATWG. On peut donc attendre quelques années avant que cela soit validé auprès du W3C. Mais cotés validateur de code html, je vous rappelle que ne pas spécifier l’attribut aura le même impact que le fait de définir loading=auto.
La solution hybride
Certains concepteurs de pages web anticipent déjà la mise en place du lazy loading natif avec une solution hybride.
Pour cela il suffirait de modifier l’ancienne technique :
<img class="lazyload" alt=".." data-src="image.jpg" />
en y ajoutant l’attribut loading :
<img loading="lazy" class="lazyload" alt=".." data-src="image.jpg" />
Ensuite un JavaScript viendrait en fonction du support de l’attribut loading par le navigateur,
- si supporté : attribuer la valeur de data-src à un src en bonne et due forme.
- si non utiliser l’ancienne technique avec une méthode de détection full JavaScript avec IntersectionObserver par exemple.
NB : c’est la même logique avec les iframes.
Et là je vous épargne la complexité du code avec la prise en compte des srcset pour les images responsives.
L’avis d’artwaï
Notre regard critique
Cela signifie que pour implémenter la solution hybride, il faut qu’un JavaScript parcourt l’ensemble de la page pour reformater l’HTML de toutes images et iframes avec l’attribut loading natif pour ceux qui le supportent… Vous la voyez venir l’aberration métaphysique qui me chatouille les neurones ?
L’objectif d’une technologie native aux navigateurs est de s’affranchir de JavaScript. Or ici on reste complément lié au JavaScript avec un parcours complet de l’arbre DOM très coûteux en terme d’exécution. Du coup avec ce genre d’hybridation on ne fait pas d’amélioration progressive, on dégrade l’expérience native !
Comme notre agence web basée à Rennes est adepte du No Fucking JS ; je vous rappelle ici la petite note en gras ci-dessus : ne pas spécifier l’attribut aura le même impact que le fait de définir loading=auto. Ne rien faire est donc encore la meilleure solution.
Que faire alors ?
Concrètement, si vous avez besoin de lazy loading aujourd’hui, gardez la version JavaScript. Par contre dès que les versions Chromium et Firefox supportant le lazy loading natif seront suffisamment déployées sur votre cible – et avec les mises à jour automatiques cela peut aller très vite – alors il vous suffira de débrancher le JavaScript réalisant le lazy loading. L’ajout de l’attribut loading deviendra anecdotique, uniquement nécessaire là où l’image devra être chargée de suite. Les anciens navigateurs eux n’auront simplement pas de lazy loading du tout, mais la page restera accessible et pas forcément sans être rapide à charger…
En effet, je recommande toujours de travailler sur les optimisations des images avant de faire du lazy loading. Pourquoi ? Parce que cela revient à mettre la poussière sous le tapis. Et quand on soulève le tapis, la poussière est toujours là. Par exemple, sur ce site il n’y a pas de lazy loading. Mais nos images sont passées au travers d’une moulinette automatique qui en génère les différentes tailles et formats (jpg et webp). Résultat, l’ensemble est assez léger et ne nécessite pas de lazy loading.
Toutefois dès que le lazy loading natif serait accessible dans les navigateurs, nous nous empresserons… de ne rien faire en fait ! Car ne pas spécifier l’attribut aura le même impact que le fait de définir loading=auto.
Mise à jour du 22/05/2019
Le site caniuse.com vient d’ajouter le suivi du support de l’attribut lazy. Ce site quasi indispensable pour l’intégration web liste l’état des supports des technologies web dans les différentes version de navigateurs les plus courants. Bref, à partir de là vous saurez quand basculer vers le lazy loading natif.
Source : l’article de smashingmagazine.com
Photo de Sebastian Molinares par Unsplash
