Chargement différé sans pages cassées

Décidez ce qui est nécessaire maintenant, pas ce qui apparaît tôt dans le markup

Le chargement différé marque une ressource comme non critique tant qu’elle n’est pas nécessaire. Classez les ressources selon le parcours réel : essentiels de la première vue, médias sous le fold, embeds optionnels et code pour une route ou un panneau ultérieur. La position dans le CMS n’est pas une preuve suffisante ; une image peut être hors écran dans un template et centrale dans un autre.

Examinez les chargements à froid sur un petit téléphone et sur un bureau typique. Testez aussi les liens de campagne et les ancres dans la page, qui peuvent amener un visiteur plus bas dans la page. Cette revue indique ce qui doit être prêt sans déclenchement par défilement.

Protégez le hero et la fenêtre visible initiale

Ne mettez pas en lazy loading le contenu susceptible d’être visible à l’ouverture de la page. Google met en garde contre cette pratique, et l’analyse de web.dev montre que le lazy-loading des images de la fenêtre initiale peut retarder le LCP. L’élément LCP peut être un hero, une image produit, un poster ou du texte ; vérifiez-le sur chaque template important au lieu de supposer.

Chargez de manière eager une image confirmée comme LCP. Si les tests montrent qu’une image critique perd de la priorité réseau, essayez un hint de fetch-priority élevé. C’est un indice, pas un ordre. Une image d’arrière-plan critique définie via CSS peut nécessiter un preload précoce parce que le parser ne la découvre pas directement ; mesurez ce cas.

Réservez l’espace avant l’arrivée des médias

Le Cumulative Layout Shift (CLS) est le déplacement inattendu du contenu visible. Une image différée sans hauteur connue peut pousser le texte et les contrôles après que le lecteur ait commencé à parcourir ou atteint un bouton. C’est un risque d’interaction, pas seulement un problème de métrique.

Fournissez des attributs width et height précis pour les images et vidéos, ou réservez la forme avec CSS aspect-ratio. Utilisez un placeholder ayant l’empreinte finale du composant. Pour une iframe tierce, réservez sa hauteur et affichez un état clair de chargement ou d’indisponibilité.

Conservez la découvrabilité du contenu et la compréhensibilité des interactions

Google Search Central indique que Google n’interagit pas avec les pages en faisant défiler ou en cliquant. Le contenu important mis en lazy loading doit se charger lorsqu’il devient visible, et le HTML rendu doit exposer le contenu attendu ou les URLs média. Inspectez des pages représentatives dans Search Console après implémentation.

Une liste infinie indexable nécessite une route paginée pour chaque segment durable : une URL unique persistante, un contenu stable à cette URL et des liens à travers la séquence. Cela crée aussi un emplacement partageable auquel les utilisateurs peuvent revenir.

Quand une action révèle du contenu, gardez le contrôle accessible au clavier et rendez le résultat compréhensible. Pour une mise à jour significative non focalisée, comme « résultats chargés », exposez l’état de façon programmatique afin que les technologies d’assistance puissent l’annoncer sans déplacer le focus.

Utilisez le mécanisme le moins fragile

Pour les images et iframes hors écran ordinaires, le lazy loading natif du navigateur est généralement le point de départ le plus simple. Le navigateur décide quand démarrer une requête proche de la fenêtre visible ; cette distance n’est pas une garantie. L’événement window load peut se déclencher alors que des ressources lazy sont encore incomplètes.

Utilisez un Intersection Observer quand un composant nommé nécessite une activation personnalisée, par exemple pour monter un panneau coûteux peu avant son apparition. Gardez l’observateur limité et commencez le travail suffisamment tôt pour couvrir un défilement rapide. Utilisez le code splitting pour des routes non initiales ou des fonctionnalités optionnelles, et non comme prétexte pour retarder la tâche courante.

Mesurez, déployez et remédiez ensemble

Comparez un baseline et un candidat sur les mêmes URLs, état du cache, viewport et parcours utilisateur. Utilisez des tests mobiles à froid et contraints ainsi que des vérifications sur appareil réel quand c’est possible. Enregistrez LCP, séquence visible, décalages de mise en page, erreurs média, HTML rendu et actions essentielles. Les données de terrain complètent les tests en laboratoire.

Déployez un changement réversible et limité au template. Enregistrez les assets déplacés d’eager à deferred, la référence de déploiement, l’action de cache, le propriétaire et la première étape de rollback. Si un LCP devient lazy ou si un parcours de conversion devient incomplet, retirez la règle pour cet asset critique et vérifiez de nouveau. Recontrôlez après tout changement de thème, CMS, service d’image, tag ou embed.