La propriété content-visibility permet à l’auteur d’une page de contrôler si et comment le contenu d’un élément est rendu par le navigateur. C’est en substance ce qu’énonce la spécification CSS Containment du W3C à son sujet — une propriété apparue dans Chrome 85 en 2020, pensée pour accélérer le rendu de pages longues en différant le calcul de mise en page des sections situées hors du viewport visible.
Cette propriété soulève une question légitime dès qu’elle touche à l’indexation : un robot qui ne « scrolle » jamais réellement une page voit-il le même contenu qu’un visiteur humain ? La réponse tient à la distinction précise entre ce que content-visibility fait réellement, et ce qu’on lui prête parfois à tort.
Ce que fait réellement content-visibility: auto
Appliquée à un conteneur avec la valeur auto, cette propriété indique au navigateur de ne calculer la mise en page, le style et le rendu visuel du contenu que lorsque ce conteneur approche du viewport. Le contenu reste présent dans le DOM à tout moment : il ne s’agit ni d’un display: none, qui retire l’élément du rendu, ni d’un chargement différé qui retarderait l’injection du contenu dans la page. La donnée textuelle existe dès le chargement initial, seul son rendu visuel est temporisé.
C’est cette nuance qui distingue content-visibility du lazy-loading d’image classique : une image en loading="lazy" n’a littéralement pas encore de source chargée avant que le navigateur ne s’en approche, tandis qu’un paragraphe de texte sous content-visibility: auto est bel et bien présent dans le document, simplement pas encore mis en page visuellement.
Comment Googlebot traite cette propriété
Googlebot s’appuie, depuis l’évolution de son moteur de rendu annoncée par Google, sur une version proche de Chrome à jour pour exécuter le JavaScript et calculer le rendu final d’une page avant indexation. Ce moteur de rendu traite content-visibility exactement comme le ferait un navigateur Chrome ordinaire : le contenu du DOM est extrait pour l’indexation indépendamment de son état de rendu visuel temporisé, contrairement à ce que redoutent certains développeurs découvrant cette propriété.
Où le risque existe malgré tout
Le principal point de vigilance concerne non pas la propriété elle-même mais son association fréquente avec contain-intrinsic-size, utilisée pour réserver un espace approximatif avant le rendu réel du contenu, afin d’éviter un décalage de mise en page (CLS). Un mauvais réglage de cette taille intrinsèque peut, dans certains cas de figure impliquant du contenu généré dynamiquement en JavaScript après le chargement initial, retarder l’apparition effective du texte dans le DOM au-delà du délai que le moteur de rendu de Google consacre à une page avant capture, ce qui reste toutefois un problème de timing JavaScript plus qu’un problème propre à content-visibility.
Recommandations d’usage
- Réserver
content-visibility: autoaux sections longues et répétitives, comme les commentaires ou les blocs secondaires d’une page produit, plutôt qu’au contenu principal de l’article. - Toujours associer une valeur de
contain-intrinsic-sizeréaliste, proche de la hauteur réelle du contenu concerné, pour éviter tout décalage visuel perceptible. - Vérifier le rendu final avec l’outil d’inspection d’URL de Search Console, qui affiche une capture du rendu tel que Google l’a effectivement calculé, contenu temporisé inclus.
Support navigateur à prendre en compte
Au moment de la rédaction, le support de cette propriété reste inégal selon les navigateurs : Chrome et les navigateurs basés sur Chromium la prennent en charge depuis 2020, tandis que Firefox et Safari n’offrent qu’un support partiel ou expérimental. Cette disparité, documentée sur le site du Mozilla Developer Network, justifie un usage progressif, sans dépendance stricte du rendu visuel principal envers cette propriété.
Différer le calcul d’un rendu visuel n’équivaut jamais à masquer un contenu. Confondre les deux conduit à des précautions inutiles là où aucun risque d’indexation ne se pose réellement.
En résumé
content-visibility: auto accélère le rendu d’une page longue sans retirer son contenu du DOM, et le moteur de rendu utilisé par Googlebot la traite comme n’importe quel navigateur Chrome récent. Le vrai point d’attention se situe du côté de contain-intrinsic-size et de la stabilité visuelle qui en découle, pas du côté d’une hypothétique invisibilité aux yeux des robots.
