content-visibility for faster long pages

What it is

content-visibility: auto tells the browser: skip layout, style and paint work for this element until it is near the viewport. Long pages with many heavy sections (long-form articles, catalogue rows, chat transcripts, index pages of records) spend most of render time on sections nobody has scrolled to yet. With the property, the browser renders only the visible band and its neighbours, and the first paint and scroll interactions get faster.

A page element gets the treatment:

article section {
  content-visibility: auto;
  contain-intrinsic-size: auto 480px;
}

The contain-intrinsic-size value is not optional polish; it is the part that stops the page jumping. Without a hinted size, a skipped section has no height, the document keeps shrinking, and as you scroll the total height recalculates, which produces layout shift. Give each extended section a reasonable height estimate, for example auto 480px, or a two-value form matching your breakpoints.

Choose between the three values

• visible: the element renders normally. Use it to intentionally turn a section back on.
• auto: the browser skips the element when it is offscreen, then renders it on approach. This is the useful one.
• hidden: the element is laid out but not rendered and is skipped for find-in-page and find-and-click purposes; it is not a privacy feature and it does not collapse like display: none. Practical use is limited to demos.

Browser support (checked)

content-visibility works in all current engines. Chrome and Edge from 85 (2020/2021). Firefox enabled it by default in version 125 (2024). Safari shipped it in 18 (2024), with follow-up fixes in later releases, and web-status and stability notes continued through 2025-2026. A very old browser ignores the declaration and renders every section normally, so the gain is lost but the page still works. The property degrades gracefully: the risk is a slightly slower page, never a broken one.

Still, if you need a fallback path for very old browsers, gate the whole pattern behind @supports:

@supports (contain-intrinsic-size: 1px) {
  article section {
    content-visibility: auto;
    contain-intrinsic-size: auto 480px;
  }
}

The interaction to watch: CLS and find-in-page

The two operational risks:

1. Layout shift. A skipped section that gets rendered after the user has already read past it will move content. The defense is a contain-intrinsic-size estimate that matches the real section height, plus the knowledge that only true content-size changes cause an unexpected shift (see the CLS article for the real shift sources).
2. Find-in-page and navigation. If a section is skipped, the browser does not index its text for the relevant find functions until the element is visited. With auto this is mostly a background detail, because rendering happens on the way; it matters if you set content-visibility: hidden globally (not recommended), where find-in-page results can disappear. Browsers have fixed several of these edge cases in 2025 and 2026, but do not use hidden casually.

When it pays

• Lists of the same type, from search results to gallery grids, where each item is heavy.
• Long-form sites with extended, static sections below the fold.
• Data-heavy page components (large tables, comment threads, logs) at the bottom of an article.

Do not apply it to content above the fold, to content that changes size regularly, or to pieces a user needs to read instantly. It is a rendering strategy for the long tail of a page, not a substitute for a good critical path: the render-blocking resources article covers the head work that this property cannot fix.