La ressource la plus rapide et la mieux optimisée est une ressource qui n'est pas envoyée. Vous devez éliminer les ressources inutiles de votre application. C'est une bonne pratique de remettre en question et de revoir régulièrement les hypothèses implicites et explicites avec votre équipe. Voici quelques exemples :
- Vous avez toujours inclus la ressource X sur vos pages, mais le coût de son téléchargement et de son affichage compense-t-il la valeur qu'elle offre à l'utilisateur ? Pouvez-vous mesurer et prouver sa valeur ?
- La ressource (en particulier s'il s'agit d'une ressource tierce) offre-t-elle des performances constantes ? Cette ressource se trouve-t-elle dans le chemin critique, ou doit-elle l'être ? Si la ressource se trouve dans le chemin critique, pourrait-elle constituer un point de défaillance unique pour le site ? Autrement dit, si la ressource n'est pas disponible, cela affecte-t-il les performances et l'expérience utilisateur de vos pages ?
- Cette ressource nécessite-t-elle ou fait-elle l'objet d'un contrat de niveau de service ? Cette ressource respecte-t-elle les bonnes pratiques en matière de performances: compression, mise en cache, etc. ?
Trop souvent, les pages contiennent des ressources inutiles, ou pire, qui nuisent aux performances de la page sans apporter beaucoup de valeur au visiteur ou au site sur lequel elles sont hébergées. Cela s'applique également aux ressources et widgets propriétaires et tiers:
- Le site A a décidé d'afficher un carrousel de photos sur sa page d'accueil pour permettre au visiteur de prévisualiser plusieurs photos d'un simple clic. Toutes les photos sont chargées en même temps que la page, et l'utilisateur les fait défiler.
- Question:Avez-vous mesuré le nombre d'utilisateurs qui affichent plusieurs photos dans le carrousel ? Le téléchargement de ressources que la plupart des visiteurs ne consultent peut-être jamais peut engendrer des frais généraux élevés.
- Le site B a décidé d'installer un widget tiers pour afficher du contenu associé, améliorer l'engagement sur les réseaux sociaux ou fournir un autre service.
- Question:Avez-vous suivi le nombre de visiteurs qui utilisent le widget ou cliquent sur le contenu qu'il fournit ? L'engagement généré par ce widget est-il suffisant pour justifier sa surcharge ? En outre, pouvez-vous utiliser une stratégie de chargement pour vous assurer que le script n'est pas chargé tant que vous n'en avez pas besoin ?
Déterminer s'il faut éliminer les téléchargements inutiles demande souvent une réflexion et des mesures minutieuses. Pour obtenir de meilleurs résultats, procédez à un inventaire régulier et révisez ces questions pour chaque élément de vos pages.
Effets sur les métriques Core Web Vitals
L'initiative Core Web Vitals a été lancée par Google pour fournir un ensemble de métriques reflétant ce que vivent les utilisateurs lorsqu'ils naviguent sur le Web. Bien qu'il existe de nombreuses stratégies d'optimisation pour les métriques Core Web Vitals, se demander si une ressource donnée doit être chargée sur une page peut vous indiquer comment améliorer ces métriques sur votre site Web. Vous trouverez ci-dessous quelques exemples, regroupés par métrique Core Web Vitals, qui méritent d'être examinés. Bien que cette liste d'exemples ne soit pas exhaustive (et il y en a beaucoup !), la lecture des exemples peut vous donner à réfléchir.
Largest Contentful Paint (LCP)
La métrique Largest Contentful Paint (LCP) mesure le moment où le contenu le plus volumineux (par exemple, une image héros ou un titre) est chargé. Il s'agit d'une métrique perceptuelle importante, qui donne à l'utilisateur l'impression qu'un site se charge rapidement.
En général, moins de ressources sont téléchargées, ce qui signifie que la bande passante dont dispose l'utilisateur est allouée à moins de ressources, ce qui peut se traduire par une amélioration du LCP. Un exemple classique est le chargement différé, dans lequel les images situées en dehors de la fenêtre d'affichage pendant le chargement de la page ne sont téléchargées que lorsque le navigateur détermine que l'utilisateur est plus susceptible de les voir. Si vous disposez d'une galerie de vignettes de grande taille, par exemple, avec 50 images, le chargement différé permet au navigateur d'utiliser plus efficacement la bande passante disponible et d'utiliser le chargement différé à l'exception des 10 premières. Les premières images que l'utilisateur voit se chargent plus rapidement.
Cependant, il ne s'agit pas nécessairement de charger moins d'images. Le navigateur dispose d'un schéma de priorisation interne qui détermine la quantité de bande passante que chaque ressource doit recevoir. Toutefois, même avec cela, toutes les ressources (en particulier celles téléchargées à une priorité élevée) risquent de priver une ressource dépendante d'un élément LCP potentiel. Cela est particulièrement vrai lorsque les connexions réseau sont lentes. Cette ressource dépendante peut être un fichier image qui représente l'élément LCP de la page, mais il peut également s'agir d'une ressource de police Web dont le navigateur a besoin pour afficher un nœud de texte pouvant être déterminé comme l'élément LCP de la page.
Si votre site Web comporte beaucoup de texte, il se peut que l'élément LCP d'une page soit un nœud de texte. Bien qu'il existe de nombreuses stratégies d'optimisation et de chargement de police efficaces, il peut être utile de déterminer si une police système est suffisante pour les besoins de votre site Web, afin que les éléments LCP, qui sont des nœuds de texte, puissent se charger sans dépendre d'une ressource de police Web et être peints presque immédiatement à mesure que le CSS et le HTML arrivent du serveur.
Cumulative Layout Shift (CLS)
Chaque ressource que vous chargez peut contribuer au CLS (Cumulative Layout Shift) d'une page, en particulier si le téléchargement n'est pas terminé au moment de l'application initiale du dessin. Pour les images, le CLS implique des pratiques telles que la définition de dimensions explicites. Pour les polices, gérer le chargement des polices et éventuellement la correspondance des polices de remplacement peut minimiser les décalages lors de la période de remplacement d'une police Web. Pour JavaScript, il peut s'agir de gérer la façon dont le script manipule le DOM afin de réduire les décalages de mise en page à une quantité acceptable.
Chaque ressource qui contribue au CLS d'une page nécessite un certain travail pour s'assurer que la mise en page est suffisamment stable. En vous demandant si vous avez besoin ou non d'une ressource spécifique, vous n'accélérez pas seulement le chargement des pages, vous réduisez également les efforts cognitifs nécessaires pour préserver la stabilité de la mise en page. L'expérience utilisateur sera ainsi beaucoup moins frustrante et l'expérience développeur sera moins frustrante, car vous aurez plus de temps pour vous concentrer sur d'autres objectifs dans vos projets.
Interaction to Next Paint (INP, Interaction to Next Paint)
L'Interaction to Next Paint (INP) mesure la réactivité aux entrées de l'utilisateur tout au long de la durée de vie d'une page. L'INP d'une page peut être grandement influencée par le code JavaScript qu'elle charge, car ce langage est celui qui génère la plupart des interactions sur le Web. En particulier, la quantité de ressources de script téléchargées lors du chargement de la page peut entraîner des tâches potentiellement coûteuses liées à l'évaluation et la compilation des scripts. Moins vous chargez de code JavaScript au démarrage, moins le navigateur doit effectuer des tâches à ce stade critique de l'expérience sur la page, où les utilisateurs peuvent essayer d'interagir avec.
Bien qu'il existe des stratégies pour réduire la taille des ressources JavaScript téléchargées au démarrage, telles que le fractionnement du code et le tremblement d'arborescence, il est utile de vérifier les packages que vous utilisez dans vos projets pour voir s'ils sont nécessaires. Par exemple, lodash propose de nombreuses méthodes encore utiles aujourd'hui, mais est fourni avec des méthodes prêtes à l'emploi, telles que les fonctions spécifiques à Array
pour le mappage, la réduction et le filtrage, et beaucoup d'autres.
L'amélioration progressive est également une approche utile de JavaScript, car elle vous permet de proposer une expérience de base (mais toujours fonctionnelle) aux utilisateurs qui disposent d'appareils plus puissants et de connexions réseau plus rapides. Que vous adhériez ou non au principe de l'amélioration progressive, le point reste le même: chaque ressource JavaScript que vous pouvez éviter de télécharger peut offrir une expérience qui répond plus rapidement aux interactions des utilisateurs, ce qui constitue un aspect essentiel des performances Web.
Conclusion
Le fait d'effectuer un audit des téléchargements inutiles sur votre site Web n'est peut-être qu'un aspect parmi d'autres qui permet d'offrir une expérience utilisateur rapide, mais il présente un fort potentiel d'impact. En résumé :
- Dressez l'inventaire de vos propres éléments et des éléments tiers sur vos pages.
- Mesurez les performances de chaque composant: sa valeur et ses performances techniques.
- Déterminer si les ressources apportent une valeur suffisante
- comprendre l'effet des téléchargements inutiles sur les Core Web Vitals et les métriques associées ;
En optimisant l'efficacité du contenu de cette manière, vous améliorez non seulement les performances globales, mais aussi de ne pas gaspiller la bande passante des utilisateurs. Vous pouvez également améliorer les métriques axées sur les utilisateurs et leur offrir une meilleure expérience.