What does content-visibility do?
A skipped block stays in the DOM and the accessibility tree, so find-in-page and the Tab key still reach it (MDN). The property takes three values:
visible: the default, no effect.auto: skip the work while the block is off screen. The one you want.hidden: likedisplay: none, hidden from find-in-page and screen readers until you change the value. Meant for tabs and panels.
How much faster does a page get?
A category page full of heavy cards does less rendering work; a lighter page gains nothing. I tested four long listing pages of three sites on 30 October 2026. Each loaded 15 times as served and 15 times with one rule on its cards, at phone size with a 4x slower CPU.
On two category pages of a promotional-products webshop, where every card carries dozens of elements, the rule took 13% of the rendering work away, about 40 ms on both pages. In the lab, the Largest Contentful Paint (LCP) also came a little earlier. On a nameplate shop and an estate agent's property list, whose cards are lighter, nothing changed beyond the noise between runs.
Lab test, 30 October 2026.
It won't fix a slow LCP caused by a big image or a slow server. Images in a skipped block still download, too; lazy loading handles those.
content-visibility: auto is never a miracle cure, but it's a one-liner. Check that it doesn't cause layout shifts, set the height right, and within ten minutes you're faster. That's how it often goes with Core Web Vitals: death by a thousand cuts. Take 20 ms off ten times and you're 200 ms faster.
Where should I use it, and why does my scrollbar jump?
Use it on big, repeated blocks below the first screen: the cards of a category page, comments, related products. Keep it off the first screen and the LCP element: nothing to skip there. And don't put it on everything: auto clips whatever sticks out of the block, like a dropdown hanging over the edge (MDN). A site crawl finds the long templates.
The scrollbar jumps because a skipped block counts as nearly empty, so the page grows at the last moment. One line fixes it: contain-intrinsic-size gives the block a placeholder size, and auto keeps the real size once drawn. On the promotional-products shop my placeholder was a little taller than a card on a phone, so its pages counted 640 to 760 px too long.
``css .product-card { content-visibility: auto; contain-intrinsic-size: auto 380px; } ``
My page on element render delay has more rules, for comments and related products.
Does it work in every browser?
It works in every current major browser: since 15 September 2025 it's Baseline "newly available". Some pages say 2024 because Safari 18 already drew it, but its find-in-page missed skipped text. Older browsers skip the line: no fallback needed.
Does Google still see the content?
Yes, because nothing is removed or loaded later. Google renders each page in a headless Chromium and "uses the rendered HTML to index the page", and the text is in that HTML. Lazy loading with JavaScript is riskier, since Google doesn't interact with the page and can miss what loads on scroll.
Nor is auto hidden text: visitors see it as they scroll. hidden, like display: none, is fine for tabs and accordions a visitor opens (spam policies). What Google calls hidden text is text kept from visitors only to rank.