Découvrez comment éviter les changements de mise en page soudains pour améliorer l'expérience utilisateur.
Le Cumulative Layout Shift (CLS) 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. Elles surviennent souvent lorsque des éléments visibles sont forcés à se déplacer, car un autre élément a été ajouté ou redimensionné de manière soudaine à la page.
Pour offrir une expérience utilisateur de qualité, les sites doivent s'efforcer d'obtenir un CLS de 0,1 ou moins pour au moins 75% des visites de page.
Contrairement aux autres métriques Core Web Vitals, qui sont des valeurs basées sur le temps mesurées en secondes ou en millisecondes, le score CLS est une valeur sans unité basée sur le calcul de la quantité de contenu qui se déplace et de la distance parcourue.
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 CLS faible:
- 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 commencer à chercher des solutions aux problèmes CLS courants, il est important de comprendre votre score CLS et d'où viennent les changements.
CLS dans les outils d'atelier et sur le 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.
Le CrUX est l'ensemble de données officiel du programme Web Vitals. Pour cette raison, la CLS est mesurée tout au long de la durée de vie de la page, et pas seulement lors du chargement initial de la page que mesurent généralement les outils de laboratoire.
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 de chargement de CLS
Lorsque les scores CLS CrUX et Lighthouse de PageSpeed Insights sont globalement alignés, cela indique généralement qu'un problème de CLS de chargement a été détecté par Lighthouse. Dans ce cas, Lighthouse vous aidera à réaliser deux audits afin de fournir plus d'informations sur les images qui entraînent des CLS en raison d'une largeur et d'une hauteur manquantes. Il va également répertorier tous les éléments qui se sont décalés pendant le chargement de la page, ainsi que leur contribution au CLS. Pour les afficher, filtrez les audits sur les audits CLS:
Le panneau "Performances" de DevTools met également en évidence les changements de mise en page dans la section Expérience. La vue Summary (Résumé) d'un enregistrement Layout Shift inclut le score cumulé du décalage de mise en page, ainsi qu'une superposition rectangulaire montrant 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 peuvent être facilement répliqués avec un profil de performance d'actualisation.
Layout Shift s'affiche dans la section Expérience des résultats. 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. Il peut être difficile de détecter ces variations sans données sur le terrain. Pour en savoir plus sur la collecte de données de champ, consultez Mesurer les éléments CLS sur le terrain.
L'extension Chrome Web Vitals permet de surveiller le CLS lorsque vous interagissez avec une page, que ce soit dans un affichage tête haute ou dans la console, où vous pouvez obtenir plus de détails au-dessus des éléments décalés.
Au lieu d'utiliser l'extension, vous pouvez parcourir votre page Web tout en enregistrant les changements de mise en page à l'aide d'un observateur de performances 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é est chargé entièrement sans espace réservé. Le déplacement du contenu lorsque l'utilisateur maintient le pointeur dessus est une autre cause courante de 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 sur le terrain
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 contient des fonctions d'attribution qui vous permettent de collecter ces informations supplémentaires. Pour en savoir plus, consultez Déboguer les problèmes de 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 de 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 requis avec aspect-ratio CSS ou un élément similaire. Cette approche garantit que le navigateur peut allouer la bonne quantité d'espace dans le document pendant le chargement de l'image.
Historique des attributs width et height sur les images
Au début du Web, les développeurs ajoutaient des attributs width et height à leurs balises <img> pour s'assurer qu'un espace suffisant était alloué sur la page avant que le navigateur ne commence à extraire 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 dimensions "pixel" garantissent que le navigateur réserve une zone de 640 x 360 pixels dans la mise en page de la page. L'image s'étirait pour s'adapter à cet espace, que ses 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 format d'une image correspond à son rapport largeur/hauteur. Il est courant de voir ce rapport exprimé sous la forme de deux nombres séparés par un deux-points (par exemple, 16:9 ou 4:3). Au format x:y, l'image mesure x unités de large et y unités en hauteur.
Cela signifie que si l'une des dimensions est connue, l'autre peut être déterminée. 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 chiot.jpg a une largeur de 640 pixels, la hauteur est de 640 x (9 / 16) = 360 pixels
Connaître le format d'une image permet au navigateur de calculer et de réserver suffisamment d'espace 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 code 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 basé sur les 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, plutôt qu'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 décalage de mise en page après le chargement de l'image, mais cela garantit que le format de l'image sera toujours utilisé lorsqu'il sera disponible, au cas où le code HTML serait incorrect. Même si le format réel est différent du format par défaut, il entraîne moins de décalage de mise en page que la taille par défaut de 0x0 d'une image pour laquelle aucune dimension n'est fournie.
Pour en savoir plus sur les formats et les images responsives, consultez Chargement de page sans à-coups avec les formats multimédias.
Si votre image se trouve dans un conteneur, vous pouvez utiliser CSS pour redimensionner l'image 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 utilisez des images responsives, srcset définit les images que vous autorisez le navigateur à sélectionner, ainsi que la taille de chaque image. Pour vous assurer que les attributs de largeur et de hauteur <img> peuvent ê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"
/>
Les formats de vos images peuvent également varier en fonction de votre direction artistique. Par exemple, vous pouvez inclure un recadrage d'une image pour les vues d'écran étroites et afficher l'image complète sur 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, intégrations 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 améliorent les performances/revenus grâce à des taux de clics plus élevés et à un plus grand nombre d'annonces participant aux enchères. Malheureusement, cela peut entraîner une expérience utilisateur non optimale, car les annonces repoussent 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. Cependant, ces widgets ne savent souvent pas quelle est la taille de leur contenu avant de le 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 pour y faire face sont toutes similaires. La principale différence réside dans le contrôle que vous pouvez exercer sur le contenu qui sera inséré. Si ces éléments sont insérés par un tiers, comme un partenaire publicitaire, vous ne pourrez peut-être pas connaître la taille exacte du contenu qui sera inséré ni contrôler les éventuels changements de mise en page dans ces éléments intégrés.
Réserver de l'espace pour le contenu à charger plus tard
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.
Une approche consiste à ajouter une règle CSS min-height pour réserver de l'espace ou, pour les contenus responsifs tels que les annonces, à utiliser la propriété CSS aspect-ratio de la même manière que les navigateurs l'utilisent automatiquement pour les images dont les dimensions sont 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 le décalage de mise en page. 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 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 plus volumineux. L'utilisation de min-height, comme suggéré précédemment, permet à l'élément parent de croître si nécessaire, 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 un CLS tout aussi important que l'insertion de contenu.
Placer le contenu à chargement différé plus bas dans la fenêtre d'affichage
Les contenus injectés dynamiquement plus près du haut de la fenêtre d'affichage entraînent généralement des décalages de mise en page plus importants que les contenus injectés 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 décalage. Si vous ne pouvez pas réserver d'espace pour le contenu injecté, nous vous recommandons de le placer plus loin sur la page afin de réduire son impact sur le CLS.
Éviter d'insérer du contenu sans interaction 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 à l'avance dans la fenêtre d'affichage (par exemple, à l'aide d'un espace réservé ou d'une interface utilisateur squelette) afin que le contenu de la page ne se déplace pas étonnamment lors de son chargement. Vous pouvez également vous assurer que l'élément ne fait pas partie du flux du document 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. Dans ce cas, il existe plusieurs façons d'éviter les décalages de mise en page inattendus:
- 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 ce changement (par exemple, avec un bouton "Plus" ou "Actualiser"). Nous vous recommandons de précharger le contenu avant l'interaction de l'utilisateur afin qu'il s'affiche immédiatement. Pour rappel, les décalages de mise en page qui se produisent dans les 500 millisecondes après la saisie 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. Modifier les propriétés top et left entraîne également des décalages de mise en page, même lorsque l'élément déplacé se trouve sur son propre calque. Évitez d'utiliser ces propriétés pour l'animation.
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 ne provoquent pas non plus de recomposition. Pour en savoir plus sur les propriétés CSS qui déclenchent des décalages de mise en page, consultez 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 mis en page à l'aide de la police de remplacement. Par conséquent, lorsque la police Web est chargée, le bloc de texte et le contenu environnant sont décalés de la même manière que pour la police visible.
Les outils suivants peuvent vous aider à réduire 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 d'utiliser la police de remplacement approprié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 de chargement de polices peut réduire le temps nécessaire pour obtenir les polices nécessaires.
- Chargez les polices Web essentielles le plus tôt possible à l'aide de
<link rel=preload>. Une police préchargée a plus de chances de respecter 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é
Pour maintenir un score CLS faible, une technique très efficace consiste à vous assurer que vos pages Web sont éligibles au cache avant/arrière (bfcache).
Le bfcache conserve les pages dans la mémoire du navigateur pendant une courte période après que vous avez quitté la page. 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.
Cela signifie que le chargement initial de la page peut toujours rencontrer des changements de mise en page, mais qu'un utilisateur qui revient sur les pages ne voit pas les mêmes changements de mise en page de manière répétée. Vous devez toujours essayer d'éviter les décalages, même lors du chargement initial. Toutefois, lorsque cela est plus difficile à résoudre, vous pouvez au moins réduire leur impact en les évitant lors de toute navigation bfcache.
Les navigations vers l'avant et l'arrière 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 du cache amélioré pour en savoir plus sur la façon de tester et d'identifier les problèmes empêchant l'utilisation du cache amélioré afin de vous assurer que vous exploitez pleinement cette fonctionnalité pour améliorer le score CLS global de votre site.
Conclusion
Il existe plusieurs techniques pour identifier et améliorer le CLS, comme indiqué précédemment 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. Vous devriez ainsi respecter ces limites et offrir une meilleure expérience aux utilisateurs de votre site Web.