Ensemble des bonnes pratiques qui, selon l'équipe des développeurs Chrome, constituent les moyens les plus efficaces d'améliorer les performances des Core Web Vitals en 2023.
Au fil des ans, chez Google, nous avons donné de nombreuses recommandations aux développeurs Web sur la façon d'améliorer les performances.
Même si chacune de ces recommandations, individuellement, peut améliorer les performances de nombreux sites, l'ensemble des recommandations est certes écrasant et, en réalité, il est impossible qu'une même personne ou un seul site les suive toutes.
À moins que les performances Web ne soient votre travail quotidien, il n'est probablement pas évident d'identifier les recommandations qui auront le plus d'impact positif sur votre site. Par exemple, vous avez peut-être lu que l'implémentation de CSS critiques 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 ces deux aspects, comment décideriez-vous lequel choisir ?
L'année dernière, l'équipe Chrome a tenté 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 façon appropriée à cette question, nous devons tenir compte non seulement des avantages techniques de chaque recommandation, mais aussi des facteurs humains et organisationnels qui déterminent la probabilité que les développeurs soient en mesure de les appliquer. En d'autres termes, certaines recommandations peuvent avoir un impact énorme en théorie, mais en réalité, très peu de sites auront le temps ou les ressources nécessaires pour les mettre en œuvre. De même, certaines recommandations sont essentielles, mais la plupart des sites Web suivent déjà ces pratiques.
Pour résumer, nous souhaitons mettre l'accent sur les recommandations suivantes concernant les performances Web:
- Recommandations qui, selon nous, auront l'impact le plus important dans le monde 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 à vérifier l'ensemble de nos recommandations en matière de performances et à évaluer chacune d'entre elles (sur le plan qualitatif et quantitatif) en fonction des trois critères ci-dessus.
Ce post présente nos principales recommandations pour améliorer les performances de chacune des métriques Core Web Vitals. Si vous débutez dans le domaine des performances Web ou si vous cherchez à déterminer ce qui vous permettra d'optimiser votre retour sur investissement, nous pensons que ces recommandations sont le meilleur point de départ.
Largest Contentful Paint (LCP)
Notre premier ensemble de recommandations concerne la métrique Largest Contentful Paint (LCP), qui mesure les performances de chargement. Parmi les trois métriques Core Web Vitals, le LCP est celui avec lequel le plus grand nombre de sites rencontrent des difficultés. À l'heure actuelle, seulement environ la moitié des sites sur le Web atteignent le seuil recommandé. Commençons par là.
S'assurer que la ressource LCP est visible à partir du code source HTML
Selon l'almanach Web de 2022 de l'archive HTTP, 72% des pages mobiles comportent une image comme élément LCP. Par conséquent, la plupart des sites doivent s'assurer que ces images peuvent se charger rapidement pour optimiser leur LCP.
Ce qui n'est peut-être pas évident pour de nombreux développeurs, c'est que le temps nécessaire pour charger une image n'est qu'une partie du défi. Un autre élément essentiel est le délai avant le début du chargement d'une image. Les données des archives HTTP suggèrent que c'est en fait à ce niveau que de nombreux sites se déclenchent.
En fait, sur les pages dont l'élément LCP était une image, 39% de ces images comportaient des URL sources qui n'étaient pas visibles dans le document HTML source. En d'autres termes, ces URL n'étaient pas présentes dans les attributs HTML standards (tels que <img src="..."> ou <link rel="preload" href="...">), ce qui permet au navigateur de les identifier rapidement et de les charger immédiatement.
Si une page doit attendre la fin du téléchargement, de l'analyse et du traitement des fichiers CSS ou JavaScript avant même que le chargement de l'image ne commence, il est peut-être déjà trop tard.
En règle générale, si votre élément LCP est une image, son URL 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 s'afficher, car ils seront toujours plus lents. 9% des pages masquent leur image LCP derrièredata-src.Privilégiez le rendu côté serveur plutôt que le rendu côté client, car le rendu côté client 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 pour 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 quand même l'inclure dans le code source HTML à l'aide d'une balise
<link rel="preload">. Notez que les images référencées par les styles intégrés ne sont pas détectables par l'outil d'analyse du préchargement du navigateur. Par conséquent, même si elles se trouvent dans le code source HTML, leur découverte peut toujours être bloquée lors du chargement d'autres ressources. Le préchargement peut donc être utile dans ces cas de figure.
Pour vous aider à comprendre si votre image LCP présente des problèmes de visibilité, Lighthouse publiera un nouvel audit dans la version 10.0 (prévu en janvier 2023).
En vous assurant que la ressource LCP est visible à partir de la source HTML, vous pouvez apporter des améliorations mesurables et bénéficier d'opportunités supplémentaires de prioriser la ressource, ce que nous recommandons ensuite.
S'assurer que la ressource LCP est priorisée
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 la ressource LCP peut commencer à se charger tôt. Toutefois, une autre étape importante consiste à s'assurer que le chargement de cette ressource est priorisé et qu'il n'est pas mis en file d'attente derrière un tas 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 les ressources ayant 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. Cela indique au navigateur de le charger plus tôt, plutôt que d'attendre que ces scripts soient terminés.
Selon l'almanach Web, seules 0, 03% des pages éligibles tirent parti de cette nouvelle API.Cela signifie que la plupart des sites Web ont de nombreuses opportunités d'améliorer le LCP avec très peu d'efforts. Bien que l'attribut fetchpriority ne soit actuellement compatible qu'avec les navigateurs basés sur Chromium, cette API est 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 par rapport aux autres ressources 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 section <head> du document. Si vous voulez vous assurer que votre ressource LCP est prioritaire par rapport à ces ressources de script, vous pouvez ajouter une balise <link rel="preload"> avant les scripts ou déplacer ces scripts sous le <img> plus tard dans le <body>. Cette méthode est efficace, mais elle est moins ergonomique que fetchpriority. Nous espérons donc qu'elle sera bientôt compatible avec d'autres navigateurs.
Un autre aspect essentiel de la hiérarchisation des ressources LCP consiste à s'assurer que vous ne faites rien qui pourrait entraîner une dégradation de leur priorité, comme ajouter l'attribut loading="lazy". Aujourd'hui, 10% des pages indiquent loading="lazy" sur leur image LCP. Méfiez-vous des solutions d'optimisation d'images qui appliquent sans distinction le comportement de chargement différé à toutes les images. Si elles 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 ne alimentent pas l'interface utilisateur (tels que 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">, ne vous inquiétez pas, car vous pouvez également définirfetchpriority="high"sur celle-ci. - N'indiquez jamais
loading="lazy"dans le tag<img>de votre image LCP. Si vous le faites, votre image sera moins prioritaire et son chargement sera retardé. - Différez les ressources non critiques si possible. Vous pouvez les déplacer à la fin de votre document, utiliser le chargement différé natif pour les images ou les iFrames, ou les charger de manière asynchrone via JavaScript.
Utiliser un CDN pour optimiser le TTFB de documents et de ressources
Les deux recommandations précédentes visaient à s'assurer que votre ressource LCP est découverte tôt et par ordre de priorité afin qu'elle puisse commencer à se charger immédiatement. La dernière pièce de ce puzzle consiste à s'assurer que la réponse initiale du document arrive également le plus rapidement possible.
Le navigateur ne peut pas commencer à charger des sous-ressources tant qu'il n'a pas reçu le premier octet de la réponse initiale du document HTML. Plus tôt cela se produit, plus vite tout le reste peut se produire.
Cette durée est appelée Time to First Byte (TTFB). Le meilleur moyen de réduire ce délai est de:
- Diffusez vos contenus aussi près que possible de vos utilisateurs
- Mettre en cache ce contenu afin que le contenu récemment demandé puisse être renvoyé rapidement.
La meilleure façon de procéder est d'utiliser un CDN. Les CDN distribuent vos ressources sur des serveurs périphériques, répartis dans le monde entier, ce qui limite la distance que ces ressources doivent parcourir sur le fil jusqu'à vos utilisateurs. De plus, les CDN disposent généralement de commandes ultraprécises de mise en cache que vous pouvez personnaliser et optimiser selon les besoins de votre site.
De nombreux développeurs savent 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 l'almanach Web, seulement 29% des requêtes de documents HTML proviennent d'un CDN, ce qui signifie que les sites ont de nombreuses possibilités de bénéficier d'économies supplémentaires.
Voici quelques conseils pour configurer vos CDN:
- Envisagez d'augmenter la durée de mise en cache du contenu (par exemple, est-il réellement important que le contenu soit toujours à jour ? ou peut-elle être obsolète de quelques minutes ?
- Envisagez même de mettre en cache le contenu indéfiniment, puis de vider le cache si vous effectuez une mise à jour, le cas échéant.
- 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 en périphérie (sans passer par votre serveur d'origine), vous gagnez en performances. Et même dans les cas où vous devez effectuer le trajet jusqu'à votre serveur d'origine, les CDN sont généralement optimisés pour le faire beaucoup plus rapidement. C'est donc une victoire dans tous les cas.
Cumulative Layout Shift (CLS)
L'ensemble de recommandations suivant concerne le CLS (Cumulative Layout Shift), qui est une mesure de la stabilité visuelle des pages Web. Bien que 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é. Pour de nombreux sites, il reste donc une grande opportunité à saisir pour améliorer leur expérience utilisateur.
Définir des tailles explicites pour tout contenu chargé depuis la page
Les décalages de mise en page se produisent généralement lorsque du contenu existant est déplacé une fois le chargement d'un autre contenu terminé. Par conséquent, le principal moyen d'y remédier consiste à réserver l'espace nécessaire à l'avance autant que possible.
Le moyen le 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). Toutefois, selon HTTP Archive, 72% des pages contiennent au moins une image de taille insuffisante. Sans taille explicite, les navigateurs définissent initialement une hauteur par défaut de 0px, ce qui peut entraîner un décalage notable de la mise en page lors du chargement final de l'image et de la découverte des dimensions. Il s'agit à la fois d'une immense opportunité pour le Web collectif, et nécessite beaucoup moins d'efforts que certaines des autres recommandations suggérées dans cet article.
Il est également important de garder à l'esprit que les images ne sont pas les seules 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, y compris des annonces tierces ou des 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 des images, ainsi que pour des éléments qui ne sont pas des images. Vous pourrez ainsi définir un width dynamique (par exemple, basé sur la taille de l'écran) et faire en sorte que le navigateur calcule automatiquement la hauteur appropriée, comme pour les images avec des dimensions.
Parfois, il n'est pas possible de connaître la taille exacte d'un contenu dynamique, car il s'agit, par nature, d'un contenu dynamique. Toutefois, même si vous ne connaissez pas la taille exacte, vous pouvez prendre des mesures pour réduire l'importance 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. Elle a simplement réduit cette quantité de croissance de la quantité totale à un niveau qui, nous l'espérons, est 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 bfcache en abrégé) pour charger instantanément une page précédente ou ultérieure dans l'historique du navigateur directement à partir d'un instantané de mémoire.
Le cache amélioré permet d'optimiser de manière significative les performances au niveau du navigateur. Il permet d'éliminer totalement les décalages de mise en page lors du chargement de la page, qui est à l'origine de la majeure partie du CLS pour de nombreux sites. L'introduction du bfcache a entraîné la plus grande amélioration du CLS observée en 2022.
Malgré cela, un grand nombre de sites Web ne peuvent pas bénéficier du cache amélioré, et ne bénéficient donc pas de ce gain 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 restaurer 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 trouver les raisons pour lesquelles ce n'est pas le cas. Chrome dispose déjà d'un testeur bfcache dans les outils de développement. Cette année, nous prévoyons d'améliorer les outils avec un nouvel audit Lighthouse effectuant un test similaire et une API permettant de mesurer cela sur le terrain.
Bien que nous ayons inclus le cache amélioré dans la section "CLS", comme nous avons constaté les gains les plus importants jusqu'à présent, le cache amélioré améliore généralement également les autres Core Web Vitals. Il s'agit de l'une des différentes fonctionnalités de navigation instantanée permettant d'améliorer considérablement la navigation sur les pages.
Évitez les animations/transitions qui utilisent des propriétés CSS induisant une 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 d'autres bannières de notification qui se glissent depuis le haut ou le bas contribuent souvent au CLS. Cela est particulièrement problématique lorsque ces bannières repoussent d'autres contenus. Toutefois, même si ce n'est pas le cas, les animer peuvent avoir un impact sur le CLS.
Bien que les données HTTP Archive ne puissent pas associer de manière concluante les animations aux décalages de mise en page, les données montrent que les pages qui animent toute propriété CSS qui pourrait affecter la mise en page sont 15% moins susceptibles d'avoir une "bonne" qualité. que le CLS que l'ensemble des pages. Certaines propriétés sont associées à un CLS moins élevé que d'autres. Par exemple, les pages qui animent les largeurs margin ou border présentent la mention "mauvaises" Le CLS est presque deux fois plus élevé que celui de toutes les pages considérées comme médiocres.
Ce n'est peut-être pas surprenant, car chaque fois que vous effectuez une transition ou que vous animez n'importe quelle propriété CSS induisant une 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 d'une interaction utilisateur, ils auront un impact sur le CLS.
Ce qui peut être surprenant pour certains développeurs, c'est que cela se vérifie même lorsque l'élément est pris en dehors du flux normal du document. Par exemple, des éléments positionnés de façon absolue qui animent top ou left entraîneront 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.
Privilégier l'animation des propriétés CSS pouvant être mises à jour sur le thread du compositeur du navigateur est depuis longtemps une bonne pratique d'amélioration des performances, car elle déplace ces tâches sur le GPU et en dehors du thread principal. En plus d'être une bonne pratique générale en matière de performances, cette approche peut aussi contribuer à améliorer le CLS.
En règle générale, n'animez ou n'effectuez jamais de transition pour une propriété CSS qui nécessite que le navigateur mette à jour la mise en page, sauf si vous le faites en réponse à un appui ou à une touche utilisateur (mais pas 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 vous 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 scorent actuellement très bien en ce qui concerne le FID, nous avons documenté des lacunes concernant la métrique FID par le passé, et nous pensons qu'il existe encore de nombreuses possibilités pour les sites d'améliorer leur réactivité globale aux interactions des utilisateurs.
Notre nouvelle métrique Interaction to Next Paint (INP) est un successeur potentiel du FID, et toutes les recommandations ci-dessous s'appliquent de la même manière au FID et à l'INP. Étant donné que les sites sont moins performants sur INP que sur FID, en particulier sur mobile, nous encourageons les développeurs à prendre sérieusement en compte ces recommandations de réactivité, même si elles sont "satisfaisantes". FID.
Évitez ou séparez les longues tâches
Les tâches sont des tâches discrètes exécutées par le navigateur. Les tâches incluent l'affichage, la mise en page, l'analyse, ainsi que la compilation et l'exécution de scripts. Lorsque les tâches deviennent de longues tâches (50 millisecondes ou plus), elles empêchent le thread principal de répondre rapidement aux entrées utilisateur.
Selon l'almanach du Web, de nombreuses preuves suggèrent que les développeurs pourraient en faire davantage pour éviter ou éliminer les longues tâches. Bien que la répartition de longues tâches ne soit pas aussi simple que les autres recommandations présentées dans cet article, elle l'est moins que d'autres techniques qui ne sont pas proposées dans cet article.
Bien que vous deviez toujours vous efforcer de faire le moins de travail possible en JavaScript, vous pouvez aider le thread principal en divisant les tâches longues en tâches plus petites. Pour ce faire, envoyez souvent des données au thread principal afin d'accélérer l'affichage des mises à jour et d'autres interactions utilisateur.
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 elle renvoie true, vous pouvez céder au thread principal pour 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 prennent en compte si le travail en cours est visible par l'utilisateur ou en arrière-plan.
En séparant les longues tâches, vous donnez au navigateur davantage d'occasions de s'adapter aux tâches essentielles visibles par l'utilisateur, comme la gestion des interactions et des mises à jour de rendu qui en résultent.
Éviter les scripts JavaScript inutiles
Cela ne fait aucun doute: les sites Web proposent plus de JavaScript que jamais, et cette tendance ne semble pas changer de futur. 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 de démarrage cruciale.
Toutefois, ce problème n'est pas insoluble. Plusieurs options s'offrent à vous:
- Utilisez l'outil de couverture des outils pour les développeurs Chrome pour 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 du 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 sera toujours nécessaire pour certaines fonctionnalités à l'avenir. Vous pouvez déplacer ce code dans un groupe distinct via la scission du code.
- Si vous utilisez un gestionnaire de balises, vérifiez régulièrement vos balises pour vous assurer qu'elles sont optimisées, même si elles sont toujours utilisées. Vous pouvez effacer 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 volumineuses du rendu
JavaScript n'est pas la seule chose qui peut affecter la réactivité de votre site Web. L'affichage peut représenter un travail coûteux en soi. Lorsque de grandes mises à jour de l'affichage se produisent, elles peuvent interférer avec la capacité de votre site Web à répondre aux entrées utilisateur.
L'optimisation de l'affichage n'est pas un processus simple, et elle dépend souvent de ce que vous essayez d'obtenir. Malgré tout, vous pouvez prendre certaines mesures pour vous assurer que les mises à jour de l'affichage sont raisonnables et qu'elles ne soient pas trop longues:
- É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 exclusivement réservées aux tâches qui impliquent des mises à jour de l'affichage. - Limitez la taille de votre DOM. 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 DOM très volumineux, le travail nécessaire pour recalculer sa mise en page peut augmenter considérablement.
- Utilisez le confinement CSS. Le confinement CSS repose sur la propriété CSS
contain, qui fournit des instructions au navigateur sur la mise en page du conteneur sur lequel la propriétécontainest définie, y compris l'isolement de la portée de la mise en page et de l'affichage à 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 d'affichage qui ne sont pas nécessaires.
Conclusion
L'amélioration des performances d'une page peut sembler ardue, d'autant plus que de nombreuses recommandations en ligne sont à prendre en compte. Toutefois, en vous concentrant sur ces recommandations, vous pouvez aborder le problème de façon ciblée et ciblée, et ainsi faire évoluer les 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 plus loin, consultez les guides d'optimisation suivants:
Nous vous souhaitons une nouvelle année et un Web plus rapide pour tous ! Que vos sites soient rapides pour vos utilisateurs de tout ce qui compte le plus.
Photo par Devin Avery