La ressource la plus rapide et la mieux optimisée est une ressource non envoyée. Vous devez éliminer les ressources inutiles de votre application. Il est recommandé de remettre en question et de réexaminer 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 apporte à 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 sur le chemin critique, ou doit-elle s'y trouver ? Si la ressource se trouve dans le chemin critique, pourrait-elle être un point de défaillance unique pour le site ? En d'autres termes, si la ressource n'est pas disponible, cela affecte-t-il les performances et l'expérience utilisateur de vos pages ?
- Cette ressource a-t-elle besoin d'un SLA ou en a-t-elle déjà un ? 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 aussi bien aux ressources et widgets propriétaires qu'aux ressources et widgets tiers :
- Le site A a décidé d'afficher un carrousel de photos sur sa page d'accueil pour permettre aux visiteurs de prévisualiser plusieurs photos en un clic. Toutes les photos sont chargées lorsque la page est chargée, et l'utilisateur fait défiler les photos.
- Question : Avez-vous mesuré le nombre d'utilisateurs qui consultent plusieurs photos dans le carrousel ? Vous risquez d'encourir des frais généraux élevés en téléchargeant des ressources que la plupart des visiteurs ne consultent jamais.
- 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 qui cliquent sur le contenu qu'il fournit ? L'engagement généré par ce widget est-il suffisant pour justifier sa surcharge ? De plus, pouvez-vous utiliser une stratégie de chargement pour vous assurer que le script n'est pas chargé tant qu'il n'est pas nécessaire ?
Pour déterminer s'il faut éliminer les téléchargements inutiles, il faut souvent réfléchir et mesurer attentivement. Pour obtenir de meilleurs résultats, inventoriez et réexaminez régulièrement ces questions pour chaque élément de vos pages.
Effets sur les Core Web Vitals
L'initiative Core Web Vitals a été lancée par Google pour fournir un ensemble de métriques reflétant l'expérience des utilisateurs lorsqu'ils naviguent sur le Web. Bien qu'il existe de nombreuses stratégies d'optimisation pour les métriques Core Web Vitals, vous demander s'il est nécessaire de charger une ressource particulière sur une page peut vous aider à améliorer ces métriques sur votre site Web. Voici quelques exemples, regroupés par Core Web Vital, qui méritent votre attention. Bien que cette liste d'exemples ne soit pas exhaustive (il en existe bien d'autres), elle peut vous donner matière à réflexion.
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 de perception importante qui donne à l'utilisateur l'impression qu'un site se charge rapidement.
En général, télécharger moins de ressources signifie que la bande passante dont dispose l'utilisateur sera répartie sur moins de ressources, ce qui peut se traduire par une amélioration du LCP. Un exemple classique est celui du chargement différé, où les images situées en dehors de la zone d'affichage lors du chargement de page ne sont pas téléchargées tant que le navigateur n'a pas déterminé que l'utilisateur est plus susceptible de les voir. Si vous disposez d'une grande galerie de miniatures, par exemple 50 images, le chargement différé de toutes les images, à l'exception des dix premières, permet au navigateur d'utiliser plus efficacement la bande passante disponible. Les premières images que l'utilisateur verra se chargeront plus rapidement.
Toutefois, 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 cette toutes les ressources, en particulier celles téléchargées avec une priorité élevée, peuvent priver une ressource dépendante d'un élément LCP potentiel. Cela est particulièrement vrai sur les connexions réseau lentes. Cette ressource dépendante peut être un fichier image représentant 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 contient beaucoup de texte, il est possible 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 des polices, 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 s'afficher presque immédiatement lorsque le CSS et le code HTML arrivent du serveur.
Cumulative Layout Shift (CLS)
Chaque ressource que vous chargez peut contribuer au Cumulative Layout Shift (CLS) d'une page, en particulier si elle n'a pas fini de se télécharger au moment de l'affichage initial. Pour les images, éviter le CLS implique des pratiques telles que la définition de dimensions explicites. Pour les polices, la gestion du chargement des polices et éventuellement la correspondance des polices de remplacement peuvent minimiser les décalages pendant la période d'échange d'une police Web. Pour JavaScript, il peut s'agir de gérer la façon dont ce script manipule le DOM afin de réduire les changements de mise en page à un niveau acceptable.
Chaque ressource qui contribue au CLS d'une page nécessite un certain travail pour garantir que la mise en page est suffisamment stable. En vous demandant si vous avez besoin d'une ressource spécifique, vous accélérez non seulement le chargement des pages, mais vous réduisez également l'effort cognitif nécessaire pour préserver la stabilité de la mise en page. Cela permet non seulement d'offrir une expérience utilisateur beaucoup moins frustrante, mais aussi une expérience de développement moins frustrante, car vous aurez plus de temps pour poursuivre d'autres objectifs dans vos projets.
Interaction to Next Paint (INP)
La métrique Interaction to Next Paint (INP) mesure la réactivité aux entrées utilisateur tout au long de la durée de vie d'une page. L'INP d'une page peut être fortement influencé par le code JavaScript qu'elle charge, car JavaScript est à l'origine de la majeure partie de l'interactivité sur le Web. En particulier, la quantité de ressources de script téléchargées lors du chargement de page peut lancer un travail potentiellement coûteux impliqué dans l'évaluation et la compilation du script. Moins vous chargez de code JavaScript au démarrage, moins le navigateur doit effectuer de travail à ce moment critique de l'expérience sur la page, où les utilisateurs peuvent essayer d'interagir avec elle.
Bien qu'il existe des stratégies pour réduire la taille des ressources JavaScript téléchargées au démarrage (comme la division du code et le tree shaking), il est utile d'auditer les packages que vous utilisez dans vos projets pour voir s'ils sont vraiment nécessaires. Par exemple, lodash propose de nombreuses méthodes qui sont encore utiles aujourd'hui, mais il est fourni avec des méthodes que le navigateur fournit d'emblée, telles que des fonctions spécifiques à Array pour le mappage, la réduction et le filtrage, et bien d'autres.
L'amélioration progressive est également une approche utile pour JavaScript, car elle vous permet de proposer une expérience de base (mais toujours fonctionnelle) aux utilisateurs, que vous pouvez enrichir pour les utilisateurs disposant d'appareils plus puissants et de connexions réseau plus rapides. Que vous adhériez ou non au principe d'amélioration progressive, le point reste le même : chaque ressource JavaScript que vous pouvez éviter de télécharger peut se traduire par une expérience qui répond plus rapidement aux interactions des utilisateurs, ce qui est un aspect essentiel des performances Web.
Conclusion
L'audit de votre site Web pour détecter les téléchargements inutiles n'est qu'un aspect de l'optimisation de l'expérience utilisateur, mais il peut avoir un impact important. En résumé :
- Faites l'inventaire de vos propres assets et des assets tiers sur vos pages.
- Mesurez les performances de chaque asset : sa valeur et ses performances techniques.
- Déterminez si les ressources fournissent une valeur suffisante.
- Comprendre l'impact 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 vous veillez également à ne pas gaspiller la bande passante des utilisateurs, tout en améliorant potentiellement les métriques axées sur l'utilisateur et en offrant une meilleure expérience utilisateur.