Découvrez comment éviter les décalages soudains de mise en page pour améliorer l'expérience utilisateur
Le CLS (Cumulative Layout Shift) est l'une des trois métriques Core Web Vitals. Il mesure l'instabilité du contenu en combinant la quantité de contenu visible qui a été déplacée dans la fenêtre d'affichage et la distance parcourue par les éléments concernés.
Les décalages de mise en page peuvent distraire les utilisateurs. Imaginez que vous commenciez à lire un article et que soudainement, des éléments se déplacent sur la page, ce qui vous déstabilise et vous oblige à retrouver votre place. Ce problème est très courant sur le Web, par exemple lorsque vous lisez les actualités ou essayez de cliquer sur les boutons "Rechercher" ou "Ajouter au panier". Ces expériences sont visuellement choquantes et frustrantes. Ils sont souvent dus à des éléments visibles qui doivent se déplacer, car un autre élément a été soudainement ajouté à la page ou redimensionné.
Afin d'offrir une expérience utilisateur de qualité, les sites doivent s'efforcer d'avoir un CLS de 0,1 ou moins pour au moins 75% des visites de page.
Contrairement aux autres Core Web Vitals, qui sont des valeurs temporelles mesurées en secondes ou en millisecondes, le score CLS est une valeur sans unité basée sur un calcul de la quantité de contenu qui change et de son ampleur.
Dans ce guide, nous allons vous expliquer comment optimiser les causes courantes de décalages de mise en page.
Voici les causes les plus courantes d'un mauvais CLS:
- Images sans dimensions.
- Annonces, éléments intégrés et iFrames sans dimensions
- Contenu injecté dynamiquement, comme des annonces, des éléments intégrés et des iFrames, sans dimensions
- Polices Web
Comprendre les causes des décalages de mise en page
Avant de chercher des solutions aux problèmes CLS courants, il est important de comprendre votre score CLS et d'identifier l'origine des variations.
CLS dans les outils de laboratoire par rapport au terrain
Il est courant d'entendre des développeurs penser que le CLS mesuré par le rapport sur l'expérience utilisateur Chrome (CrUX) est incorrect, car il ne correspond pas au CLS qu'ils mesurent à l'aide de Chrome DevTools ou d'autres outils de laboratoire. Les outils de l'atelier sur les performances Web, tels que Lighthouse, n'affichent pas toujours le CLS complet d'une page, car ils effectuent généralement un simple chargement de la page pour mesurer certaines métriques de performances Web et fournir des conseils. Toutefois, les parcours utilisateur Lighthouse vous permettent d'aller au-delà de l'audit de chargement de page par défaut.
CrUX est l'ensemble de données officiel du programme Web Vitals. Pour cela, le CLS est mesuré tout au long de la durée de vie de la page, et pas seulement pendant le chargement initial de la page, que les outils de laboratoire mesurent généralement.
Les décalages de mise en page sont très courants lors du chargement de la page, car toutes les ressources nécessaires sont récupérées pour afficher la page initialement. Toutefois, ils peuvent également se produire après le chargement initial. De nombreux décalages post-chargement peuvent se produire à la suite d'une interaction utilisateur et seront donc exclus du score CLS, car il s'agit de décalages attendus, à condition qu'ils se produisent dans les 500 millisecondes suivant cette interaction.
Toutefois, d'autres décalages post-chargement inattendus par l'utilisateur peuvent être inclus en l'absence d'interaction éligible. Par exemple, si vous faites défiler la page et que le contenu chargé de manière différée est chargé, ce qui entraîne des décalages. Le CLS post-chargement est aussi souvent dû aux interactions des transitions, par exemple dans les applications monopages, qui prennent plus de temps que le délai de grâce de 500 millisecondes.
PageSpeed Insights affiche à la fois le CLS perçu par l'utilisateur à partir d'une URL dans la section "Découvrez ce que vos utilisateurs réels vivent" et le CLS de chargement en laboratoire dans la section "Diagnostiquer les problèmes de performances". Les différences entre ces valeurs sont probablement dues au CLS post-chargement.
Identifier les problèmes liés au CLS de chargement
Lorsque les scores CLS CrUX et Lighthouse de PageSpeed Insights sont globalement alignés, cela signifie généralement qu'un problème de CLS de chargement a été détecté par Lighthouse. Dans ce cas, Lighthouse vous aidera à effectuer deux audits pour vous fournir plus d'informations sur les images qui provoquent un CLS en raison de la largeur et de la hauteur manquantes. Il listera également tous les éléments qui ont été décalés lors du chargement de la page, ainsi que leur contribution au CLS. Vous pouvez afficher ces audits en filtrant les audits CLS:
Le panneau "Performances" des outils de développement met également en évidence les décalages de mise en page dans la section Expérience. La vue Récapitulatif d'un enregistrement Layout Shift inclut le score cumulé de décalage de mise en page, ainsi qu'un calque rectangulaire indiquant les régions concernées. Cela est particulièrement utile pour obtenir plus de détails sur les problèmes de CLS de chargement, car ils sont facilement reproduits avec un profil de performances de recharge.
<ph type="x-smartling-placeholder">Layout Shift. Cliquez sur l'enregistrement pour examiner les éléments concernés en affichant des informations telles que les entrées "depuis" et "vers" dans cette image.
Identifier les problèmes de CLS post-chargement
Un désaccord entre les scores CLS de CrUX et de Lighthouse indique souvent un CLS post-chargement. Ces variations peuvent être difficiles à repérer sans données réelles. Pour en savoir plus sur la collecte de données sur le terrain, consultez Mesurer les éléments CLS sur le terrain.
L'extension Chrome Web Vitals vous permet de surveiller le CLS lorsque vous interagissez avec une page, soit dans un affichage en plein écran, soit dans la console, où vous pouvez obtenir plus d'informations au-dessus des éléments déplacés.
Au lieu d'utiliser l'extension, vous pouvez parcourir votre page Web tout en enregistré les décalages de mise en page à l'aide d'un outil Performance Observer collé dans la console.
Après avoir configuré la surveillance des quarts, vous pouvez essayer de répliquer les problèmes CLS post-chargement. Le CLS se produit souvent lorsque l'utilisateur fait défiler une page, lorsque le contenu à chargement différé se charge entièrement sans espace qui lui est réservé. Le décalage du contenu lorsque l'utilisateur maintient le pointeur sur celui-ci est une autre cause courante du CLS post-chargement. Tout changement de contenu lors de l'une de ces interactions est considéré comme inattendu, même s'il se produit dans les 500 millisecondes.
Pour en savoir plus, consultez Déboguer les décalages de mise en page.
Une fois que vous avez identifié les causes courantes du CLS, vous pouvez également utiliser le mode de parcours utilisateur sur les périodes de temps de Lighthouse pour vous assurer que les flux utilisateur classiques ne régressent pas en introduisant des décalages de mise en page.
Mesurer les éléments CLS dans le champ
Le suivi du CLS sur le terrain peut s'avérer très utile pour déterminer dans quelles circonstances le CLS se produit et pour identifier les causes possibles. Comme la plupart des outils de laboratoire, les outils sur le terrain ne mesurent que les éléments qui ont changé, mais cela fournit généralement suffisamment d'informations pour identifier la cause. Vous pouvez également utiliser les mesures du champ CLS pour déterminer les problèmes à résoudre en priorité.
La bibliothèque web-vitals inclut des fonctions d'attribution qui vous permettent de recueillir ces informations supplémentaires. Pour en savoir plus, consultez Déboguer les performances sur le terrain. D'autres fournisseurs de RUM ont également commencé à collecter et à présenter ces données de la même manière.
Causes courantes du CLS
Une fois que vous avez identifié les causes du CLS, vous pouvez commencer à résoudre les problèmes. Dans cette section, nous allons vous présenter les raisons les plus courantes de ce problème et les mesures que vous pouvez prendre pour l'éviter.
Images sans dimensions
Incluez toujours les attributs de taille width et height dans vos images et vos éléments vidéo. Vous pouvez également réserver l'espace nécessaire avec CSS aspect-ratio ou un code similaire. Cette approche garantit que le navigateur peut allouer la quantité d'espace appropriée dans le document pendant le chargement de l'image.
Historique des attributs width et height sur les images
Aux débuts du Web, les développeurs ajoutaient les attributs width et height à leurs balises <img> pour s'assurer que l'espace alloué sur la page était suffisant avant que le navigateur ne commence à récupérer les images. Cela permet de réduire la refonte et la mise en page.
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">
Dans cet exemple, width et height n'incluent pas d'unités. Ces "pixels" pour garantir que le navigateur réserve une zone de 640 x 360 dans la mise en page. L'image est étirée pour s'adapter à cet espace, que les dimensions réelles y correspondent ou non.
Lorsque le Responsive Web Design a été introduit, les développeurs ont commencé à omettre width et height et à utiliser CSS pour redimensionner les images à la place :
img {
width: 100%; /* or max-width: 100%; */
height: auto;
}
Toutefois, comme la taille de l'image n'est pas spécifiée, aucun espace ne peut lui être alloué tant que le navigateur ne commence pas à la télécharger et ne peut pas déterminer ses dimensions. Lorsque les images se chargent, le texte est décalé vers le bas de la page pour les laisser de la place, ce qui crée une expérience utilisateur confuse et frustrante.
C'est là qu'intervient le format. Le rapport hauteur/largeur d'une image correspond au rapport entre sa largeur et sa hauteur. Cette valeur est généralement exprimée sous la forme de deux nombres séparés par le signe deux-points (par exemple, 16:9 ou 4:3). Pour un format x:y, l'image mesure x unités de large et y unités de haut.
Cela signifie que si nous connaissons l'une des dimensions, nous pouvons déterminer l'autre. Pour un format 16:9 :
- Si puppy.jpg a une hauteur de 360 px, la largeur est de 360 x (16 / 9) = 640 px.
- Si puppy.jpg a une largeur de 640 px, la hauteur est de 640 x (9 / 16) = 360 px.
Connaître les proportions d'une image permet au navigateur de calculer et de réserver un espace suffisant pour la hauteur et la zone associée.
Bonnes pratiques modernes pour définir les dimensions des images
Étant donné que les navigateurs modernes définissent le format par défaut des images en fonction des attributs width et height de l'image, vous pouvez éviter les décalages de mise en page en définissant ces attributs sur l'image et en incluant le CSS précédent dans votre feuille de style.
<!-- set a 640:360 i.e a 16:9 aspect ratio -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">
Tous les navigateurs ajoutent ensuite un format par défaut en fonction des attributs width et height existants de l'élément.
Cela permet de calculer un format basé sur les attributs width et height avant le chargement de l'image. Ces informations sont fournies au tout début du calcul de la mise en page. Dès qu'une image doit avoir une certaine largeur (par exemple, width: 100%), le format est utilisé pour calculer la hauteur.
Cette valeur aspect-ratio est calculée par les principaux navigateurs lors du traitement du code HTML, et non avec une feuille de style par défaut pour l'user-agent (consultez cet article pour en savoir plus). La valeur est donc affichée un peu différemment. Par exemple, Chrome l'affiche comme suit dans la section "Styles" du panneau "Élément" :
img[Attributes Style] {
aspect-ratio: auto 640 / 360;
}
Safari se comporte de la même manière, en utilisant une source de style Attributs HTML. Firefox n'affiche pas du tout ce aspect-ratio calculé dans son panneau Inspector (Inspecteur), mais il l'utilise pour la mise en page.
La partie auto du code précédent est importante, car elle permet aux dimensions de l'image de remplacer le format par défaut après le téléchargement de l'image. Si les dimensions de l'image sont différentes, cela entraîne toujours un léger décalage de la mise en page après le chargement de l'image. Toutefois, cela garantit que le format de l'image est toujours utilisé lorsqu'il est disponible, au cas où le code HTML serait incorrect. Même si le format réel est différent du format par défaut, le décalage de mise en page est moindre par rapport à la taille par défaut 0x0 d'une image sans dimensions fournies.
Pour une présentation détaillée des formats et une réflexion plus poussée sur les images responsives, consultez la section sur le chargement de pages sans à-coups avec les formats multimédias.
Si votre image se trouve dans un conteneur, vous pouvez utiliser CSS pour la redimensionner en fonction de la largeur du conteneur. Nous définissons height: auto; pour éviter d'utiliser une valeur fixe pour la hauteur de l'image.
img {
height: auto;
width: 100%;
}
Qu'en est-il des images responsives ?
Lorsque vous travaillez avec des images responsives, srcset définit les images que le navigateur peut sélectionner et la taille de chacune d'elles. Pour que les attributs de largeur et de hauteur <img> puissent être définis, chaque image doit utiliser le même format.
<img
width="1000"
height="1000"
src="puppy-1000.jpg"
srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
alt="Puppy with balloons"
/>
Vos images les formats peuvent également varier en fonction direction artistique. Par exemple, vous pouvez inclure le plan recadré d'une image pour les images et afficher l'image complète sur un ordinateur:
<picture>
<source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" />
<source media="(min-width: 800px)" srcset="puppy-800w.jpg" />
<img src="puppy-800w.jpg" alt="Puppy with balloons" />
</picture>
Chrome, Firefox et Safari acceptent désormais de définir width et height sur les éléments <source> d'un élément <picture> donné :
<picture>
<source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" width="480" height="400" />
<source media="(min-width: 800px)" srcset="puppy-800w.jpg" width="800" height="400" />
<img src="puppy-800w.jpg" alt="Puppy with balloons" width="800" height="400" />
</picture>
Annonces, éléments intégrés et autres contenus chargés tardivement
Les images ne sont pas le seul type de contenu pouvant entraîner des décalages de mise en page. Les annonces, les éléments intégrés, les iFrames et les autres contenus injectés dynamiquement peuvent tous entraîner un décalage du contenu qui apparaît après eux, ce qui augmente votre CLS.
Les annonces sont l'un des principaux facteurs de décalage de mise en page sur le Web. Les réseaux publicitaires et les éditeurs acceptent souvent les tailles d'annonces dynamiques. Les tailles d'annonces augmentent les performances et les revenus, car les taux de clics sont plus élevés et les annonces en concurrence lors des enchères sont plus nombreuses. Malheureusement, cela peut entraîner une expérience utilisateur non optimale, car les annonces font défiler le contenu visible que vous consultez vers le bas de la page.
Les widgets intégrés vous permettent d'inclure du contenu Web portable sur votre page, comme des vidéos YouTube, des cartes Google Maps et des posts sur les réseaux sociaux. Toutefois, la plupart du temps, ces widgets ne détectent pas la taille de leur contenu avant de se charger. Par conséquent, les plates-formes proposant des intégrations ne réservent pas toujours de l'espace pour leurs widgets, ce qui entraîne des décalages de mise en page lors de leur chargement final.
Les techniques à appliquer sont toutes similaires. Les principales différences sont le niveau de contrôle dont vous disposez sur le contenu inséré. Si cet élément est inséré par un tiers (par exemple, un partenaire publicitaire), vous ne connaissez peut-être pas la taille exacte du contenu qui sera inséré, et vous ne pourrez peut-être pas contrôler les décalages de mise en page qui se produisent dans ces intégrations.
Réserver de l'espace pour les contenus à chargement tardif
Lorsque vous placez du contenu à chargement tardif dans le flux de contenu, vous pouvez éviter les décalages de mise en page en leur réservant de l'espace dans la mise en page initiale.
Vous pouvez ajouter une règle CSS min-height pour réserver de l'espace ou utiliser la propriété CSS aspect-ratio de la même manière que les navigateurs l'utilisent automatiquement pour les images aux dimensions fournies.
Vous devrez peut-être tenir compte de légères différences de tailles d'annonces ou d'espaces réservés entre les différents facteurs de forme à l'aide de requêtes multimédias.
Pour les contenus dont la hauteur n'est pas fixe, comme les annonces, vous ne pourrez peut-être pas réserver l'espace exact nécessaire pour éliminer complètement ce décalage. Si une annonce de taille inférieure est diffusée, l'éditeur peut appliquer un style à un conteneur plus grand pour éviter les décalages de mise en page. Il peut également choisir la taille la plus probable pour l'espace publicitaire en fonction des données historiques. L'inconvénient de cette approche est qu'elle augmente la quantité d'espace vide sur la page.
Vous pouvez également définir la taille initiale sur la plus petite taille qui sera utilisée et accepter un certain niveau de décalage pour les contenus de plus grande taille. Comme suggéré précédemment, l'utilisation de min-height permet à l'élément parent de s'agrandir selon les besoins tout en réduisant l'impact des décalages de mise en page par rapport à la taille par défaut de 0 px d'un élément vide.
Essayez d'éviter de réduire l'espace réservé en affichant un espace réservé si, par exemple, aucune annonce n'est renvoyée. Supprimer l'espace réservé aux éléments peut entraîner autant de CLS que l'insertion de contenu.
Placer le contenu à chargement différé plus bas dans la fenêtre d'affichage
Le contenu injecté de manière dynamique plus près du haut de la fenêtre d'affichage entraîne généralement des décalages de mise en page plus importants que le contenu injecté plus bas dans la fenêtre d'affichage. Toutefois, l'injection de contenu n'importe où dans la fenêtre d'affichage entraîne toujours un léger décalage. Si vous ne pouvez pas réserver d'espace pour le contenu injecté, nous vous recommandons de le placer plus tard sur la page afin de réduire l'impact sur son CLS.
Éviter d'insérer du nouveau contenu sans intervention de l'utilisateur
Vous avez probablement déjà constaté des décalages de mise en page en raison d'une interface utilisateur qui s'affiche en haut ou en bas du viewport lorsque vous essayez de charger un site. Comme pour les annonces, cela se produit souvent avec les bannières et les formulaires qui déplacent le reste du contenu de la page:
Si vous devez afficher ces types d'affordances d'interface utilisateur, réservez suffisamment d'espace dans le viewport à l'avance (par exemple, à l'aide d'un espace réservé ou d'une interface utilisateur squelette) afin que, lors du chargement, le contenu de la page ne soit pas déplacé de manière surprenante. Vous pouvez également vous assurer que l'élément ne fait pas partie du flux de documents en superposant le contenu lorsque cela est pertinent. Pour obtenir des recommandations supplémentaires sur ces types de composants, consultez l'article Bonnes pratiques concernant les avis sur les cookies.
Dans certains cas, l'ajout de contenu de manière dynamique est un élément important de l'expérience utilisateur. Par exemple, lorsque vous ajoutez des produits à une liste d'articles ou que vous modifiez le contenu d'un flux en direct. Il existe plusieurs façons d'éviter des décalages de mise en page inattendus dans ces cas:
- Remplacez l'ancien contenu par le nouveau dans un conteneur de taille fixe ou utilisez un carrousel et supprimez l'ancien contenu après la transition. N'oubliez pas de désactiver tous les liens et les commandes jusqu'à la fin de la transition pour éviter les clics ou les pressions accidentels pendant l'importation du nouveau contenu.
- Demandez à l'utilisateur de lancer le chargement du nouveau contenu afin qu'il ne soit pas surpris par le changement (par exemple, avec un bouton "Charger plus" ou "Actualiser"). Il est recommandé de précharger le contenu avant toute interaction de l'utilisateur pour qu'il s'affiche immédiatement. Pour rappel, les décalages de mise en page qui se produisent dans les 500 millisecondes après l'entrée utilisateur ne sont pas comptabilisés dans le CLS.
- Chargez le contenu en dehors de l'écran et affichez une notification indiquant à l'utilisateur qu'il est disponible (par exemple, avec un bouton "Défiler vers le haut").
Animations
Les modifications apportées aux valeurs des propriétés CSS peuvent nécessiter que le navigateur réagisse à ces changements. Certaines valeurs, telles que box-shadow et box-sizing, déclenchent une nouvelle mise en page, une nouvelle peinture et une nouvelle composition. La modification des propriétés top et left entraîne également des décalages de mise en page, même lorsque l'élément en cours de déplacement se trouve sur son propre calque. Évitez les animations à l'aide de ces propriétés.
D'autres propriétés CSS peuvent être modifiées sans déclencher de refontes. Par exemple, vous pouvez utiliser des animations transform pour traduire, ajuster, faire pivoter ou déformer des éléments.
Les animations composées à l'aide de translate ne peuvent pas avoir d'impact sur les autres éléments. Elles ne sont donc pas comptabilisées dans le CLS. Les animations non composées n'entraînent pas non plus de remise en page. Pour en savoir plus sur les propriétés CSS qui déclenchent des décalages de mise en page, consultez la section Animations hautes performances.
Polices Web
Le téléchargement et l'affichage des polices Web sont généralement gérés de deux manières différentes avant le téléchargement de la police Web :
- La police de remplacement est remplacée par la police Web, ce qui entraîne un flash de texte non stylisé (FOUT).
- Le texte "invisible" est affiché à l'aide de la police de remplacement jusqu'à ce qu'une police Web soit disponible et que le texte soit rendu visible (FOIT, flash de texte invisible).
Les deux approches peuvent entraîner des décalages de mise en page. Même si le texte est invisible, il est toujours disposé à l'aide de la police de remplacement. Ainsi, lorsque la police Web est chargée, le bloc de texte et le contenu environnant se déplacent de la même manière que pour la police visible.
Les outils suivants peuvent vous aider à minimiser le décalage du texte:
font-display: optionalpeut éviter une nouvelle mise en page, car la police Web n'est utilisée que si elle est disponible au moment de la mise en page initiale.- Assurez-vous que la police de remplacement appropriée est utilisée. Par exemple, l'utilisation de
font-family: "Google Sans", sans-serif;garantit que la police de remplacementsans-serifdu navigateur est utilisée pendant le chargement de"Google Sans". Si vous ne spécifiez pas de police de remplacement à l'aide defont-family: "Google Sans", la police par défaut est utilisée. Dans Chrome, il s'agit de "Times", une police Serif qui est moins adaptée que la policesans-serifpar défaut. - Réduisez les différences de taille entre la police de remplacement et la police Web à l'aide des nouvelles API
size-adjust,ascent-override,descent-overrideetline-gap-override, comme indiqué dans l'article Amélioration des polices de remplacement. - L'API Font Loading peut réduire le temps nécessaire pour obtenir les polices nécessaires.
- Chargez les polices Web critiques le plus tôt possible à l'aide de
<link rel=preload>. Une police préchargée a plus de chances de répondre à la première peinture, auquel cas il n'y a pas de décalage de mise en page.
Consultez la section Bonnes pratiques concernant les polices pour découvrir d'autres bonnes pratiques concernant les polices.
Réduisez le CLS en vous assurant que les pages sont éligibles au cache amélioré
Une technique très efficace pour maintenir les scores CLS bas consiste à s'assurer que vos pages Web sont éligibles au cache amélioré (bfcache).
Le cache amélioré conserve les pages dans la mémoire du navigateur pendant une courte période après que vous avez quitté la page. Ainsi, si vous y revenez, elles seront restaurées exactement comme vous les aviez laissées. Cela signifie que la page entièrement chargée est disponible instantanément, sans aucun décalage normalement visible pendant le chargement pour l'une des raisons indiquées précédemment.
Bien que cela puisse toujours signifier que le chargement initial de la page rencontre des décalages de mise en page, lorsqu'un utilisateur revient sur les pages, il ne voit pas les mêmes changements de mise en page à plusieurs reprises. Vous devez toujours essayer d'éviter les décalages, même lors du chargement initial. Toutefois, lorsqu'il est plus difficile de résoudre complètement ce problème, vous pouvez au moins réduire l'impact en les évitant sur les navigations en cache amélioré.
Les navigations vers l'avant et vers l'avant sont courantes sur de nombreux sites. Par exemple, pour revenir à une page de contenu, à une page de catégorie ou aux résultats de recherche.
Lorsque cette fonctionnalité a été déployée dans Chrome, nous avons constaté des améliorations notables du CLS.
Le cache amélioré est utilisé par défaut par tous les navigateurs, mais certains sites ne peuvent pas en bénéficier pour diverses raisons. Consultez le guide concernant le cache amélioré pour découvrir comment tester et identifier les problèmes empêchant l'utilisation du cache amélioré. Vous pourrez ainsi vous assurer que vous exploitez pleinement cette fonctionnalité afin d'améliorer votre score CLS global pour votre site.
Conclusion
Il existe un certain nombre de techniques permettant d'identifier et d'améliorer le CLS, comme indiqué plus haut dans ce guide. Les Core Web Vitals incluent des tolérances. Même si vous ne pouvez pas éliminer complètement le CLS, l'utilisation de certaines de ces techniques devrait vous permettre de réduire son impact. Nous espérons que cela vous permettra de ne pas dépasser ces limites et d'offrir ainsi une meilleure expérience aux utilisateurs de votre site Web.