Content-Visibility Rendering
The content-visibility CSS property lets the browser skip rendering work for off-screen content, so a long page paints the visible portion fast and defers the rest until scrolled into view.
Definition
The content-visibility CSS property (with contain-intrinsic-size) tells the browser to skip layout, paint, and style for an element that is not visible, so that a page with thousands of rows renders the viewport quickly and the off-screen content is rendered lazily as the user scrolls, trading a small scroll-time cost for a large initial-render win.
Context and scope
Applied in long lists, virtualized pages, and any document where the content below the fold is expensive to render and the initial paint is the metric.
Common misconceptions
- content-visibility is just lazy rendering — it is lazy rendering with a browser primitive that handles layout and paint skip correctly, which hand-rolled lazy render does not
- It works without contain-intrinsic-size — without it the browser cannot size the skipped element, so the scrollbar jumps as content renders, hurting UX
Anti-patterns
- Applying content-visibility to every section including the above-fold one, skipping the render that the user is waiting for
- Setting contain-intrinsic-size to 0, so the scrollbar shows no content and the user thinks the page is empty
Related concepts
Authoritative source
https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility
What it is
The content-visibility CSS property (with contain-intrinsic-size) tells the browser to skip layout, paint, and style for an element that is not visible, so that a page with thousands of rows renders the viewport quickly and the off-screen content is rendered lazily as the user scrolls, trading a small scroll-time cost for a large initial-render win. Applied in long lists, virtualized pages, and any document where the content below the fold is expensive to render and the initial paint is the metric. The browser is a hostile, shared, single-threaded (for JS) environment where every millisecond of main-thread work is a millisecond the user cannot interact.
How it works
The rendering pipeline — style, layout, paint, composite — is incremental and can be invalidated by any DOM change. Performance work targets avoiding the expensive phases (layout, paint) and scheduling the rest in idle callbacks or off the main thread. Loading work orders resources by their impact on the critical path: render-blocking scripts are deferred, images get fetch priority, and the server pushes what the client will need next.
When to apply and pitfalls
Apply when user interaction latency or load performance has a measured business impact. The pitfall is micro-optimizing a function while the page ships a megabyte of render-blocking JavaScript — the dominant cost is structural, not algorithmic. Another is measuring in the ideal lab profile and missing the long-tail devices and networks where most users actually live.