Si vous avez déjà visité n’importe quelle page web moderne, vous remarquerez que parfois les choses à l’écran (comme les images, les éléments d’entrée, etc.) se chargeront avant d’autres parties du site. Les pages web se chargeront souvent par étapes, certaines choses n’apparaissant qu’après un délai initial. Cette échelonnement peut en fait être intentionnel pour améliorer les performances du site, mais pourrait aussi être juste un effet secondaire de la façon dont votre navigateur traite la page.
Chargement Différé
Le chargement différé est une technique utilisée par les développeurs web pour retarder le chargement de choses non importantes sur la page. Des choses comme les images, les vidéos et le contenu intégré se chargent généralement en dernier, ou jusqu’à ce qu’ils soient réellement nécessaires à la page. Au lieu de charger avidement tout à la fois (ce qui peut obstruer votre navigateur avec un tas de requêtes), votre navigateur attendra pour charger le contenu hors écran jusqu’à ce que l’utilisateur fasse défiler près de lui. En ne chargeant pas tout ce contenu, à chaque fois, le chargement initial de la page est beaucoup plus rapide et se sent plus léger, améliorant la perception des performances.
Par exemple, cet article de blog pourrait charger notre bannière supérieure et l’icône d’auteur en premier, mais retarder le chargement des images près du pied de page du site jusqu’à ce que vous fassiez défiler jusqu’à lui. Cela accélère le chargement initial, car seule la première image se charge.
Du côté de l’expérience utilisateur, le chargement différé est clairement bénéfique : vous voyez les choses critiques et importantes plus rapidement, et votre bande passante n’est pas gaspillée sur des images et vidéos que l’utilisateur ne verra peut-être jamais en premier lieu. Cela améliore la Première Peinture de Contenu de la page, qui est une métrique du navigateur utilisée pour chronométrer la rapidité avec laquelle le premier élément apparaît à l’écran.
Il peut y avoir des implémentations négatives du chargement différé, et cela dépend finalement du développeur de la page de s’assurer qu’ils l’utilisent correctement. Par exemple, charger quoi que ce soit au-dessus du pli (qui est tout contenu visible sans faire défiler vers le bas de la page) ne devrait pas être chargé de manière différée. Une autre préoccupation est le décalage de mise en page, qui est lorsqu’un espace d’image n’est pas réservé sur la page et se charge plus tard, poussant tout le contenu vers le bas.
Rendu Côté Client et Hydratation
Les applications web modernes sont principalement JavaScript de nos jours, ce qui signifie que le contenu est souvent rendu puis affiché à l’utilisateur. Dans les frameworks de rendu côté client (CSR) comme React, Angular et Vue, le serveur enverra une page HTML très basique, puis attendra que le navigateur génère le contenu. Cela signifie qu’au premier chargement d’une page, vous pourriez juste voir un écran vide ou un indicateur de chargement pendant que le navigateur télécharge et génère le contenu.
Cette implémentation peut souvent conduire à une perception négative des performances de votre site, car les utilisateurs pourraient penser que rien ne se charge ou que cela prend trop de temps à charger en premier lieu. La métrique Première Peinture de Contenu dont nous avons parlé plus tôt pourrait être considérablement repoussée dans une situation CSR pure, car rien de significatif n’apparaît sur la page jusqu’à beaucoup, beaucoup plus tard.
Résoudre cela avec le Rendu Côté Serveur
Pour atténuer certains des délais d’attente du rendu côté client, de nombreux frameworks web utiliseront le Rendu Côté Serveur (SSR). Cela signifie qu’un serveur enverra une page web entièrement développée à votre navigateur (pour que vous voyiez le contenu immédiatement), puis l’hydratera plus tard avec des éléments plus interactifs.
L’hydratation nécessite toujours de générer ce contenu du navigateur côté client, mais cela signifie simplement que vos utilisateurs ne regardent pas un écran vide entre-temps. À son tour, cela améliore les performances perçues de votre page et mène à moins de pensées sur “pourquoi cette page est-elle si lente ?”.
Cela dit, SSR et l’hydratation peuvent encore introduire des problèmes à un site s’ils ne sont pas implémentés correctement. Le problème du scintillement du contenu est lorsque le serveur ne connaît pas l’utilisateur ou le contexte qu’il a déjà (comme, si un utilisateur est déjà connecté ou non), et en conséquence leur donnera une version générique du site. Une fois que le site est hydraté et réalise que l’utilisateur est connecté, il pourrait remplacer des parties de l’UI avec du contenu personnalisé ou mis à jour. Bien que pas aussi mauvais qu’une page complètement vide, ces changements de contenu à mi-parcours peuvent être distrayants et confondre momentanément l’utilisateur.
Du point de vue de l’expérience utilisateur, l’objectif est de minimiser le délai avant que les utilisateurs voient du contenu utile. Si vous utilisez CSR, il est essentiel de garder votre JavaScript mince et d’inclure un indicateur de chargement bien conçu ou un squelette pour que vos utilisateurs sachent qu’il y a du contenu en chemin. Encore mieux, utiliser SSR pour la vue initiale assure que les utilisateurs voient quelque chose en premier, et obtiennent leur contenu en second.
Ressources Bloquant les Rendu
Tous les retards ne sont pas dus aux scripts, et peuvent aussi être dus à la façon dont votre navigateur gère les ressources critiques comme CSS et les polices. Les navigateurs ne savent pas prioriser ces éléments de manière inhérente, ou pourraient ne pas réaliser que le contenu est stylisé jusqu’à plus tard, menant à ce que le contenu scintille sur votre page avec la mauvaise police ou le mauvais style.
CSS est le plus classique des problèmes de blocage de rendu. Habituellement, les navigateurs retarderont le rendu du contenu de la page jusqu’à ce que le CSS soit téléchargé et traité, mais si votre fichier CSS est trop grand ou trop complexe, tout élément qui dépend de ce fichier CSS apparaîtra tard jusqu’à ce qu’il soit chargé. S’assurer que votre CSS est optimisé et que le style de mise en page de base existe sur votre site assurera que le contenu s’affiche tôt, et améliorera le temps de chargement perçu de l’utilisateur.
La police d’un site peut également retarder l’apparition du texte, mais souvent de manières plus subtiles. Lorsqu’un site utilise une police personnalisée (via `@font-face`, ou quelque chose comme Google Fonts), les navigateurs les géreront soigneusement pour s’assurer qu’une police de secours n’apparaît pas. Les navigateurs ont implémenté “le flash de texte invisible”, ce qui signifie que le texte est caché jusqu’à ce que le fichier de police soit chargé. Le texte est essentiellement là, sur la page, vous ne pouvez tout simplement pas le voir. Et si votre police prend trop de temps à charger, l’utilisateur ne pourrait pas voir aucun mot, ne menant pas à une expérience idéale pour eux.
Équilibrer les Performances avec l’Expérience
En bref, il est toujours important pour les développeurs web de fournir la page la plus rapide, tout en ne surprenant pas l’utilisateur avec du contenu non stylisé, du texte manquant ou des temps de chargement longs. Chaque élément retardé sur une page devrait avoir une bonne raison d’être retardé, et le retard devrait être géré dans l’UI à travers des indicateurs de chargement et des espaces réservés.
En comprenant les raisons techniques derrière ces apparitions retardées, les développeurs peuvent prendre de meilleures décisions sur la façon dont ils veulent charger leur contenu et améliorer l’expérience pour leurs utilisateurs.
