⚠️ Disclaimer:

I’m NOT too deep in exploring this topic yet, so my understanding at this point may not be 100% accurate… But the performance bump is true, so I think it is worth taking a note at least for my future reference (to revisit this topic one day)

Explanation

CSS containment (contain) enables performance improvement by providing predictable isolation of a DOM subtree (an element + its descendant elements) from the rest of the page. With this property, a developer can declare some parts of the page to be encapsulated as a set of content, and when this encapsulated part is off-screen, the browser won’t need to consider its states (size/layout/style/paint)

By declaring an element’s CSS to have content-visibility: auto, you can prevent an element from immediately rendering when it is off-screen, and hence get immediate performance improvement with minimal effort. The browser will calculate the size of such element as if it had no children based on its size containment: contain-intrinsic-size/contain-intrinsic-height/contain-intrinsic-width. (i.e. when such element is off-screen, browser will lay out the element without rendering its internal content) This will lead to a huge performance increase because browser skips a lot of rendering cost, making page load and scroll more efficiently.

Such element will only starts to paint when it approaches the viewport (just-in-time rendering), when the element are close to appear in the viewport, the browser will remove its size containment, and starts rendering its contents.

Practical Example

Consider we have a page with many repeating image component that is repeated across the page:

2025-11-18T135110

Without CSS containment the loading time is 1,185ms, because the browser needs to render all the content inside every single .team-card-container component.

2025-11-18T120804

However, by incorporating the CSS containment size, the browser could assume / guess the size of the .team-card-container components without actually rendering them (i.e. hence eliminating the need of rendering those tens of component subtrees when they’re off-screen). And the result? rendering time from 1,185ms straight to just 27ms !

2025-11-18T120804

Reference