Wat doet content-visibility?
Een overgeslagen blok blijft in de DOM en de accessibility tree, dus met zoeken op de pagina en de Tab-toets bereik je het nog steeds (MDN). De eigenschap kent drie waarden:
visible: de standaardwaarde, geen effect.auto: slaat het werk over zolang het blok buiten beeld is. Deze wil je.hidden: net alsdisplay: noneverborgen voor zoeken op de pagina en screenreaders tot je de waarde aanpast. Bedoeld voor tabbladen en panelen.
Hoeveel sneller wordt een pagina?
Een categoriepagina vol zware kaarten kost minder renderwerk; een lichtere pagina wint er niets mee. Op 30 oktober 2026 testte ik vier lange overzichtspagina's van drie sites. Elke pagina laadde ik 15 keer ongewijzigd en 15 keer met één regel op de kaarten, op telefoonformaat met een 4x tragere CPU.
Op twee categoriepagina's van een webshop voor relatiegeschenken, waar elke kaart tientallen elementen bevat, haalde de regel 13% van het renderwerk weg, zo'n 40 ms op beide pagina's. In het lab kwam ook de Largest Contentful Paint (LCP) iets eerder. Bij een naambordjeswinkel en het woningaanbod van een makelaar, waar de kaarten lichter zijn, veranderde er niets buiten de ruis tussen metingen.
Labtest, 30 oktober 2026.
Een trage LCP door een grote afbeelding of een trage server los je er niet mee op. Afbeeldingen in een overgeslagen blok downloadt de browser ook nog steeds; daarvoor heb je lazy loading.
content-visibility: auto is nooit een wondermiddel, maar wel een oneliner. Controleer of het geen layout shifts veroorzaakt, zet de hoogte goed en binnen tien minuten ben je sneller. Zo gaat het vaak bij Core Web Vitals: een optelsom van kleine vertragingen. Haal er tien keer 20 ms af en je bent 200 ms sneller.
Waar gebruik ik het, en waarom verspringt mijn scrollbalk?
Gebruik het op grote, herhaalde blokken onder het eerste scherm: de kaarten van een categoriepagina, reacties, gerelateerde producten. Laat het weg op het eerste scherm en het LCP-element: daar valt niets over te slaan. En zet het niet overal op: auto kapt alles af wat buiten het blok steekt, zoals een dropdown die over de rand hangt (MDN). Met een site crawl vind je de lange templates.
De scrollbalk verspringt omdat een overgeslagen blok als bijna leeg meetelt, waardoor de pagina op het laatste moment langer wordt. Eén regel lost dat op: contain-intrinsic-size geeft het blok een placeholder-formaat, en auto behoudt het echte formaat zodra het getekend is. Bij de webshop voor relatiegeschenken was mijn placeholder iets hoger dan een kaart op een telefoon, waardoor de pagina's 640 tot 760 px te lang uitvielen.
``css .product-card { content-visibility: auto; contain-intrinsic-size: auto 380px; } ``
Op mijn pagina over element render delay staan meer regels, voor reacties en gerelateerde producten.
Werkt het in elke browser?
Het werkt in elke grote moderne browser: sinds 15 september 2025 is het Baseline "newly available". Sommige pagina's noemen 2024 omdat Safari 18 het al renderde, maar zoeken op de pagina miste daar overgeslagen tekst. Oudere browsers slaan de regel over: geen fallback nodig.
Ziet Google de content nog steeds?
Ja, want er wordt niets verwijderd of later ingeladen. Google rendert elke pagina in een headless Chromium en "gebruikt de gerenderde HTML om de pagina te indexeren", en de tekst staat in die HTML. Lazy loading met JavaScript is risicovoller, omdat Google geen interactie heeft met de pagina en kan missen wat bij het scrollen laadt.
Ook is auto geen verborgen tekst: bezoekers zien die tijdens het scrollen. hidden is net als display: none prima voor tabbladen en accordeons die een bezoeker opent (spambeleid). Wat Google verborgen tekst noemt, is tekst die je voor bezoekers verbergt puur om te ranken.