En bref : retard de rendu
- Le retard de rendu est l’intervalle entre la réception du HTML par le navigateur et l’affichage de la page terminée à l’utilisateur. Sur presque tous les sites modernes, il est dominé par l’exécution JavaScript, pas par le transit réseau.
- Le principal coupable est le JavaScript tiers synchrone chargé dans le head : tag manager, outils d’analyse et widgets de chat qui empêchent l’arbre de rendu de se commiter.
- Les métriques Web Vitals (LCP, FID, INP) mesurent les symptômes observables, mais elles ne vous disent pas quel script précis ralentit votre page. Le suivi en session du temps d’exécution des scripts, lui, le fait.
Si vous avez déjà visité une page web moderne, vous aurez sans doute remarqué que certains éléments à l’écran (comme les images, les champs de saisie, etc.) se chargent avant d’autres parties du site. Les pages web se chargent souvent par étapes, certains éléments n’apparaissant qu’après un délai initial. Cet étalement peut être intentionnel, pour améliorer les performances du site, mais il peut aussi n’être qu’un simple effet secondaire de la façon dont votre navigateur traite la page.
Si la partie lente est le téléchargement lui-même, vérifiez l’unité avant de comparer les chiffres. Un navigateur affichant des MB/s et une offre internet vendue en Mbps utilisent des unités différentes ; Mbps, Mb/s et MB/s nécessitent une conversion de 8 pour 1.
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 tout avidement d’un coup (ce qui peut engorger votre navigateur avec un tas de requêtes), votre navigateur attendra de charger le contenu hors écran jusqu’à ce que l’utilisateur fasse défiler à proximité. En ne chargeant pas tout ce contenu à chaque fois, le chargement initial de la page est bien plus rapide et semble plus léger.
Par exemple, cet article de blog pourrait charger notre bannière du haut et l’icône de l’auteur en premier, mais retarder le chargement des images situées près du pied de page jusqu’à ce que vous fassiez défiler jusqu’à elles. Cela accélère le chargement initial, puisque seule la première image se charge.
Du point de vue de l’expérience utilisateur, le chargement différé est clairement bénéfique : vous voyez les éléments importants plus rapidement, et votre bande passante n’est pas gaspillée sur des images et des vidéos que l’utilisateur ne verra peut-être jamais. Cela améliore le First Contentful Paint de la page, une métrique du navigateur utilisée pour mesurer la rapidité d’apparition du premier élément à l’écran.
Il peut exister des implémentations négatives du chargement différé, et cela dépend en fin de compte du développeur de la page de s’assurer qu’il l’utilise correctement. Par exemple, tout contenu situé au-dessus de la ligne de flottaison (c’est-à-dire tout contenu visible sans faire défiler 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 survient lorsque l’espace d’une image n’est pas réservé sur la page et que celle-ci se charge plus tard, repoussant tout le contenu vers le bas.
Rendu côté client et hydratation
Les applications web modernes reposent aujourd’hui principalement sur JavaScript, 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 envoie une page HTML très minimale, puis attend que le navigateur génère le contenu. Cela signifie qu’au premier chargement d’une page, vous pourriez ne voir qu’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. La métrique First Contentful Paint dont nous avons parlé plus haut peut être considérablement retardée dans une situation de CSR pur, car rien de significatif n’apparaît sur la page avant bien plus longtemps.
Résoudre ce problème avec le rendu côté serveur
Pour atténuer certains des délais d’attente du rendu côté client, de nombreux frameworks web utilisent le rendu côté serveur (SSR). Cela signifie qu’un serveur envoie une page web entièrement développée à votre navigateur (vous voyez donc immédiatement du contenu), puis l’hydrate ensuite avec des éléments plus interactifs.
L’hydratation nécessite toujours de générer ce contenu côté navigateur, mais elle signifie simplement que vos utilisateurs ne regardent pas un écran vide entre-temps. Cela améliore ainsi la performance perçue de votre page et évite de se demander « pourquoi cette page est-elle si lente ? ».
Cela dit, le SSR et l’hydratation peuvent tout de même introduire des problèmes sur un site s’ils ne sont pas implémentés correctement. Le problème du scintillement de contenu survient lorsque le serveur ne connaît pas l’utilisateur ni le contexte qu’il possède déjà (par exemple, s’il est déjà connecté ou non), et lui présente en conséquence une version générique du site. Une fois le site hydraté et une fois qu’il a détecté que l’utilisateur est connecté, il peut remplacer certaines parties de l’interface par du contenu personnalisé ou mis à jour. Bien que moins gênants qu’une page entièrement vide, ces changements de contenu en cours de route peuvent distraire et momentanément désorienter l’utilisateur.
Du point de vue de l’expérience utilisateur, l’objectif est de minimiser le délai avant que les utilisateurs ne voient un contenu utile. Si vous utilisez le CSR, gardez votre JavaScript léger et incluez un indicateur de chargement ou un squelette bien conçu, afin que vos utilisateurs sachent qu’un contenu est en chemin. Mieux encore, utiliser le SSR pour la vue initiale garantit que les utilisateurs voient d’abord quelque chose, puis reçoivent leur contenu ensuite.
Voyez-le sur votre propre site
Le retard de rendu est souvent attribué à la latence réseau, mais la véritable cause sur les sites modernes est le JavaScript tiers non audité qui bloque le chemin de rendu. cside montre exactement quels scripts ralentissent votre page dans chaque session utilisateur réelle. Offre gratuite disponible.
Ressources bloquant le rendu
Tous les retards ne sont pas dus à des scripts ; ils peuvent aussi provenir de la façon dont votre navigateur gère des ressources critiques comme le CSS et les polices. Les navigateurs ne savent pas toujours prioriser ces éléments d’eux-mêmes, ou peuvent ne réaliser que le contenu est stylisé que plus tard, ce qui provoque un scintillement du contenu avec la mauvaise police ou le mauvais style.
Le CSS est le cas le plus classique des problèmes de blocage du rendu. Habituellement, les navigateurs retardent 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 volumineux ou trop complexe, tout élément qui en dépend apparaîtra tardivement, une fois le fichier chargé. Garder un CSS optimisé et une mise en page de base en place permet au contenu de s’afficher plus tôt et améliore le temps de chargement perçu par l’utilisateur.
La police d’un site peut également retarder l’apparition du texte, mais souvent de manière plus subtile. Lorsqu’un site utilise une police personnalisée (via @font-face, ou un service comme Google Fonts), les navigateurs la gèrent avec précaution pour éviter qu’une police de secours n’apparaisse. Les navigateurs ont implémenté « le flash de texte invisible », ce qui signifie que le texte est masqué jusqu’à ce que le fichier de police soit chargé. Le texte est en réalité déjà présent sur la page, vous ne pouvez simplement pas le voir. Et si votre police met trop de temps à charger, l’utilisateur ne verra aucun mot du tout.
Équilibrer performance et expérience
Les développeurs web doivent viser à offrir la page la plus rapide possible, sans surprendre 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 de l’être, et ce délai devrait être géré dans l’interface à l’aide d’indicateurs de chargement et d’espaces réservés.
