![Jeremy Wagner](https://web.dev/images/authors/jlwagner-v7.jpg) Jeremy Wagner [GitHub](https://github.com/malchata) [LinkedIn](https://www.linkedin.com/in/malchata) [Homepage](https://jlwagner.net/)

<br />


Published: October 30, 2024

<br />

> [!TIP]
> **Celebration:** This web feature is now available in all three major browser engines, and becomes **Baseline Newly available** as of September 15, 2025.

<iframe src="https:///frame/blog/css-content-visibility-baseline/index_ec9c555ab7d70c54491bee8dc0f3b7667d026259426329aacda7148b550d120f.frame" class="framebox inherit-locale " allow="clipboard-write https://" allowfullscreen is-upgraded></iframe>

The [introduction of Interaction to Next Paint (INP) as a Core Web Vital metric](https://web.dev/blog/inp-cwv-launch.md.txt) early in 2024 has created more interest in rendering performance. Part of INP focuses on what it takes for the browser to paint the next frame *after* a user initiates an interaction with the page. [Keeping your website's INP low](https://web.dev/articles/inp.md.txt#good-score) means that users will feel as though it is responding to their interactions as quickly and smoothly as possible.

What's also important is the rendering work that needs to take place *as* a page loads, which has [the potential to delay interactions from even beginning](https://web.dev/articles/optimize-input-delay.md.txt#what_is_input_delay). It's worth finding ways to reduce the amount of work that occurs during this crucial part of the page lifecycle. [The CSS `content-visibility` property](https://web.dev/articles/content-visibility.md.txt) is one way you can achieve this, and we're happy to announce that it is now [Baseline Newly available](https://web.dev/baseline) as of September 2024!

> [!NOTE]
> **Note:** What follows is a condensed explanation of how `content-visibility` works. You'll want to read [our guide on this property](https://web.dev/articles/content-visibility.md.txt) to get the full story.

`content-visibility` is a CSS property that tells the user agent to defer the rendering of elements until they approach the viewport. For pages with many DOM elements, this can be beneficial, as it means the initial load of a page will kick off less rendering work. Instead, the work happens just before the user needs to see it.
![demo with figures representing network results](https://web.dev/static/articles/content-visibility/image/demo-figures.jpg) In our article demo, applying `content-visibility: auto` to chunked content areas gives a **7x** rendering performance boost on initial load. Read on to learn more.

To enable this optimization for off-screen elements, apply the `content-visibility: auto` rule to them in your website's CSS:

```css
.render-me-later {
  content-visibility: auto;
}
```

`content-visibility` operates by some of the behaviors defined for the `contain` property in [CSS containment](https://web.dev/articles/content-visibility.md.txt#containment). The goal of CSS containment is to provide isolation to parts of the DOM tree. This lets rendering operations be scoped to a specific part of the DOM tree, so layout is invalidated and redone for only a subset of the DOM tree. While applying this for rendering performance, it requires a fair bit of familiarity with the `contain` property's various values, and how to use them effectively.

When `content-visibility: auto` is applied to elements, they take on some of the properties provided by the `contain` property automatically. The result is that affected elements will initially be rendered with a height of `0px`, effectively meaning that they are *not* rendered.

However, this has some side-effects. For example, the page's scrollbar may shift and change height as a user scrolls towards previously unrendered elements which render just in time for the user to see them. To mitigate this, apply the [`contain-intrinsic-size` property](https://web.dev/articles/content-visibility.md.txt#specify_the_natural_size_of_an_element_with_contain-intrinsic-size).

Since `content-visibility` is recently Baseline Newly available, you might have some concerns about users with browsers that haven't updated yet to use the new property. Given that `content-visibility` is a CSS property, you shouldn't be overly concerned! Browsers that understand it will use it, and those that don't, won't. This means that---aside from the performance benefits you'd get from browsers that support `content-visibility`---you can expect that pages will largely function the same.

`content-visibility` provides an *additive* benefit---and if there are cases where you can use it to reduce rendering work during page load, you should consider using it to ensure that your pages have as much processing power available to them as possible when they need it most. Now that this useful feature is Baseline Newly available, you should feel free to use it, so that users can benefit from the rendering work it avoids until necessary.