Improve Page Performance with content-visibility

With the advancements in both technical capability and audience expectations, web pages nowadays have become heavier, and can have pretty massive payloads.
There are many factors at play: ever‑increasing numbers of detailed imagery, resource‑intensive CSS layouts that require the browser to work hard and calculate where everything needs to sit and how it should render on the screen ‑ even when those elements are far, far down the page, outside of the viewport ‑ can really bog down not only the initial load time but also page performance as you scroll. We've all experienced web pages that appear to lag a half‑second behind the scroll wheel whilst our browser struggles to keep up.
This is particularly obvious when dealing with a page that automatically loads new content as you scroll down, for instance, starting off with normal scrolling performance but getting jankier, choppier, and laggier as more and more content is loaded in; not to mention giving Chrome an excuse to chew up more of your system resources.
One tool that can reduce this rendering work is content-visibility.
What is the Content Visibility Property in CSS?
content-visibility is a CSS property that allows you to alter the rendering behaviour of the browser. Using it, you can skip rendering of layouts and elements until they're in (or about to be in) the viewport and need to be viewed. This means that your initial page load can be sped up, only using client‑side resources to render what's visible rather than wasting resources on the stuff that isn't.
There are three settings for the content-visibility parameter (aside from the usual global options like inherit or initial). These are:
visible
Essentially, this is the default setting. The element will be rendered as usual.
hidden
The element's contents are skipped, but the element itself still generates a box.
auto
This is where the property becomes particularly useful. With content-visibility: auto, the browser can skip rendering work for content that is not currently relevant to the user, such as an off‑screen section. To reserve space when size containment makes that content unavailable for sizing, give contain-intrinsic-size a sensible fallback length, such as 750px or 75rem. Percentages are not valid. The property also applies to other size‑contained elements, including those using contain: size; it is not limited to content-visibility. Check the estimate against the real content so that rendering it does not cause an unexpected layout shift.
For example, these length values are valid:
contain-intrinsic-size: 750px;
contain-intrinsic-size: 75rem;Compatibility
Check support in the browsers your project needs. Browsers that do not recognise content-visibility ignore the declaration, so the page must remain usable without the skipped rendering work. Treat it as a progressive enhancement and test the ordinary layout too.
Reserve the Space You Skip
content-visibility: auto can save rendering work, but the browser still needs a sensible idea of the skipped element's size. Pair it with contain-intrinsic-size where appropriate, otherwise the page can shift when the browser eventually renders the content.
That trade‑off is especially relevant for long article bodies, product listings and repeated panels below the fold. The property is useful, but it is not a free replacement for measuring layout stability.
Accessibility and Rendering Caveats
Do not use content-visibility to hide interactive state that should be available immediately. Test find‑in‑page, focus movement and assistive technology behaviour in the browsers you support. If the content is important to the current task, delaying its rendering may work against the user even if it improves a metric.
The Wrap‑up
content-visibility is a useful option for complex pages, but it still needs testing against the layout‑stability and accessibility cautions above. Support alone does not make it the right choice for every section.
Postscript
July 2026: content-visibility reached Baseline 2024 and now works across current Chrome, Edge, Firefox and Safari releases. This coverage is much broader than it was when the article appeared. The sizing, focus, find‑in‑page and assistive‑technology checks above still decide whether the optimisation is suitable for a particular section.