Ensemble des bonnes pratiques qui, selon l'équipe Chrome DevRel, sont les moyens les plus efficaces d'améliorer les performances des métriques Core Web Vitals en 2023.
Au fil des ans, Google a formulé de nombreuses recommandations aux développeurs Web sur la façon d'améliorer leurs performances.
Même si chacune de ces recommandations, individuellement, peut améliorer les performances de nombreux sites, l'ensemble complet de recommandations est certes écrasant et, en réalité, il est impossible qu'une personne ou un site puisse toutes les suivre.
À moins que les performances Web ne soient votre travail quotidien, il n'est probablement pas évident de déterminer quelles recommandations auront le plus fort impact positif sur votre site. Par exemple, vous avez peut-être compris que la mise en œuvre d'un CSS critique peut améliorer les performances de chargement, et vous avez peut-être également entendu dire qu'il est important d'optimiser vos images. Mais, si vous n'avez pas le temps de travailler sur les deux choses, comment décideriez-vous laquelle choisir ?
Au sein de l'équipe Chrome, nous avons passé l'année dernière à essayer de répondre à la question suivante: Quelles sont les recommandations les plus importantes que nous pouvons donner aux développeurs pour les aider à améliorer les performances de leurs utilisateurs ?
Pour répondre de manière adéquate à cette question, nous devons prendre en compte non seulement les mérites techniques de chaque recommandation, mais aussi les facteurs humains et organisationnels qui influencent la probabilité que les développeurs puissent réellement adopter ces recommandations. En d'autres termes, certaines recommandations peuvent avoir un impact considérable en théorie, mais en réalité, très peu de sites auront le temps ou les ressources nécessaires pour les implémenter. De même, certaines recommandations sont essentielles, mais la plupart des sites Web les respectent déjà.
Pour résumer, nous souhaitions axer notre liste sur les principales recommandations concernant les performances Web:
- Recommandations qui, selon nous, auront le plus grand impact réel
- Recommandations pertinentes et applicables à la plupart des sites
- Recommandations réalistes pour la plupart des développeurs
Au cours de l'année écoulée, nous avons passé beaucoup de temps à auditer l'ensemble de nos recommandations de performances et à évaluer chacune d'elles (d'un point de vue qualitatif et quantitatif) par rapport aux trois critères ci-dessus.
Cet article présente nos principales recommandations pour améliorer les performances de chacune des métriques Core Web Vitals. Si vous n'avez jamais utilisé les performances Web ou si vous souhaitez déterminer les éléments les plus rentables pour votre argent, nous pensons qu'elles constituent le meilleur point de départ.
Largest Contentful Paint (LCP)
Notre premier ensemble de recommandations concerne le Largest Contentful Paint (LCP), qui est une mesure des performances de chargement. Parmi les trois métriques Core Web Vitals, le LCP est celle qui rencontre le plus de problèmes avec le plus grand nombre de sites. Aujourd'hui, environ la moitié de tous les sites Web atteignent le seuil recommandé. Alors commençons par là.
Vérifier que la ressource LCP est visible à partir du code source HTML
Selon le site 2022 Web Almanac by HTTP Archive, 72% des pages mobiles ont une image comme élément LCP. La plupart des sites devront donc s'assurer que ces images se chargent rapidement pour optimiser leur LCP.
Ce qui n'est pas évident pour de nombreux développeurs, c'est que le temps de chargement d'une image n'est qu'une partie du défi. Un autre aspect essentiel est le temps qui s'écoule avant le début du chargement d'une image. Les données des archives HTTP laissent à penser que de nombreux sites sont bloqués.
En effet, 39% des pages où l'élément LCP était une image comportaient des URL sources qui n'étaient pas visibles dans la source du document HTML. En d'autres termes, ces URL étaient introuvables dans les attributs HTML standards (tels que <img src="..."> ou <link rel="preload" href="...">), ce qui permettrait au navigateur de les détecter rapidement et de commencer à les charger immédiatement.
Si une page doit attendre que les fichiers CSS ou JavaScript soient entièrement téléchargés, analysés et traités avant que l'image puisse commencer à se charger, il est peut-être déjà trop tard.
En règle générale, si votre élément LCP est une image, l'URL de celle-ci doit toujours être visible à partir du code source HTML. Voici quelques conseils pour y parvenir:
Chargez l'image à l'aide d'un élément
<img>avec l'attributsrcousrcset. N'utilisez pas d'attributs non standards, commedata-src, qui nécessitent JavaScript pour l'affichage, car cela ralentit toujours. 9% des pages masquent leur image LCP derrièredata-src.Privilégiez le rendu côté serveur (SSR) plutôt que le rendu côté client, car ce type de rendu implique que le balisage de la page entière (y compris l'image) est présent dans le code source HTML. Les solutions CSR nécessitent l'exécution de JavaScript avant que l'image puisse être découverte.
Si votre image doit être référencée à partir d'un fichier CSS ou JS externe, vous pouvez tout de même l'inclure dans la source HTML à l'aide d'une balise
<link rel="preload">. Notez que les images référencées par des styles intégrés ne sont pas détectables par l'outil d'analyse de préchargement du navigateur. Par conséquent, même si elles se trouvent dans le code source HTML, leur découverte peut être bloquée lors du chargement d'autres ressources. Dans ce cas, le préchargement peut donc être utile.
Pour vous aider à déterminer si votre image LCP présente des problèmes de visibilité, Lighthouse publiera un nouvel audit dans la version 10.0 (prévue en janvier 2023).
S'assurer que la ressource LCP est visible à partir de la source HTML peut permettre d'améliorer de manière mesurable la qualité des résultats et d'accéder à des opportunités supplémentaires de prioriser la ressource (ce qui constitue notre prochaine recommandation).
S'assurer que la ressource LCP est prioritaire
S'assurer que la ressource LCP peut être découverte à partir de la source HTML est une première étape essentielle pour s'assurer que le chargement de la ressource LCP peut commencer plus tôt. Toutefois, une autre étape importante consiste à s'assurer que le chargement de cette ressource est priorisé et qu'il ne soit pas placé en file d'attente derrière d'autres ressources moins importantes.
Par exemple, même si votre image LCP est présente dans la source HTML à l'aide d'une balise <img> standard, si votre page inclut une douzaine de balises <script> dans la balise <head> de votre document avant cette balise <img>, le chargement de votre ressource image peut prendre un certain temps.
Le moyen le plus simple de résoudre ce problème consiste à indiquer au navigateur quelles ressources ont la priorité la plus élevée en définissant le nouvel attribut fetchpriority="high" sur la balise <img> ou <link> qui charge votre image LCP. Vous indiquez ainsi au navigateur de la charger plus tôt, au lieu d'attendre que ces scripts aient terminé.
Selon Web Almanac, seulement 0, 03% des pages éligibles tirent parti de cette nouvelle API.La plupart des sites Web ont donc de nombreuses possibilités d'améliorer le LCP avec un minimum d'efforts. Bien que l'attribut fetchpriority ne soit actuellement compatible qu'avec les navigateurs basés sur Chromium, cette API constitue une amélioration progressive que les autres navigateurs ignorent. Nous recommandons donc vivement aux développeurs de l'utiliser dès maintenant.
Pour les navigateurs autres que Chromium, le seul moyen de s'assurer que la ressource LCP est prioritaire est de la référencer plus tôt dans le document. Reprenons l'exemple d'un site comportant de nombreuses balises <script> dans la partie <head> du document. Si vous souhaitez vous assurer que votre ressource LCP est prioritaire par rapport aux ressources de script, vous pouvez ajouter une balise <link rel="preload"> avant chacun de ces scripts, ou déplacer ces scripts sous le <img> plus tard dans le <body>. Bien que cette méthode fonctionne, elle est moins ergonomique que l'utilisation de fetchpriority. Nous espérons donc que d'autres navigateurs proposeront bientôt cette fonctionnalité.
Un autre aspect essentiel de la priorisation de la ressource LCP est de s'assurer que vous ne faites rien qui pourrait la reclasser, comme ajouter l'attribut loading="lazy". Aujourd'hui, 10% des pages définissent loading="lazy" sur leur image LCP. Méfiez-vous des solutions d'optimisation d'images qui appliquent sans distinction un comportement de chargement différé à toutes les images. S'ils permettent d'ignorer ce comportement, veillez à l'utiliser pour l'image LCP. Si vous ne savez pas quelle image correspond au LCP, essayez d'utiliser des méthodes heuristiques pour choisir un candidat raisonnable.
Le report des ressources non critiques est un autre moyen d'augmenter efficacement la priorité relative de la ressource LCP. Par exemple, les scripts qui n'alimentent pas l'interface utilisateur (comme les scripts d'analyse ou les widgets de réseaux sociaux) peuvent être reportés en toute sécurité jusqu'au déclenchement de l'événement load, ce qui garantit qu'ils ne seront pas en concurrence avec d'autres ressources critiques (telles que la ressource LCP) pour la bande passante réseau.
En résumé, vous devez suivre ces bonnes pratiques pour vous assurer que la ressource LCP est chargée tôt et avec une priorité élevée:
- Ajoutez
fetchpriority="high"au tag<img>de votre image LCP. Si la ressource LCP est chargée via une balise<link rel="preload">, n'ayez crainte, car vous pouvez également y définirfetchpriority="high". - Ne définissez jamais
loading="lazy"sur le tag<img>de votre image LCP. Cela affectera la priorité de votre image et retardera son chargement. - Différez les ressources non critiques dans la mesure du possible. Vous pouvez soit les déplacer à la fin de votre document, soit utiliser le chargement différé natif pour les images ou les iFrames, soit les charger de manière asynchrone via JavaScript.
Utiliser un CDN pour optimiser le TTFB des documents et des ressources
Les deux recommandations précédentes visaient à s'assurer que votre ressource LCP est découverte tôt et prioritaire afin qu'elle puisse se charger immédiatement. La dernière pièce de ce puzzle consiste à s'assurer que la réponse initiale du document arrive aussi rapidement que possible.
Le navigateur ne peut pas lancer le chargement des sous-ressources tant qu'il n'a pas reçu le premier octet de la réponse initiale du document HTML. Et plus vite cela se produit, plus vite tout le reste peut se produire aussitôt.
Cette durée est appelée Time to First Byte (TTFB). Le meilleur moyen de réduire le TTFB consiste à:
- Diffusez votre contenu le plus près possible de vos utilisateurs géographiquement.
- Mettre en cache ce contenu pour que le contenu demandé récemment puisse être à nouveau diffusé rapidement.
Le meilleur moyen de procéder est d'utiliser un CDN. Les CDN distribuent vos ressources à des serveurs en périphérie, répartis dans le monde entier, limitant ainsi la distance que ces ressources doivent parcourir sur le réseau jusqu'à vos utilisateurs. En général, les CDN disposent de contrôles précis de la mise en cache, personnalisables et optimisés pour les besoins de votre site.
De nombreux développeurs ont l'habitude d'utiliser un CDN pour héberger des éléments statiques, mais les CDN peuvent également diffuser et mettre en cache des documents HTML, même ceux qui sont générés dynamiquement.
Selon Web Almanac, seulement 29% des demandes de documents HTML étaient diffusées à partir d'un CDN, ce qui signifie que les sites ont la possibilité de réclamer davantage d'économies.
Voici quelques conseils pour configurer vos CDN:
- Envisagez d'augmenter la durée de mise en cache du contenu (par exemple, est-il vraiment essentiel que le contenu soit toujours à jour ? ou quelques minutes peuvent-elles être obsolètes ?).
- Vous pouvez même mettre en cache le contenu indéfiniment, puis vider le cache si/quand vous effectuez une mise à jour.
- Déterminez si vous pouvez déplacer la logique dynamique en cours d'exécution sur votre serveur d'origine vers la périphérie (une fonctionnalité de la plupart des CDN modernes).
En général, chaque fois que vous pouvez diffuser du contenu directement à partir de la périphérie (en évitant de passer par votre serveur d'origine), vous gagnez en performances. Et même dans les cas où vous devez effectuer un trajet jusqu'à votre serveur d'origine, les CDN sont généralement optimisés pour le faire beaucoup plus rapidement, ce qui est gagnant dans tous les cas.
Cumulative Layout Shift (CLS)
L'ensemble de recommandations suivant concerne le Cumulative Layout Shift (CLS), qui mesure la stabilité visuelle des pages Web. Même si le CLS s'est considérablement amélioré sur le Web depuis 2020, environ un quart des sites Web n'atteignent toujours pas le seuil recommandé. Il reste donc une opportunité importante pour de nombreux sites d'améliorer leur expérience utilisateur.
Définir des tailles explicites pour tout contenu chargé à partir de la page
Les décalages de mise en page se produisent généralement lorsque le contenu existant est déplacé après la fin du chargement d'un autre contenu. Par conséquent, la principale façon d'atténuer cela consiste à réserver tout l'espace nécessaire à l'avance autant que possible.
La manière la plus simple de corriger les décalages de mise en page causés par des images non dimensionnées consiste à définir explicitement les attributs width et height (ou des propriétés CSS équivalentes). Cependant, selon HTTP Archive, 72% des pages comportent au moins une image non dimensionnée. Sans taille explicite, les navigateurs définissent initialement une hauteur par défaut de 0px et peuvent provoquer un décalage de mise en page notable lorsque l'image est finalement chargée et que les dimensions sont découvertes. Il s'agit à la fois d'une énorme opportunité pour le Web collectif, qui nécessite beaucoup moins d'efforts que certaines des autres recommandations proposées dans cet article.
Il est également important de garder à l'esprit que les images ne sont pas les seuls contributeurs au CLS. Les décalages de mise en page peuvent être dus à d'autres contenus qui se chargent généralement après le rendu initial de la page, comme les annonces tierces ou les vidéos intégrées. La propriété aspect-ratio peut vous aider à lutter contre ce problème. Il s'agit d'une fonctionnalité CSS relativement récente qui permet aux développeurs de fournir explicitement un format pour les images ainsi que pour les éléments qui ne sont pas des images. Vous pouvez ainsi définir une width dynamique (en fonction de la taille de l'écran, par exemple) et faire en sorte que le navigateur calcule automatiquement la hauteur appropriée, de la même manière que pour des images avec des dimensions.
Parfois, il n'est pas possible de connaître la taille exacte d'un contenu dynamique, car il est, par nature, dynamique. Toutefois, même si vous ne connaissez pas la taille exacte, vous pouvez toujours prendre des mesures pour réduire la gravité des décalages de mise en page. Il est presque toujours préférable de définir un min-height approprié plutôt que de permettre au navigateur d'utiliser la hauteur par défaut de 0px pour un élément vide. L'utilisation d'un min-height est généralement une solution simple, car elle permet toujours au conteneur d'atteindre la hauteur finale du contenu si nécessaire. Cela permet de réduire ce niveau de croissance de la quantité totale à un niveau, espérons-le, plus tolérable.
Vérifier que les pages sont éligibles au cache amélioré
Les navigateurs utilisent un mécanisme de navigation appelé cache amélioré (ou cache amélioré) pour charger instantanément une page antérieure ou ultérieure dans l'historique du navigateur, directement à partir d'un instantané de mémoire.
Le cache amélioré permet d'optimiser considérablement les performances au niveau du navigateur et élimine complètement les décalages de mise en page lors du chargement de la page, qui représentent la majorité du CLS pour de nombreux sites. L'introduction du cache amélioré a provoqué la plus grande amélioration du CLS observée en 2022.
Malgré cela, un grand nombre de sites Web ne sont pas éligibles au cache amélioré et ne peuvent donc pas bénéficier de performances Web sans frais pour un grand nombre de navigations. À moins que votre page ne charge des informations sensibles que vous ne souhaitez pas récupérer de la mémoire, vous devez vous assurer que vos pages sont éligibles.
Les propriétaires de sites doivent vérifier que leurs pages sont éligibles au cache amélioré et chercher les raisons pour lesquelles elles ne le sont pas. Chrome dispose déjà d'un testeur bfcache dans les outils de développement et nous prévoyons d'améliorer cette année ses outils grâce à un nouvel audit Lighthouse effectuant un test similaire et à une API permettant d'effectuer des mesures sur le terrain.
Bien que nous ayons inclus le cache amélioré dans la section CLS, étant donné que nous avons constaté les plus grands gains jusqu'à présent, le cache amélioré améliore généralement également les autres Core Web Vitals. Il fait partie des nombreuses navigations instantanées disponibles pour améliorer considérablement la navigation sur les pages.
Évitez les animations/transitions qui utilisent des propriétés CSS qui induisent la mise en page
Une autre source courante de décalages de mise en page est l'animation des éléments. Par exemple, les bannières de cookies ou autres bannières de notification qui glissent du haut ou du bas contribuent souvent au CLS. Cela est particulièrement problématique lorsque ces bannières repoussent d'autres contenus. Même si ce n'est pas le cas, les animations peuvent avoir un impact sur le CLS.
Bien que les données d'archive HTTP ne puissent pas établir de lien concluant entre les animations et les décalages de mise en page, les données montrent que les pages qui animent une propriété CSS qui pourraient affecter la mise en page ont 15% moins de chances d'avoir un "bon" CLS que les pages dans l'ensemble. Certaines propriétés sont associées à un CLS moins élevé que d'autres. Par exemple, les pages qui animent des largeurs margin ou border présentent un CLS "faible" représentant presque deux fois le taux global de pages considérées comme mauvaises.
Ce n'est peut-être pas surprenant, car chaque fois que vous transférez ou animez une propriété CSS induisant la mise en page, cela entraîne des décalages de mise en page. Si ces décalages ne se produisent pas dans les 500 millisecondes suivant une interaction de l'utilisateur, ils ont un impact sur le CLS.
Ce qui peut être surprenant pour certains développeurs, c'est que c'est le cas même lorsque l'élément est emmené en dehors du flux normal du document. Par exemple, des éléments positionnés de façon absolue qui animent top ou left entraînent des décalages de mise en page, même s'ils ne déplacent pas d'autres contenus. Toutefois, si vous animez transform:translateX() ou transform:translateY() au lieu d'animer top ou left, le navigateur ne mettra pas à jour la mise en page et ne générera donc aucun décalage de mise en page.
Préférer l'animation des propriétés CSS pouvant être mises à jour sur le thread compositeur du navigateur est depuis longtemps une bonne pratique en termes de performances, car cela déplace ces tâches sur le GPU et en dehors du thread principal. En plus d'être une bonne pratique générale, il peut également contribuer à améliorer le CLS.
En règle générale, n'animez jamais une propriété CSS qui nécessite que le navigateur mette à jour la mise en page, sauf si vous le faites en réponse à une pression de l'utilisateur ou à une pression sur une touche (mais pas sur hover). Dans la mesure du possible, privilégiez les transitions et les animations à l'aide de la propriété CSS transform.
L'audit Lighthouse Éviter les animations non composées avertit lorsqu'une page anime des propriétés CSS potentiellement lentes.
First Input Delay (FID)
Notre dernier ensemble de recommandations concerne le FID (First Input Delay), qui mesure la réactivité d'une page aux interactions des utilisateurs. Bien que la plupart des sites Web obtiennent actuellement de bons résultats en termes de FID, nous avons déjà documenté les lacunes de la métrique FID par le passé. Nous pensons que les sites ont encore de nombreuses possibilités d'améliorer leur réactivité globale aux interactions des utilisateurs.
Notre nouvelle métrique Interaction to Next Paint (INP) peut remplacer FID, et toutes les recommandations ci-dessous s'appliquent aussi bien au FID qu'à l'INP. Étant donné que les sites sont moins performants sur INP que sur le FID, en particulier sur les mobiles, nous encourageons les développeurs à prendre sérieusement en compte ces recommandations de réactivité, même si le FID est "satisfaisant".
Éviter ou diviser les longues tâches
Les tâches correspondent à des tâches discrètes réalisées par le navigateur. Les tâches incluent le rendu, la mise en page, l'analyse, la compilation et l'exécution de scripts. Lorsque les tâches deviennent des tâches longues (c'est-à-dire 50 millisecondes ou plus), elles empêchent le thread principal de répondre rapidement aux entrées utilisateur.
Selon l'almanac du Web, de nombreuses preuves suggèrent que les développeurs pourraient faire plus pour éviter ou interrompre les longues tâches. Bien que décoder les longues tâches ne demande pas autant d'efforts que les autres recommandations présentées dans cet article, il est plus facile que d'autres techniques non proposées dans cet article.
Bien que vous deviez toujours vous efforcer d'effectuer le moins de travail possible en JavaScript, vous pouvez apporter une aide supplémentaire au thread principal en divisant les longues tâches en tâches plus petites. Pour ce faire, effectuez régulièrement un retour sur le thread principal afin que les mises à jour et autres interactions utilisateur s'affichent plus rapidement.
Vous pouvez également envisager d'utiliser des API telles que isInputPending et l'API Scheduler. isInputPending est une fonction qui renvoie une valeur booléenne indiquant si une entrée utilisateur est en attente. Si la valeur true est renvoyée, vous pouvez céder au thread principal afin qu'il puisse gérer l'entrée utilisateur en attente.
L'API Scheduler est une approche plus avancée, qui vous permet de planifier le travail en fonction d'un système de priorités qui tient compte du fait que le travail en cours soit visible par l'utilisateur ou en arrière-plan.
En divisant les tâches longues, vous permettez au navigateur de s'intégrer davantage aux tâches essentielles visibles par l'utilisateur, telles que la gestion des interactions et des mises à jour de l'affichage qui en résultent.
Éviter d'utiliser des scripts JavaScript inutiles
Cela ne fait aucun doute: les sites Web envoient plus de code JavaScript que jamais et cette tendance ne semble pas changer de sitôt. Lorsque vous envoyez trop de code JavaScript, vous créez un environnement dans lequel les tâches se font concurrence pour attirer l'attention du thread principal. Cela peut certainement affecter la réactivité de votre site Web, en particulier pendant cette période cruciale de démarrage.
Toutefois, il ne s'agit pas d'un problème insoluble. Plusieurs options s'offrent à vous:
- Utilisez l'outil de couverture dans les outils pour les développeurs Chrome afin de trouver le code inutilisé dans les ressources de votre site Web. En réduisant la taille des ressources dont vous avez besoin au démarrage, vous pouvez faire en sorte que votre site Web passe moins de temps à analyser et compiler le code, ce qui améliore l'expérience utilisateur initiale.
- Parfois, le code inutilisé que vous trouvez à l'aide de l'outil de couverture est marqué comme "inutilisé", car il n'a pas été exécuté au démarrage, mais il est toujours nécessaire pour certaines fonctionnalités à l'avenir. Il s'agit d'un code que vous pouvez déplacer vers un bundle distinct via la scission du code.
- Si vous utilisez Tag Manager, vérifiez régulièrement vos balises pour vous assurer qu'elles sont optimisées, voire si elles sont encore utilisées. Vous pouvez supprimer les anciennes balises contenant du code inutilisé afin de réduire la taille du code JavaScript de votre gestionnaire de balises et de gagner en efficacité.
Éviter les mises à jour de rendu volumineuses
JavaScript n'est pas le seul facteur susceptible d'affecter la réactivité de votre site Web. L'affichage peut être un type de travail coûteux en soi. Lorsque des mises à jour importantes de l'affichage se produisent, elles peuvent interférer avec la capacité de votre site Web à répondre aux entrées utilisateur.
L'optimisation du rendu n'est pas un processus simple et dépend souvent de ce que vous essayez d'accomplir. Malgré cela, vous pouvez prendre certaines mesures pour vous assurer que les mises à jour du rendu sont raisonnables et qu'elles ne se propagent pas à de longues tâches:
- Évitez d'utiliser
requestAnimationFrame()pour effectuer des tâches non visuelles. Les appelsrequestAnimationFrame()sont gérés pendant la phase de rendu de la boucle d'événements. Lorsque trop de travail est effectué au cours de cette étape, les mises à jour du rendu peuvent être retardées. Il est essentiel que toutes les tâches que vous effectuez avecrequestAnimationFrame()soient strictement réservées aux tâches qui impliquent des mises à jour d'affichage. - La taille de votre DOM doit être petite. Il existe une corrélation entre la taille du DOM et l'intensité du travail de mise en page. Lorsque le moteur de rendu doit mettre à jour la mise en page d'un très grand DOM, le travail requis pour recalculer sa mise en page peut considérablement augmenter.
- Utilisez la structuration CSS. Le confinement CSS repose sur la propriété CSS
contain, qui fournit au navigateur des instructions sur la mise en page du conteneur sur lequel la propriétécontainest définie, y compris l'isolement du champ d'application de la mise en page et du rendu à une racine spécifique dans le DOM. Ce n'est pas toujours un processus facile, mais en isolant les zones contenant des mises en page complexes, vous pouvez éviter d'effectuer des tâches de mise en page et de rendu qui ne sont pas nécessaires.
Conclusion
L'amélioration des performances de vos pages peut sembler intimidante, d'autant plus qu'il existe une multitude de conseils disponibles sur le Web. Toutefois, en vous concentrant sur ces recommandations, vous pourrez aborder le problème avec concentration et objectif, et ainsi faire évoluer les métriques Core Web Vitals de votre site Web.
Bien que les recommandations listées ici ne soient en aucun cas exhaustives, nous pensons, après une analyse minutieuse de l'état du Web, qu'elles constituent le moyen le plus efficace d'améliorer les performances des Core Web Vitals pour les sites en 2023.
Si vous souhaitez aller au-delà des recommandations présentées ici, consultez ces guides d'optimisation pour plus d'informations:
C'est une nouvelle année et un Web plus rapide pour tous ! Que vos sites soient rapides pour vos utilisateurs, dans les domaines qui comptent le plus !
Photo par Devin Avery