Can content-visibility Make Long Pages Render Faster?

Yes, content-visibility: auto can reduce rendering work on a long page by letting the browser skip off-screen content until it is needed. The benefit depends on how much work those sections would otherwise require.

I like the idea because the browser already knows which parts of the page matter to the current view. On a page that already feels quick, the change still needs a measured benefit.

Apply content-visibility to substantial sections

Start with meaningful sections rather than every element on the page:

<section class="article-section">
  <h2>A section farther down the page</h2>
  <p>The content stays in the document while its rendering can be deferred.</p>
</section>

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

The content-visibility documentation describes how auto allows the browser to skip rendering work when content is not relevant to the user. It can resume that work as the content becomes relevant, including when it approaches the viewport.

The size declaration gives skipped content a placeholder. The 600px value is an example, not a measurement of the short section above. A real page needs an estimate suited to its content.

The saving comes from rendering work

Skipping an off-screen subtree can avoid layout and painting work for its descendants. The browser decides when that content needs rendering; the property does not give the stylesheet an exact distance at which it must appear.

Google’s content-visibility explanation describes the containment behind that behaviour. The element itself still participates in the page layout, while some work inside it can wait.

Documentation pages with large examples and feeds containing substantial entries are reasonable candidates. A long document with mostly plain text may have little expensive work to postpone.

The property also serves a different purpose from lazy-loading resources. Treat it as a rendering decision, rather than assuming it will stop image downloads or application scripts.

Reserve space before the section is rendered

A skipped section still needs space in the document. An unsuitable estimate can change the page’s length as the browser replaces the placeholder with the rendered content.

The contain-intrinsic-size reference explains the auto 600px form. Before a remembered size exists, the length supplies an estimate; after normal rendering, the browser can remember the size for later use while skipping content.

The shorthand applies that estimate to both width and height. For ordinary full-width sections in a vertical article, the height is usually the part you are trying to reserve.

Base the estimate on actual sections, including their images and code examples. A plausible number is more useful than a very large placeholder chosen only to make skipped content take up space.

A remembered size cannot predict future content

An expanded example or a newly loaded image can change a section’s height. The auto value remembers a normally rendered size; it cannot predict a change that has not yet been laid out.

That makes the remembered size helpful without making it permanent truth. Check the page again after expanding controls or loading the content it normally receives.

Watch the scrollbar and reading position during that check. A faster initial render is less convincing if the page becomes awkward to move through afterward.

Keep the content available to readers

The content-visibility specification keeps skipped auto content available to browser features such as Find in Page and focus navigation. The value is intended to defer rendering, rather than make a section unavailable to the reader.

MDN also says off-screen auto content remains in the accessibility tree. Its accessibility notes flag an edge case: descendants hidden through CSS can still appear in that tree while their styles are skipped.

Include hidden controls when checking a realistic section. Find in Page, keyboard navigation, and a direct link to a heading deep in the document are useful checks too.

Avoid turning every element into a boundary

Applying content-visibility: auto through the universal selector would give the browser a very different set of containment boundaries. The containment model is part of how the optimisation works, so selecting those boundaries is a layout decision.

Begin with a few large off-screen sections that account for noticeable rendering work. Applying the property to every paragraph makes it harder to understand what changed and whether it helped.

The top of the page is also a poor place to look for work that can wait until later. Keep the initial content straightforward and focus the experiment on material farther down the document.

Compare the page before and after

Record a baseline before adding the rule, then compare the same page with the same content and browser conditions. Look at initial rendering and at scrolling into sections that were previously off-screen.

For a repeatable comparison, use the same viewport and device or CPU settings. Check several runs rather than treating one unusually good result as the benefit of the property.

A Lighthouse score alone would not persuade me to keep this change. The rendering trace and actual scrolling behaviour matter more here, especially when placeholder sizes are involved.

There are no measurements from this site behind the example. The CSS shows the mechanism; whether it improves a particular page still needs a before-and-after comparison.

If a lightweight page already renders promptly, leaving it alone is a reasonable outcome. I would keep content-visibility where it removes enough work to justify the extra sizing and interaction checks.

← Back to all articles