La ressource la plus rapide et la mieux optimisée est une ressource non envoyée. Vous devez supprimer 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 est-il compensé par la valeur qu'elle apporte à l'utilisateur ? Pouvez-vous mesurer et prouver sa valeur ?
- La ressource (en particulier si elle est tierce) offre-t-elle des performances cohérentes ? Cette ressource se trouve-t-elle sur le chemin critique ou doit-elle l'être ? Si la ressource se trouve sur le chemin critique, peut-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 un contrat de niveau de service ou en dispose-t-elle 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, voire pire, qui nuisent aux performances de la page sans apporter beaucoup de valeur au visiteur ni au site sur lequel elles sont hébergées. Cela s'applique également aux ressources et aux widgets propriétaires et 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 les fait défiler.
- Question:Avez-vous mesuré le nombre d'utilisateurs qui regardent plusieurs photos dans le carrousel ? Vous risquez de générer des coûts é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 des contenus associés, 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 le nombre de clics sur le contenu qu'il fournit ? L'engagement généré par ce widget est-il suffisant pour justifier ses coûts ? 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 ?
Déterminer si vous devez éliminer les téléchargements inutiles nécessite souvent une réflexion et des mesures minutieuses. Pour de meilleurs résultats, effectuez régulièrement un inventaire et revoyez ces questions pour chaque composant 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 qui reflètent l'expérience des utilisateurs sur le Web. Bien qu'il existe de nombreuses stratégies d'optimisation pour les Core Web Vitals, vous pouvez vous demander si vous devez charger une ressource particulière sur une page pour améliorer ces métriques sur votre site Web. Vous trouverez ci-dessous quelques exemples (groupés par métrique Core Web Vitals) qui méritent d'être pris en compte. Bien que cette liste d'exemples ne soit pas exhaustive (il y en a beaucoup !), 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 hero ou un titre) est chargé. Il s'agit d'une métrique perceptive importante qui donne à l'utilisateur l'impression qu'un site se charge rapidement.
En règle générale, 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 le chargement paresseux, où les images situées en dehors de la fenêtre d'affichage lors du chargement de la 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 avez une grande galerie de miniatures de 50 images, le chargement paresseux de toutes les miniatures, à l'exception des 10 premières, permet au navigateur d'utiliser plus efficacement la bande passante dont il dispose. Les premières images que l'utilisateur verra se chargeront ainsi plus rapidement.
Toutefois, il ne s'agit pas seulement 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 en priorité élevée, peuvent priver la 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 qui peut ê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 bonnes 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. Ainsi, les éléments LCP qui sont des nœuds de texte peuvent se charger sans dépendre d'une ressource de police Web et s'afficher presque immédiatement lorsque le CSS et le HTML arrivent du serveur.
Cumulative Layout Shift (CLS)
Chaque ressource que vous chargez peut contribuer au décalage de mise en page cumulé (CLS) d'une page, en particulier si le téléchargement n'est pas terminé au moment de la peinture initiale. Pour les images, évitez le CLS en adoptant des pratiques telles que le paramétrage de dimensions explicites. Pour les polices, la gestion du chargement des polices et la mise en correspondance des polices de remplacement peut réduire les décalages pendant la période de remplacement 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 décalages de mise en page à un niveau 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 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 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 c'est ce code qui génère la plupart des interactions sur le Web. Plus précisément, la quantité de ressources de script téléchargées lors du chargement de la page peut déclencher un travail potentiellement coûteux lié à l'évaluation et à la compilation des scripts. Moins vous chargez de code JavaScript au démarrage, moins le navigateur a de travail à effectuer à ce stade critique de l'expérience sur la page, où les utilisateurs peuvent essayer d'interagir avec elle.
Bien qu'il existe des stratégies permettant de réduire la taille des ressources JavaScript téléchargées au démarrage (par exemple, la division du code et le ramassage d'arbres), il est utile d'examiner les packages que vous utilisez dans vos projets pour voir s'ils sont vraiment nécessaires. Par exemple, lodash propose de nombreuses méthodes toujours utiles aujourd'hui, mais est fourni avec des méthodes que le navigateur fournit prêtes à l'emploi, 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 référence (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 respectiez ou non le principe d'amélioration progressive, le point reste le même: chaque ressource JavaScript que vous pouvez éviter de télécharger peut entraîner 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'expérience utilisateur rapide, mais il peut avoir un impact important. En résumé :
- Faites l'inventaire de vos propres composants et de ceux de tiers sur vos pages.
- Mesurez les performances de chaque composant: sa valeur et ses performances techniques.
- Déterminez si les ressources apportent 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é des contenus de cette manière, vous améliorez non seulement les performances globales, mais vous veillez également à ne pas gaspiller la bande passante des utilisateurs. Vous pouvez également améliorer les métriques axées sur l'utilisateur et offrir une meilleure expérience utilisateur.