La vitesse de chargement initial de votre site web ou application constitue la première interaction de vos visiteurs. Ce guide explore des approches éprouvées pour optimiser ce moment crucial et gagner de précieuses secondes lors du premier affichage de la page.
L’importance du temps de chargement initial
Le délai entre le moment où un utilisateur saisit l’adresse de votre site et celui où le contenu apparaît à l’écran représente les secondes les plus importantes pour faire une première impression réussie.
Une étude d’Amazon a révélé que chaque 100 millisecondes de latence entraînaient une baisse de 1% des ventes.
Pourtant, de nombreux développeurs web considèrent cette question comme secondaire. L’ajout constant de nouvelles fonctionnalités et de librairies engendre progressivement des pertes de conversion, souvent imperceptibles car les utilisateurs quittent la page avant que les outils de suivi n’aient le temps d’enregistrer les données.
Certaines optimisations se font côté front-end, d’autres côté back-end, mais dans tous les cas, il est crucial d’assurer un chargement rapide de l’application web.
Mettre en place les mesures appropriées
La première étape consiste à implémenter un système de suivi. Le processus de chargement se compose de nombreuses phases, et sans mesures précises, il est impossible d’identifier les points de blocage.
Voici les étapes clés du processus de chargement :
Mesures | Diagramme créé par Terrastruct
Cela signifie que vous devez surveiller les métriques pour chaque phase de ce schéma.
Voyons comment procéder.
Requête du navigateur à la réponse :
Mesurez ce temps sur votre serveur. Il faut mesurer le temps écoulé entre la réception de la requête par l’API et l’envoi de la réponse. Ce délai peut varier en fonction des appels externes vers des bases de données, par exemple, et peut constituer un goulet d’étranglement majeur.
Réponse envoyée à réponse reçue :
Cette mesure est plus difficile à obtenir. Une approche consiste à ajouter un horodatage au moment où la réponse quitte votre serveur, et de le comparer avec l’heure actuelle côté utilisateur, au plus tôt (idéalement via un script dans l’en-tête du code HTML).
Réponse reçue au premier affichage de contenu :
Le premier affichage de contenu désigne le moment où le premier élément apparaît dans le DOM. Il peut s’agir d’un simple texte, d’un fond ou d’un indicateur de chargement. Vous pouvez mesurer ce temps en utilisant Lighthouse, un outil intégré aux outils de développement de Chrome.
Premier affichage de contenu au plus grand affichage de contenu :
Le plus grand affichage de contenu correspond au moment où le plus grand élément est affiché dans la zone visible de l’utilisateur. C’est généralement la fin du rendu de la page, et l’utilisateur voit un écran rempli. Cette métrique est également mesurable via Lighthouse.
Plus grand affichage de contenu au temps d’interactivité :
Enfin, le temps d’interactivité indique quand l’utilisateur peut effectuer des actions (défilement, clics, saisie). Un délai important peut être frustrant car l’utilisateur voit la page, mais ne peut pas interagir avec elle. Lighthouse permet également de mesurer cette métrique.
Réduire le code
Une fois les mesures établies, vous pouvez entamer l’optimisation. Les optimisations impliquent des compromis, et les métriques vous aideront à déterminer lesquels sont pertinents.
La page la plus rapide à charger est une page vide. Néanmoins, une quantité importante de code peut être ajoutée avant qu’une différence de vitesse avec une page vide ne soit perçue. Les modifications sont parfois si infimes que l’on ne remarque pas les ralentissements, jusqu’à ce qu’ils deviennent flagrants. C’est alors qu’il devient crucial de réduire la taille du code.
La réduction du code apporte deux avantages majeurs :
- Le transfert de l’application sur le réseau est plus rapide.
- L’analyse du code par le navigateur est plus rapide.
Le premier avantage est modeste, car les requêtes sont compressées sur le réseau. La réduction de 1 Mo de code source n’engendrera qu’une économie de bande passante d’environ 10 ko. Cependant, l’accélération de l’analyse est significative. Les navigateurs et ordinateurs des utilisateurs varient en termes de puissance de calcul, et certains ne peuvent pas analyser le code aussi vite que votre propre machine.
Sur un appareil mobile, la puissance de calcul est encore plus limitée. La différence peut atteindre plusieurs secondes.
Plus le code est léger, plus le navigateur est en mesure d’analyser et d’exécuter rapidement votre application. Même un écran de chargement en Javascript nécessite l’analyse de ce code avant son affichage.
Il ne s’agit pas de supprimer des fonctionnalités, mais d’optimiser le code existant. Voici quelques bonnes pratiques pour y parvenir :
- Utiliser des minificateurs de code : Ces outils raccourcissent les noms de variables (par exemple, « signUpDarkModeButton » devient « ss »), suppriment les espaces et autres caractères inutiles, pour rendre le code aussi compact que possible, sans perte de fonctionnalité.
- Importer des parties spécifiques de librairies : Les librairies contiennent souvent des éléments inutiles. Si vous n’avez besoin que d’une fonction spécifique d’une librairie, importez uniquement le code nécessaire, plutôt que toute la librairie.
- Éliminer le code mort (« tree-shaking ») : Un code laissé à des fins de débogage ou suite à la suppression d’une fonctionnalité n’est pas exécuté. Des outils comme Webpack détectent et suppriment automatiquement ce code mort dans la version de production.
Découper le code en modules
Après avoir optimisé la taille du code global de votre application, il est possible d’aller plus loin et de réduire la quantité de code nécessaire pour le chargement initial.
Supposons que 20% de votre code servent une fonctionnalité accessible uniquement après plusieurs clics. Il est inutile de charger ce code au démarrage de la page. La division en modules peut grandement améliorer le temps d’interactivité.
Au lieu d’avoir un seul graphique d’importation imbriquée, identifiez les zones qui peuvent être séparées. Par exemple, un composant particulier pourrait charger des librairies lourdes. Isolez ce composant dans un fichier distinct, et importez-le uniquement lorsque l’utilisateur est sur le point d’interagir avec lui.
Des librairies facilitent le chargement différé de modules, selon le framework utilisé. Il n’est pas nécessaire de découper chaque composant, au risque de créer des temps d’attente à chaque interaction. Segmentez les blocs de code les plus importants.
Rendu côté serveur
Les navigateurs doivent effectuer des analyses et des compilations coûteuses en ressources, et de nombreux utilisateurs travaillent sur des appareils mobiles peu performants. Le rendu côté serveur permet de transférer une partie du travail des navigateurs vers les serveurs. Au lieu de renvoyer une page blanche que le Javascript devra remplir, vous pouvez utiliser un moteur Javascript côté serveur (comme Node.js) pour pré-remplir la page avec des données et du contenu.
Les serveurs sont généralement plus rapides et prévisibles que les navigateurs des utilisateurs. L’analyse de Javascript reste nécessaire pour l’interactivité de l’application. Le rendu côté serveur permet de fournir un contenu initial de sorte que l’utilisateur voie au moins un écran de chargement ou une barre de progression dès le chargement de la page.
De plus, si la vue initiale nécessite des données, le client n’a pas à effectuer de requête séparée, les données sont déjà présentes dans l’application.
Compresser les ressources
Les ressources (images, icônes, vidéos, etc.) donnent vie à une page. Une page ne semble pas complètement chargée tant que ces éléments n’ont pas fini de s’afficher. Ces ressources peuvent aussi modifier la mise en page, provoquant des sauts et des décalages pendant le chargement, frustrant l’utilisateur. Les ressources sont parfois les éléments les plus volumineux, et sont responsables du « plus grand affichage de contenu ».
Les ressources représentent souvent la partie la plus lourde d’une application. Une image peut peser plusieurs mégaoctets, et le chargement simultané de nombreuses icônes peut facilement dépasser la limite de requêtes réseau du navigateur, entraînant une longue file d’attente.
Il ne faut jamais télécharger une image depuis Internet pour l’afficher telle quelle. Les images doivent être redimensionnées à la plus petite dimension possible. Afficher un profil utilisateur dans un élément de 50 x 50 pixels en téléchargeant l’image en résolution écran, pour ensuite la réduire, est une perte de temps.
Ensuite, les images doivent être compressées en fonction de leur format. Webm est actuellement le format privilégié, mais l’optimisation de la compression sur le web est en constante évolution. Certains navigateurs peuvent ne pas prendre en charge les formats les plus récents. La technologie des navigateurs permet de charger le format supporté par chaque utilisateur.
Compressez donc les ressources dans un format récent et performant, mais conservez également une version plus ancienne, pour que tous les navigateurs puissent les afficher. Les éléments `img` et `video` prennent en charge les formats de secours.
Conclusion
Voici cinq techniques efficaces pour assurer un chargement initial ultra-rapide de votre application. Elles améliorent le taux de conversion, la satisfaction des utilisateurs, et même le référencement, car Google favorise les sites rapides. Chez Terrastruct, nous appliquons ces pratiques, et bien d’autres, pour que les diagrammes présentés dans cet article soient créés et affichés aussi rapidement que possible.