On a page rendering thousands of DOM nodes in a long list, what does the CSS declaration content-visibility: auto change about the work the browser does, and why does it usually need contain-intrinsic-size alongside it?

## The problem it solves On a very long page — a forum thread, a documentation page, a feed rendered fully into the DOM — the browser does style and layout work for every node, including the ninety percent nobody has scrolled to. That cost shows up as a slow first render and as a stall whenever something forces the page to lay out again. Deferring *downloads* does nothing for it: the bytes were never the problem, the DOM was. `content-visibility: auto` is the lever for that. Applied to a container, it tells the browser: while this subtree is not relevant to the user, skip its rendering work; when it approaches the viewport, render it then. ```css .post { content-visibility: auto; contain-intrinsic-size: auto 480px; } ``` ## What "skipped" means A skipped subtree does not have its descendants styled, laid out or painted. The elements are still in the DOM; scripts can still find them; the browser will render them on demand — including when the user searches the page or navigates to an anchor inside it, so this is not the same as hiding content. What is *not* skipped is just as important. Resources referenced inside the subtree are still requested; `content-visibility` is about rendering cost, not network cost. If you also want the images inside those sections to hold their downloads, that is a separate, complementary decision. Nor does it stop your JavaScript running: timers, listeners and framework work inside that section are unaffected. It is also worth distinguishing the sibling value `content-visibility: hidden`, which skips the contents unconditionally and does not auto-render them when they scroll in — that one is for content your own code will reveal, not for long-page rendering. ## Why contain-intrinsic-size is not optional Skipping layout has a consequence: a subtree whose layout was never computed has no known size. Left alone, the element collapses to something close to zero height. Multiply that by two hundred sections and the document is drastically shorter than it should be. As the user scrolls, each section reaches the viewport, gets rendered for real, suddenly takes its true height, and the page grows underneath them. The visible symptoms are a scrollbar thumb that resizes and jumps, scroll position that lands somewhere unexpected, and content moving while being read. `contain-intrinsic-size` fixes this by giving the browser a size to assume while the subtree is skipped. You are not required to be exact — you are supplying a plausible placeholder so the scroll height is approximately right and stays stable. The `auto` keyword form, as in `contain-intrinsic-size: auto 480px`, is the one to reach for in practice: the browser uses your value until the element has been rendered once, then remembers the size it actually had and uses that afterwards. So the guess only has to be good for a first pass; after the user has seen a section, its placeholder is accurate. ## Where it fits, and where it does not It suits long, uniform, article-shaped pages: many sibling blocks of similar structure that the user consumes in order. Applying it to a handful of small elements is pointless overhead — the win scales with the amount of layout you are avoiding. It is not a substitute for not having the nodes at all. If a list is large enough that even the DOM itself is a memory and interaction problem, keeping the nodes and skipping their rendering is weaker than not creating them; the tradeoff is that keeping the nodes preserves find-in-page, anchors and simple markup, which are exactly what people miss when they replace a list with a windowed one. Be careful with anything measuring elements inside a skipped subtree. Code that reads offset or bounding-box geometry on a skipped element will either get placeholder-shaped answers or force the browser to render it right then, which is the opposite of the intended saving. Scroll-driven effects and sticky elements inside these containers deserve a real check on a device, not just a glance. ## Reporting it in an interview Say what it skips (rendering work, not downloads and not scripts), why the size hint is mandatory rather than nice-to-have (skipped subtrees have no measured height, so the scroll height lies), what the `auto` keyword buys (remembered real sizes after first render), and when you would not use it (few elements, or a list so large that not building the DOM is the better answer). That covers the mechanism, the pitfall and the judgment in one pass.