Exploring the use of the CSS `contain` property to reduce layout rendering times

[kevmodrome]

Describe the problem

I was just recently made aware of the CSS contain property after it was added to the new Safari TP (136). It helps reduce layout rendering times when changing styles by containing the "layout" event to smaller portions of the page. the MDN docs explain it quite well:

The contain CSS property allows an author to indicate that an element and its contents are, as much as possible, independent of the rest of the document tree. This allows the browser to recalculate layout, style, paint, size, or any combination of them for a limited area of the DOM and not the entire page, leading to obvious performance benefits.

I've found an article showing some pretty significant performance improvements. From 28ms to 14ms going from none to strict.

Describe the proposed solution

It would be neat if Svelte could somehow do this automatically somehow. Maybe a compiler option that lets you turn on aggressively adding the property to elements inside of components or even wrapping them using the same solution we're using for custom CSS properties.

Alternatives considered

Doing it manually.

Importance

nice to have

[Prinzhorn]

From my experience (I've played with it a while ago, Chromium had this for years) there is a lot of foot gun potential. It requires careful consideration for each element you apply it to and I don't think your regular website needs to use it (or can even use it). The use-cases are also rather limited. In the CodePen in the article you've linked the main element has a fixed width and height for a reason. Because otherwise changes inside the element would have an effect on things outside of it. If you don't carefully apply contain you will end up with funny rendering issues and inconsistent layouts.

Here's what happens without height: 50vh, strict will just collapse the element:

vokoscreen-2021-12-12_11-30-57.mp4

I don't think it's realistic to "aggressively adding the property to elements" at all. The property changes some semantics, e.g. try adding a position: absolute element inside the main in the CodePen. It will move inside the element once you enable contain.

vokoscreen-2021-12-12_11-27-36.mp4

[kevmodrome]

This is a fair point. strict applies all of the contain options. That is obviously not always ideal. It'd be interesting to see performance differences if you're just applying size, paint or layout independently.

[Prinzhorn]

I think the most important question is: what are the conditions under which each of them can be set and if Svelte can detect these conditions. Because there must be conditions for each, otherwise the browsers would apply these optimization by default. If these conditions could be detected at compile time by Svelte (or even at runtime), then once again what keeps the browser from doing it for us? I think each case needs to be carefully evaluated by a person and it cannot be automated. But I'm by no means an expert on contain and it would of course be great if Svelte could do something automatically if it is 100% safe to do so.

[samclaus]

It's arbitrarily hard to determine. JavaScript might dynamically add classes, etc. I can think of lots of cases where children are not neatly contained: badges, floating labels, etc. Svelte implicitly injecting CSS, especially considering the risk, seems like a severe overreach. Not to mention, the "contain" rule is not even verbose to begin with, and explicitly promising Svelte that it's ok to add it saves you no code and just adds complexity and more mental overhead.

[Rich-Harris]

I don't believe it's possible to safely determine where contain can be applied using static analysis. Maybe there's scope for browser devtools (ideally not framework-specific) to assist here, but it seems outside the realm of what's possible for something like Svelte, so I'll close this