Le lazy loading (chargement différé) est une technique d'optimisation web qui retarde le chargement des ressources non visibles — images, vidéos, composants, données — jusqu'au moment où l'utilisateur scrolle vers la zone de la page où elles apparaissent, réduisant ainsi le temps de chargement initial et la consommation de bande passante.
Voici le paradoxe que peu d'équipes veulent entendre : le lazy loading est excellent pour vos utilisateurs et terrible pour vos tests visuels. C'est une technologie conçue pour ne pas charger le contenu tant qu'il n'est pas visible. Or, un outil de test visuel a besoin de voir le contenu pour le tester. Les deux objectifs sont fondamentalement en tension.
Cette tension n'est pas une raison pour choisir l'un au détriment de l'autre. Votre site a besoin du lazy loading pour performer — les données de Google sont claires, le temps de chargement est un facteur de classement SEO et un déterminant majeur du taux de rebond. Et votre site a besoin de tests visuels pour garantir que le lazy loading n'introduit pas de régressions — un placeholder qui ne disparaît jamais, une image qui se charge avec les mauvaises dimensions, un layout qui saute quand le contenu apparaît.
Cet article vous explique comment concilier les deux.
Pourquoi le lazy loading complique le test visuel
Le contenu invisible n'est pas testable
Le principe fondamental du lazy loading est que le contenu situé en dessous de la ligne de flottaison (below the fold) n'est pas chargé au chargement initial de la page. Un screenshot pris immédiatement après le chargement ne montre que le contenu au-dessus de la ligne de flottaison — tout le reste est soit absent, soit remplacé par des placeholders.
C'est un problème de couverture. Si votre page fait 5000 pixels de haut et que votre viewport mesure 900 pixels, un screenshot initial ne couvre que 18 % de votre page. Les 82 % restants ne sont pas testés. Sur une page produit e-commerce, cela signifie que la description, les avis clients, les produits recommandés, et le footer ne sont jamais vérifiés visuellement.
Certaines équipes pensent résoudre le problème en prenant un screenshot full-page. Mais un screenshot full-page ne déclenche pas le lazy loading — il capture la page telle qu'elle est rendue au moment de la capture, avec les placeholders et les éléments non chargés. Vous obtenez une image complète d'une page incomplète.
Le moment de la capture : un dilemme permanent
Quand exactement devez-vous prendre votre screenshot ? La question semble simple. Elle ne l'est pas.
Si vous prenez le screenshot immédiatement après le chargement de la page, vous capturez l'état initial avec les placeholders. C'est rapide mais incomplet. Si vous scrollez jusqu'en bas de la page avant de capturer, vous déclenchez le chargement de tout le contenu différé — mais le temps que chaque ressource se charge, le contenu en haut de la page peut avoir changé (animations, mises à jour temps réel, réaffichage du header).
Et puis, le scroll lui-même modifie l'apparence de la page. Un header sticky qui apparaît au scroll, un bouton "retour en haut" qui se matérialise, un indicateur de progression de lecture qui se remplit — tous ces éléments changent selon la position de scroll, et leur état au moment de la capture varie d'une exécution à l'autre.
Les images placeholder et le layout shift
Le lazy loading d'images utilise des placeholders pour réserver l'espace dans le layout : des rectangles gris, des blurs de basse résolution (LQIP — Low Quality Image Placeholder), des SVG colorés, ou simplement rien du tout. Quand l'image réelle se charge, elle remplace le placeholder.
Le problème survient quand le remplacement du placeholder par l'image modifie les dimensions de l'élément. C'est le fameux Cumulative Layout Shift (CLS) — un décalage visible qui déplace les éléments environnants, souvent mentionné dans les articles sur l'impact SEO des bugs visuels. Si votre screenshot est pris pendant ce décalage, vous capturez un état transitoire qui n'est ni le placeholder ni l'état final.
Les bonnes pratiques web recommandent de définir des dimensions explicites sur les images (width et height en HTML) pour éviter le layout shift. Mais toutes les équipes ne suivent pas ces bonnes pratiques, et les images responsive avec des dimensions variables rendent la chose plus complexe.
L'infinite scroll : une page sans fin
L'infinite scroll pousse le problème du lazy loading à l'extrême. Au lieu d'une page de taille fixe avec du contenu différé, vous avez une page dont la longueur est potentiellement infinie. Chaque scroll vers le bas charge de nouveaux éléments et allonge la page.
Comment testez-vous visuellement une page sans fin ? Vous ne pouvez pas capturer un screenshot full-page — la page n'a pas de "full." Vous devez décider arbitrairement quand arrêter de scroller, combien d'éléments constitue un échantillon suffisant, et comment gérer le fait que le contenu chargé par l'infinite scroll est souvent alimenté par des données qui changent (nouveaux articles, nouvelles publications, nouveaux produits).
L'infinite scroll crée aussi un problème de mémoire. Chaque lot de contenu chargé ajoute des éléments au DOM. Après suffisamment de scrolls, le navigateur peut ralentir, le rendu peut devenir moins fluide, et le timing des opérations peut varier — introduisant du non-déterminisme dans vos tests.
Les stratégies pour tester visuellement le contenu en lazy loading
Stratégie 1 : le scroll incrémental avec captures multiples
Au lieu de chercher un screenshot unique de toute la page, découpez la page en segments et capturez chaque segment séparément. Scrollez de la hauteur d'un viewport, attendez que le contenu différé se charge, capturez un screenshot, puis continuez.
Cette approche produit une série de screenshots — viewport 1, viewport 2, viewport 3, etc. — que vous comparez individuellement à leurs baselines respectives. Chaque screenshot couvre un segment spécifique de la page avec tout le contenu chargé.
L'avantage est que vous obtenez une couverture complète avec du contenu entièrement chargé. L'inconvénient est la multiplicité des baselines à maintenir et la gestion du timing entre chaque scroll et chaque capture. Le temps de stabilisation après le scroll — le temps que les images chargent, que les animations de transition s'achèvent, que le layout se stabilise — doit être suffisant mais pas excessif.
Pour l'infinite scroll, définissez un nombre fixe de scrolls (par exemple 5 ou 10) et testez les segments correspondants. Vous ne pouvez pas tester l'infini, mais vous pouvez tester un échantillon représentatif.
Stratégie 2 : forcer le chargement complet avant la capture
Certains outils permettent de désactiver le lazy loading dans l'environnement de test. L'attribut HTML loading="eager" force le chargement immédiat de toutes les images. Les scripts Intersection Observer peuvent être patchés pour considérer que tous les éléments sont visibles immédiatement. Les frameworks comme React et Vue qui implémentent le lazy loading au niveau composant peuvent être configurés pour charger tous les composants en mode test.
Cette approche transforme votre page en lazy-loaded en une page complètement chargée, et vous pouvez capturer un screenshot full-page classique. C'est simple, direct, et ça résout le problème de couverture.
Mais vous ne testez plus le lazy loading lui-même. Si votre implémentation de lazy loading a un bug — un composant qui ne se charge jamais, un placeholder qui reste affiché, une animation de transition qui casse le layout — vous ne le verrez pas en mode "eager". Vous testez le contenu, pas le mécanisme de chargement.
C'est un compromis acceptable si votre objectif est uniquement de détecter les régressions visuelles dans le contenu. Si vous voulez aussi vérifier que le lazy loading fonctionne correctement, vous avez besoin de la stratégie suivante.
Stratégie 3 : tester les états de transition
Au lieu de contourner le lazy loading, testez-le explicitement. Capturez des screenshots à chaque étape du cycle de chargement : l'état initial avec les placeholders, l'état pendant le chargement (transition), et l'état final avec le contenu complet.
Chaque état a sa propre baseline. Le test de l'état initial vérifie que les placeholders sont correctement dimensionnés et positionnés. Le test de l'état final vérifie que le contenu chargé remplace correctement les placeholders sans casser le layout. Le test de transition vérifie qu'il n'y a pas de layout shift excessif.
Cette approche est la plus complète mais aussi la plus lourde à maintenir. Trois baselines par composant en lazy loading, c'est trois fois plus de maintenance quand le design évolue. Réservez-la aux composants critiques où le comportement du lazy loading est essentiel à l'expérience utilisateur.
Stratégie 4 : la comparaison structurelle, indifférente au contenu pixel
L'approche structurelle résout élégamment plusieurs problèmes du lazy loading simultanément. Au lieu de comparer les pixels d'un placeholder et les pixels de l'image finale, elle compare la structure de l'élément : sa position dans le DOM, ses dimensions calculées, ses propriétés CSS, sa visibilité.
Un placeholder correctement dimensionné occupe le même espace que l'image finale — la structure est identique même si les pixels sont complètement différents. Un composant en lazy loading qui se charge correctement conserve la même position et les mêmes dimensions que son placeholder. L'approche structurelle valide cette équivalence sans se soucier du contenu pixel des images.
C'est l'approche que Delta-QA utilise nativement. Quand un placeholder de 400x300 pixels est remplacé par une image de 400x300 pixels, la structure ne change pas — pas d'alerte. Quand un placeholder de 400x300 est remplacé par une image de 400x200 (un bug dans le ratio d'aspect), la structure change — alerte légitime.
Les défis spécifiques de l'infinite scroll
L'infinite scroll mérite une attention particulière parce qu'il combine les problèmes du lazy loading avec des défis qui lui sont propres.
Le problème de la répétabilité
L'infinite scroll charge généralement du contenu paginé depuis une API. Le contenu de la page 2 dépend de ce qui est en page 1. Si le jeu de données change entre deux exécutions de test (un nouvel article publié, un produit retiré), les pages n'ont pas le même contenu, et la comparaison échoue.
Pour obtenir des résultats répétables, vous devez figer les données sous-jacentes. Utilisez une API mockée qui retourne toujours les mêmes données dans le même ordre, ou testez contre un environnement de staging avec un jeu de données fixe.
Le problème du rendu des marges et du regroupement
Les listes à infinite scroll affichent souvent du contenu avec des en-têtes de regroupement — "Aujourd'hui", "Hier", "La semaine dernière." Ces en-têtes dépendent de la date courante et changent d'un jour à l'autre. Un article publié "aujourd'hui" sera sous l'en-tête "Hier" demain.
La solution est la même que pour tout contenu temporel : figez la date système dans l'environnement de test.
Le problème de la performance dégradée
Après 20 ou 30 scrolls successifs, la performance du navigateur peut se dégrader à cause du nombre d'éléments dans le DOM. Cette dégradation affecte le timing du rendu et peut introduire du non-déterminisme dans vos screenshots.
Les applications bien conçues implémentent la virtualisation — elles ne gardent dans le DOM que les éléments actuellement visibles, recyclant les nœuds DOM au fur et à mesure du scroll. Si votre application virtualise le DOM, le nombre d'éléments reste constant quel que soit le nombre de scrolls, et la performance reste stable.
Si votre application n'utilise pas la virtualisation, limitez le nombre de scrolls dans vos tests pour rester dans la zone de performance acceptable.
Recommandations pratiques pour intégrer le lazy loading dans votre stratégie de test visuel
Pour les images en lazy loading, le minimum est de tester l'état final — l'état où toutes les images visibles dans le viewport sont chargées. Utilisez le scroll incrémental pour déclencher le chargement, attendez la stabilisation, et capturez. Définissez des attentes claires : toutes les images du viewport doivent être chargées (pas de placeholders visibles), et aucun layout shift ne doit se produire après le chargement.
Pour les composants en lazy loading (code splitting, dynamic imports), testez dans deux modes : le mode "tout chargé" pour vérifier le rendu des composants eux-mêmes, et le mode "chargement naturel" pour vérifier les états de transition et les fallbacks.
Pour l'infinite scroll, définissez un périmètre de test réaliste. Testez les 3 à 5 premiers chargements (scrolls), ce qui couvre le comportement initial, la logique de pagination, et la transition entre les lots. Ne cherchez pas à tester l'intégralité du flux — ce n'est ni pratique ni nécessaire.
Pour les placeholders, testez-les explicitement. Les placeholders font partie de l'expérience utilisateur — un placeholder mal dimensionné cause du layout shift, un placeholder manquant laisse un trou blanc dans la page. Capturez un screenshot de l'état initial (avant le scroll) et vérifiez que les placeholders sont correctement dimensionnés et positionnés.
Pour le timing, privilégiez les attentes conditionnelles aux délais fixes. Attendez que les images soient chargées (via l'événement load sur les éléments img) plutôt que d'attendre un nombre arbitraire de secondes. Les délais fixes sont fragiles — 2 secondes peuvent suffire en local et être insuffisantes en CI sous charge.
Le lazy loading est un allié, pas un ennemi
Le lazy loading optimise la performance de votre site. Il réduit le temps de chargement initial, la consommation de bande passante, et l'utilisation de ressources côté client. Ce sont des bénéfices réels et mesurables pour vos utilisateurs.
Le fait qu'il complique le test visuel n'est pas une raison pour l'abandonner — c'est une raison pour adapter votre stratégie de test. Et les outils modernes de test visuel, Delta-QA en tête, sont conçus pour gérer cette complexité sans que vous ayez à choisir entre performance et testabilité.
Le lazy loading n'est pas un obstacle au test visuel. C'est une contrainte technique avec des solutions techniques. Mettez-les en place, et vous aurez le meilleur des deux mondes : des pages rapides et des tests fiables.
FAQ
Le lazy loading rend-il le test visuel full-page impossible ?
Non, mais il nécessite une approche différente du screenshot full-page classique. Soit vous forcez le chargement complet (loading="eager") avant la capture, soit vous scrollez progressivement en capturant chaque segment séparément. Les deux approches offrent une couverture complète — la première est plus simple, la seconde est plus fidèle au comportement réel de la page.
Comment tester visuellement une page avec infinite scroll ?
Définissez un périmètre de test réaliste : 3 à 5 scrolls couvrent le comportement initial, la logique de pagination, et les transitions entre lots. Utilisez des données mockées pour garantir la répétabilité. Capturez chaque segment comme un screenshot indépendant avec sa propre baseline. Ne cherchez pas à tester l'infini — testez un échantillon représentatif et fiable.
Faut-il désactiver le lazy loading dans l'environnement de test ?
Cela dépend de votre objectif. Si vous testez le contenu (détecter les régressions visuelles dans le design), désactivez le lazy loading pour simplifier les captures. Si vous testez le mécanisme de chargement (vérifier que les placeholders, les transitions et le chargement différé fonctionnent), gardez le lazy loading activé et testez les différents états explicitement.
Comment gérer le layout shift causé par le chargement différé des images ?
Définissez toujours des dimensions explicites (width et height) sur vos images pour réserver l'espace dans le layout. Utilisez des placeholders de même taille que l'image finale (LQIP ou rectangles colorés). Testez visuellement l'état initial (avec placeholders) et l'état final (avec images) pour vérifier que les dimensions ne changent pas et qu'aucun décalage ne se produit.
Les tests visuels en lazy loading sont-ils plus lents que les tests classiques ?
Oui, nécessairement. Le scroll incrémental avec des attentes de chargement à chaque étape prend plus de temps qu'une capture instantanée d'une page entièrement chargée. C'est le coût de la couverture complète. Optimisez en parallélisant vos tests, en limitant le nombre de scrolls au strict nécessaire, et en utilisant des attentes conditionnelles plutôt que des délais fixes pour minimiser le temps d'attente.
Delta-QA gère-t-il le lazy loading et l'infinite scroll ?
Oui. L'approche structurelle de Delta-QA est particulièrement adaptée au lazy loading parce qu'elle compare la structure plutôt que les pixels. Un placeholder correctement dimensionné et l'image finale ont la même structure — pas de faux positif. L'outil gère le scroll incrémental, les attentes de chargement, et la comparaison par segments, le tout sans écrire une ligne de code.