Google has called this property out in https://web.dev/articles/dom-size-and-interactivity#use_the_content-visi... and our initial render timing findings on pages with an extreme number of hidden-by-default DOM nodes is quite dramatic.
The `content-visibility` property will prevent user-agents from evaluating certain DOM nodes and descendants based on a heuristic.
Since DOM node evaluation may be skipped by this property, extra care should be used such that there aren't any accessibility regressions. For example, it's probably not a good use of this property to apply to a <footer> element, as it may remove the footer landmark from the accessibility tree and awkwardly blink into the tree as a user is scrolling down the page without warning...however for certain patterns, like toggleable content (such as hamburger-like-menus, or accordions), this could be useful.
None
None
None
Active
11.0 🔥
It affects performance. It is often combined with the Needs profiling tag.
Clarified accessibility considerations with an example.
Bumping to major, this is potentially a significant improvement and I think we should try to do something in core - entity listings, layout sections, and comments seem like good candidates as well as hamburger menus as listed in the summary.