The Scribe's First Un-ruled Parchment: On the Steady Hand of a Perfectly Optimized Text Layout Without a `content-visibility`

We often reach for the heaviest tools first. Faced with a long, text-heavy article, the immediate impulse is to contain it, to section it off. We might grab for `content-visibility: auto`, a modern and powerful CSS property that promises to skip the rendering work for off-screen content. It’s a sledgehammer, and it works. But like any powerful tool, its application requires precision. Used without care, it can introduce a new, jarring instability: the very content shifts we strive to avoid.

I encountered this recently on a sprawling, research-heavy post. The page felt sluggish. My Core Web Vitals, particularly Cumulative Layout Shift (CLS), were suffering from late-loading images and embeds within the long scroll. `content-visibility` seemed the perfect fix. I applied it to a main content container and watched my rendering metrics improve dramatically in isolation. The victory was short-lived. During testing, I noticed a subtle but infuriating jerk. As a user scrolled quickly, sections of text would momentarily appear as blurred, indistinct blocks before snapping into sharp focus, often pushing the content below them down the page. I had traded one form of jank for another.

The issue is one of containment. `content-visibility` creates a containment context for layout, style, and paint. This is its power, but also its peril. The browser, in its effort to save resources, cannot know the precise size of the skipped content until it is nearly on screen. If you haven’t explicitly given that container a height, or if its content is dynamic, the browser must essentially guess. When it stops guessing and actually renders the content, the layout recalculates. This calculation is what causes the jump—a tiny, cumulative shift that feels anything but premium.

The Steadier Hand of `contain-intrinsic-size`

Abandoning the power of containment felt like a step backward. But the answer wasn't to discard the tool; it was to use its companion. The property `contain-intrinsic-size` allows you to provide the browser with an approximate value for the height of the content it is skipping. It’s like ruling a parchment before you write on it. You give the scribe (the browser) a guide, so the spacing remains consistent even before the ink is fully applied.

The technique is simple yet requires a small investment in attention. You cannot use a single value for all your content blocks. A headline and a paragraph have different intrinsic heights. The solution is to define a CSS custom property for a typical block's estimated height, perhaps `--intrinsic-size: 1000px`, and apply it alongside your containment. The syntax becomes: `content-visibility: auto; contain-intrinsic-size: var(--intrinsic-size);`

This is not about pixel-perfection; it’s about providing a reasonable placeholder. The goal is to get close enough that the eventual render of the real content causes a minimal, often imperceptible, adjustment rather than a violent recalculation of the entire page layout. It’s the difference between a scribe carefully estimating the space for an illuminated letter and simply writing in the margin. One approach maintains the rhythm of the page; the other breaks it. By pairing these properties, we gain the performance benefits of deferred rendering without sacrificing the stable, reliable feel of a well-crafted layout.

Notes & further reading

A few pages I came back to while writing this: