Table of contents of the article:
When it comes to optimizing website performance, attention is often focused on image weight, resource compression, caching, JavaScript, or server response times. These are all crucial elements, but they only represent part of the problem.
A modern page can in fact contain thousands of DOM nodes, images, tables, widgets, editorial blocks, products, reviews and components that the browser must parse, format and potentially render even when a significant portion of this content is located far below the visible portion of the screen.
This is where content-visibility comes in , a CSS property designed to allow the browser to avoid some of the work of rendering content that is not relevant to the user at that moment.
Used correctly, it can become a very interesting tool for particularly long pages, e-commerce sites with many products, archives, technical documentation, complex blogs and web applications with numerous independent sections.
However, it shouldn't be considered a magic switch for achieving higher PageSpeed scores. Content-visibility should be applied selectively , as incorrect use can have the opposite effect, introducing layout instability or delaying the rendering of important content.
What does content-visibility actually do?
Before understanding its relationship with Core Web Vitals, it is necessary to understand what happens when a page is rendered.
After receiving HTML and CSS, the browser must build the structures needed to display the page, calculate styles, determine the position and size of elements, and finally perform painting. On very complex documents, these operations can become expensive, especially on smartphones or devices with slower CPUs.
The property content-visibility allows you to tell the browser that the content of certain elements can be treated differently.
Its main values are:
- visible: normal behavior and default value;
- : allows the browser to avoid rendering content that is not relevant or far enough from the visible area;
- hidden: Keeps content hidden regardless of its position on the screen.
For the purpose of optimizing regular web pages, the most interesting value is generally content-visibility: auto.
.sezione {
content-visibility: auto;
}
With this simple CSS declaration, the browser can automatically apply various forms of CSS Containment and, when a section is outside the user-relevant area, it can skip a significant part of the work needed to process its descendants.
In practical terms, instead of immediately laying out and painting every single element on a very long page, the browser can focus first on the sections that are actually needed.
CSS Containment: The Principle Behind Optimization
content-visibility is closely linked to the concept of CSS Containment.
Typically, the browser must consider that changing one element may affect other elements on the page. The layout of one component can affect the surrounding one, making it more difficult to exclude portions of the document from calculations.
Containment, on the other hand, allows you to further limit the effects of a DOM subtree. With content-visibility: auto containment measures are applied relating to layout, style and painting; when content is actually skipped, size containment also comes into play.
This isolation allows the rendering engine to make decisions that would be difficult to make safely in a normal DOM structure.
The advantage becomes even more evident the more the document contains independent and complex sections . A landing page of a few hundred lines might achieve marginal benefits; a catalog with dozens of blocks, a very long editorial page, or a documentation page can instead offer significantly greater optimization opportunities.
content visibility and Core Web Vitals: what can really be improved?
The Core Web Vitals currently used to evaluate fundamental aspects of user experience are Largest Contentful Paint (LCP) , Interaction to Next Paint (INP) , and Cumulative Layout Shift (CLS).
As a reference, a good experience generally requires an LCP within 2,5 seconds, an INP no higher than 200 milliseconds, and a CLS no higher than 0,1, evaluating real-world user behavior at the 75th percentile.
However, it's important to distinguish between correlation and causality: content visibility doesn't automatically improve all three metrics . Its contribution depends on the page structure and the type of bottleneck present.
Effects on the Largest Contentful Paint
Largest Contentful Paint measures how quickly the main content in the front area of the page is displayed.
If a document is very large, avoiding some of the rendering work related to sections far from the viewport can reduce the initial load on the main thread and leave more resources available for the really important content.
This can indirectly contribute to a more efficient initial loading.
There is one fundamental rule, however: do not indiscriminately apply content-visibility to above-the-fold content.
The hero, main title, main image, initial content, and in general any elements potentially eligible for LCP must be rendered immediately. Trying to postpone them risks compromising the very metric you're trying to improve.
A much more sensible strategy is to apply the property to subsequent sections.
<main>
<section class="hero">
...
</section>
```
<section class="sezione-differita">
...
</section>
<section class="sezione-differita">
...
</section>
```
</main>
.sezione-differita {
content-visibility: auto;
}
This way, the initial part remains immediately available, while the browser can optimize its work on the more distant blocks.
Effects on Interaction to Next Paint
The relationship with INP is particularly interesting.
INP measures perceived responsiveness during user interactions. A main thread busy with lengthy JavaScript calculations, style recalculation, layout, or rendering can delay the display of the result of a click, tap, or keystroke.
Reducing the work needed for off-screen sections, content-visibility It can reduce pressure on the main thread in some scenarios and leave more capacity available to respond to interactions.
The benefit is especially plausible on pages with extended DOMs and numerous independent components.
However, it's no substitute for JavaScript optimization. If the problem is multi-millisecond tasks, invasive third-party scripts, or inefficient event handlers, adding a CSS property won't be enough.
Effective INP optimization must consider JavaScript, DOM, layout, and rendering together.
But be careful with the Cumulative Layout Shift
It is on the CLS that particular attention must be paid.
When the browser skips the content of a section, it still needs to be able to estimate the space it will occupy on the page. If the expected size is significantly different from the actual size, the arrival of the content in the viewport can cause visible shifts.
For this reason content-visibility It is often used together with contain-intrinsic-size.
contain-intrinsic-size: the fundamental complement
contain-intrinsic-size allows you to provide the browser with a size that can be used as a reference when the internal content is not rendered.
A simple example could be:
.sezione-differita {
content-visibility: auto;
contain-intrinsic-size: auto 800px;
}
The 800 pixels represent an initial estimate of the space needed. The keyword auto This makes the solution even more interesting: after the section has actually been rendered, the browser can remember its actual dimensions and use them when that same section is skipped again.
Of course, 800px isn't a universal value . Copying an arbitrary measurement from a tutorial can introduce more problems than it solves.
If the affected sections average about 500 pixels tall, using a baseline of 1500 pixels can cause significant variations during scrolling. Similarly, drastically underestimating the dimensions can cause the document to suddenly expand when the content is being processed.
The intrinsic size should therefore be chosen by analyzing the actual layout, possibly differentiating it by component type.
.card-prodotto {
content-visibility: auto;
contain-intrinsic-size: auto 420px;
}
.blocco-editoriale {
content-visibility: auto;
contain-intrinsic-size: auto 900px;
}
.sezione-recensioni {
content-visibility: auto;
contain-intrinsic-size: auto 700px;
}
This solution is generally more reliable than applying a single value to elements with completely different characteristics.
Where to use content-visibility
The most interesting situations are those where a page contains a large amount of content that is initially out of viewport.
A typical example is a very long article. The first part needs to be available immediately, while sections thousands of pixels lower don't necessarily need to be processed with the same priority.
The same concept can be applied to e-commerce catalogs, search results lists, category pages, extensive FAQs, technical documentation, pages with numerous comments or reviews, and component-rich dashboards.
In WordPress, for example, it might make sense to assign a specific class to large editorial blocks following the initial part:
<article class="contenuto-articolo">
```
<section>
<!-- Contenuto iniziale: rendering normale -->
</section>
<section class="cv-auto">
<!-- Sezione molto lunga -->
</section>
<section class="cv-auto">
<!-- Altra sezione fuori viewport -->
</section>
```
</article>
.cv-auto {
content-visibility: auto;
contain-intrinsic-size: auto 750px;
}
It's preferable to work on semantically independent blocks rather than applying the property to a large number of small elements. Adding it to every paragraph or every single node doesn't necessarily improve performance and unnecessarily increases layout complexity.
Where, on the other hand, it is better not to use it
The most common mistake is to add content-visibility: auto to selectors that are too generic, perhaps to all elements section, article or to the main site wrappers without first analyzing the result.
In particular, it is advisable to avoid indiscriminate application to elements present in the first screen, to possible LCP candidates, to components whose geometry strongly influences the rest of the page and to structures in which containment produces behaviors different from those expected by the original layout.
You should also be careful with JavaScript applications that continually query the DOM for dimensions and coordinates. Some APIs may ask the browser for layout information even for content you were trying to skip, reducing or eliminating some of the benefit you gained.
In other words, content-visibility works best when the page architecture actually allows the browser to leave off-screen sections alone.
Accessibility, page search, and content visibility
An important aspect concerns the difference between auto e hidden.
With content-visibility: autoOff-screen content remains part of the DOM and remains semantically relevant. The browser can make it available to functions like page search, keyboard navigation, and assistive technologies while temporarily bypassing some of the graphical work.
content-visibility: hidden It has a different behavior and should not be used as a simple universal replacement for display: none.
When working on accessibility, it is therefore essential to test real-world behavior with keyboard navigation and screen readers, especially in the case of complex interfaces, accordions, modals, tabs, and dynamic components.
Performance optimization should never compromise the usability of the content.
Progressive enhancement and browser compatibility
Today content-visibility It has much broader support than in the early years of its introduction and can be used in major modern browsers. However, for projects that need to support particularly old clients, it's still a good idea to consider it as a progressive improvement.
A browser that does not enforce the property should be able to display the page normally.
If you want to be explicit, you can use a CSS feature query:
@supports (content-visibility: auto) {
.cv-auto {
content-visibility: auto;
contain-intrinsic-size: auto 750px;
}
}
The page thus remains perfectly usable even when optimization is not available.
How to check if content visibility is really improving performance
Every performance optimization intervention must be measured. It's not enough to add a CSS property and observe an occasional increase in your Lighthouse score.
Before starting the intervention, it is advisable to create a baseline and check at least the behavior on mobile and desktop, the initial rendering, the main thread activities, any layout shifts and the available Core Web Vitals .
After applying content-visibility, the tests must be repeated under the same conditions and the results compared.
Chrome DevTools also allows you to use the Performance panel to observe the style recalculation, layout, and rendering phases. On a truly suitable page, you should be able to detect a reduction in the workload associated with offscreen content.
PageSpeed Insights and Lighthouse remain very useful tools, but lab results need to be paired with real user data . Search Console and Chrome UX Report can show a different picture than a single simulation run on your computer.
You also need to allow enough time for the field data to reflect user behavior after the change.
content-visibility is not a substitute for proper stack optimization
A fast web page is born from the combination of many different levels.
If the server takes several seconds to generate the HTML document, if the database is overloaded, if the cache is misconfigured, or if several megabytes of blocking JavaScript are transferred, content-visibility It cannot solve the problem at its root.
Likewise, it is no substitute for image optimization, thoughtful lazy loading, JavaScript minimization, Critical CSS, a proper caching policy, HTTP/2 or HTTP/3, Brotli, a CDN where necessary, and above all, a properly sized server infrastructure.
Web Performance is the result of the entire chain from server to browser.
A browser can be perfectly optimized, but if it receives the initial document late, it will still launch late. Conversely, an extremely fast server doesn't eliminate the cost of rendering a page with a huge DOM and dozens of complex components.
It is precisely for this reason that content-visibility It's interesting: it intervenes on an often overlooked level, that of the computational cost required by the browser to display the document.
A practical strategy for introducing content visibility into production
The best solution is not to apply this property globally, but to introduce it after identifying pages that have significant rendering complexity.
The process should start by analyzing the most important pages and the most used templates. Once you've identified the particularly large blocks that are typically found under the first screen, you can experiment. content-visibility: auto and define an intrinsic size consistent with the layout.
You should then carefully check scrolling, internal anchors, document search, keyboard navigation, JavaScript components, and responsive behavior.
Only after these checks does it make sense to compare the performance data and evaluate the extension of the change to other templates.
This approach allows you to gain a measurable benefit without turning a CSS optimization into a new source of regressions.
Conclusions: less unnecessary rendering, but only where needed
content-visibility It represents one of the most interesting CSS techniques for optimizing particularly long or complex pages. It allows the browser to temporarily skip some of the work required for sections the user isn't yet viewing, reducing the initial cost of layout and painting.
The benefit can be reflected in page loading and responsiveness and, under certain conditions, contribute to improving metrics such as LCP and INP.
At the same time, incorrect use can compromise the result, especially when the property is applied to the initial contents or when contain-intrinsic-size it is configured with values that are very far from the actual dimensions, generating instability in the layout.
The rule therefore remains the same that should guide every intervention on Web Performance: measure first, optimize selectively and measure again after the change.
For WordPress, WooCommerce, editorial portals, and high-traffic applications, frontend optimization must also be accompanied by adequate infrastructure. Proper server configuration, efficient caching, optimized PHP and databases, along with browser-side rendering control, allow you to address the entire performance chain rather than simply chasing a single benchmark score.
It is this comprehensive approach, from server to final rendering in the browser, that allows for truly fast, stable, and responsive sites for real users.
