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. Une bonne pratique consiste à remettre en question et à revoir périodiquement 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 (surtout s'il s'agit d'une ressource tierce) offre-t-elle des performances constantes ? Cette ressource est-elle sur 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 a-t-elle besoin ou dispose-t-elle 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 de valeur ajoutée 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é combien d'utilisateurs voient plusieurs photos dans le carrousel ? Vous risquez de subir des frais généraux importants 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 déterminé combien de visiteurs utilisent le widget ou cliquent sur le contenu qu'il fournit ? L'engagement généré par ce widget est-il suffisant pour justifier ses frais généraux ? De plus, pouvez-vous utiliser une stratégie de chargement pour vous assurer que le script ne sera pas chargé avant d'être nécessaire ?
Déterminer s'il faut éliminer les téléchargements inutiles nécessite souvent une réflexion approfondie et beaucoup de mesures. Pour obtenir de meilleurs résultats, dressez un inventaire régulier et revoyez ces questions pour chaque élément de vos pages.
Effets sur les métriques Core Web Vitals
Google a présenté l'approche introductive des Core Web Vitals 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 métriques Core Web Vitals, vous demander si vous devez charger une ressource particulière sur une page peut vous permettre d'améliorer ces métriques sur votre site Web. Vous trouverez ci-dessous quelques exemples, regroupés par rapport aux métriques Core Web Vitals, que vous pouvez examiner. Bien qu'il ne s'agisse pas d'une liste exhaustive d'exemples (et qu'il y en a beaucoup !), les lire vous permettra peut-être de réfléchir.
Largest Contentful Paint (LCP)
La métrique LCP (Largest Contentful Paint) mesure le chargement du contenu le plus volumineux (par exemple, une image héros ou un titre). Elle est considérée comme une métrique perceptive importante qui donne à l'utilisateur l'impression que le site se charge rapidement.
En général, le fait de télécharger moins de ressources 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. Le chargement différé est un exemple classique : les images qui se trouvent en dehors de la fenêtre d'affichage pendant le 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 disposez d'une grande galerie de vignettes contenant, par exemple, 50 images, et si toutes les images sont chargées en différé, sauf les dix premières, cela signifie que le navigateur peut utiliser plus efficacement la bande passante disponible, et que les premières images que l'utilisateur verra se chargeront plus rapidement.
Toutefois, il ne s'agit pas simplement 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. Cependant, même avec cela, 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 pour 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ément LCP de la page.
Si votre site Web comporte beaucoup de texte, l'élément LCP d'une page peut être un nœud de texte. Bien qu'il existe de nombreuses bonnes stratégies d'optimisation des polices et de chargement, 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 correspondent à des nœuds de texte puissent se charger sans dépendre d'une ressource de police Web et s'afficher presque immédiatement à mesure que le code CSS et le code 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 son téléchargement n'est pas terminé au moment du premier dessin. Pour les images, évitez que 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 pour réduire les décalages de mise en page dans un nombre acceptable.
Chaque ressource qui contribue au CLS d'une page nécessite une certaine quantité de 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 n'accélérez pas seulement le chargement des pages, mais vous réduisez également les efforts cognitifs nécessaires pour préserver la stabilité de la mise en page. Cela se traduit non seulement par une expérience utilisateur beaucoup moins frustrante, mais aussi par une expérience de développement moins frustrante, car vous aurez plus de temps pour atteindre d'autres objectifs dans vos projets.
Interaction to Next Paint (INP) et First Input Delay (FID)
Interaction to Next Paint (INP) et First Input Delay (FID) sont des métriques qui mesurent la réactivité aux entrées utilisateur. Même si INP devrait remplacer le FID comme métrique Core Web Vitals en mars 2024, les stratégies d'optimisation correspondantes ont tendance à s'appliquer également à INP. De plus, l'INP est généralement plus difficile à optimiser que le FID, car il suit la latence totale de l'interaction pour toutes les interactions avec la page, et pas seulement le délai d'entrée de la première interaction tel que mesuré par le FID.
Les INP et le FID ont tendance à être les plus affectés par JavaScript, car ce dernier est à l'origine de la majeure partie de l'interactivité utilisée sur le Web. Pour l'INP et le FID, la quantité de ressources de script téléchargées lors du chargement de la page entraîne un travail potentiellement coûteux lié à l'évaluation et la compilation du script. Moins vous chargez de code JavaScript au démarrage, moins le navigateur doit effectuer de tâches à ce stade critique de l'expérience sur la page.
Même s'il existe des stratégies permettant de réduire la taille des ressources JavaScript téléchargées au démarrage (comme le fractionnement du code et le tree shaking), il est utile d'auditer les packages que vous utilisez dans vos projets pour déterminer s'ils sont nécessaires. Par exemple, lodash comporte de nombreuses méthodes qui sont encore utiles aujourd'hui, mais sont fournies avec des méthodes fournies par le navigateur, telles que des fonctions spécifiques à Array pour le mappage, la réduire et le filtrage, et bien d'autres.
L'amélioration progressive constitue également une approche utile de JavaScript, car elle vous permet de proposer une expérience de base (mais toujours fonctionnelle) aux utilisateurs disposant d'appareils plus puissants et d'une connexion réseau plus rapide. Que vous adhériez ou non au principe de l'amélioration progressive, un point important est toujours d'actualité: chaque ressource JavaScript que vous pouvez éviter de télécharger peut se traduire par une expérience qui réagit plus rapidement aux interactions des utilisateurs, un aspect essentiel des performances Web.
Conclusion
Vérifier si votre site Web ne génère pas de téléchargements inutiles n'est peut-être qu'un aspect de la rapidité de l'expérience utilisateur, mais il peut avoir un impact important. En résumé :
- Dressez l'inventaire de vos propres éléments et des éléments tiers sur vos pages.
- Mesurez les performances de chaque asset: sa valeur et ses performances techniques.
- Déterminez si les ressources offrent une valeur suffisante.
- Comprendre l'impact des téléchargements inutiles sur Core Web Vitals et les métriques associées.
En optimisant ainsi l'efficacité du contenu, vous améliorez non seulement les performances globales, mais aussi de ne pas gaspiller la bande passante des utilisateurs. Vous pouvez aussi améliorer les métriques centrées sur l'utilisateur et offrir une meilleure expérience utilisateur.