1410579 - Share UA cascade data across author and user stylesheets

Status: NEW

(Core :: CSS Parsing and Computation, enhancement, P3)

Description

[Cameron McCormack (:heycam)]

We should probably make the UA cascade data cache work on author sheets, at least for the set of sheets in a shadow tree (as long as none of them are inline <style> elements) so that we can avoid duplicating cascade data in the common case of some Web Component applying the same style sheets to all instances of the component.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

I talked with Cameron and he mentioned this maybe mattering in a Fission world if you have multiple tabs open for a same origin, we could shave quite a bit of memory.

To make it work for documents too, apart from ShadowRoot, this should probably start holding the CascadeData off the StyleSheet object itself...

That may be a bit tricky, perf-wise, because it involves way more pointer-chasing and hashtable lookups for each element styled. So probably needs more perf and memory measurement.

Note that we already considered this for other stuff like bug 1443536 / bug 1434145, which added and removed a sheet really fast with a flush in the middle, which caused a full stylist rebuild.

Comment 2

[Bobby Holley (:bholley)]

Yeah, I'm hesitant to multiply the number of per-element rulehash lookups by the number of stylesheets. Could certainly measure though.

Comment 3

[Eric Rahm [:erahm]]

Cameron, do you have any idea what kind of overhead this is?

Comment 4

[Cameron McCormack (:heycam)]

I think there's two different things here.  In comment 0 I was imagining that we would want to share the cascade data that we compute for style sheets in a shadow tree, since with Web Components it's going to be common to have the same set of style sheets loaded in each shadow tree, and right now we'll compute a unique copy of the same cascade data in each.  Whether it's worth doing that depends on how big sheets in shadow trees tend to be; I haven't checked.

For comment 1, the savings from sharing of author sheet cascade data across documents for the same origin (which I guess would not be forced into separate processes) would be entirely dependent on the site.  I was thinking cases like someone opening multiple nytimes.com tabs for different articles.  Each of those has 660 KB of cascade data that could in theory be shared, assuming they're loading exactly the same set of style sheets.  But it's probably worth looking at sharing the style sheets themselves, since IIRC we still only do this sharing for sheets loaded from exactly the same document URL, not origin -- nytimes.com has 2.48 MB of style sheets.

But this isn't really a content process overhead saving, so I'm not sure if it should be captured with an [overhead] whiteboard tag.

Comment 5

[Brian Grinstead [:bgrins]]

(In reply to Cameron McCormack (:heycam) from comment #4)
> I think there's two different things here.  In comment 0 I was imagining
> that we would want to share the cascade data that we compute for style
> sheets in a shadow tree, since with Web Components it's going to be common
> to have the same set of style sheets loaded in each shadow tree, and right
> now we'll compute a unique copy of the same cascade data in each.  Whether
> it's worth doing that depends on how big sheets in shadow trees tend to be;
> I haven't checked.

FYI: We aren't yet using Shadow DOM in chrome (waiting on sign off from the DOM team in Bug 1465592). But once we do, if it's viable for performance, it's quite likely we'd want to load the whole of global.css inside it (which in turn includes a bunch more sheets through widgets.css). That way we wouldn't have to worry about anon content inside of the Shadow DOM not getting styled with the global document styles.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

FWIW, I'd take that last comment in bug 1465592 as a "go ahead", but I'd double-check with Olli just in case :)

Comment 7

[Emilio Cobos Álvarez (:emilio)]

(In reply to Brian Grinstead [:bgrins] from comment #5)
> FYI: We aren't yet using Shadow DOM in chrome (waiting on sign off from the
> DOM team in Bug 1465592). But once we do, if it's viable for performance,
> it's quite likely we'd want to load the whole of global.css inside it (which
> in turn includes a bunch more sheets through widgets.css). That way we
> wouldn't have to worry about anon content inside of the Shadow DOM not
> getting styled with the global document styles.

Also, that looks like a different bug to me, which is much more tractable IMO.

Could you file, maybe with a see also pointing to bug 1480146? Looks like as long as we share the stylesheet objects we could do this in a similar way to what we do for UA sheets, even better since we don't need to care about media queries evaluating differently between instantiations.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

(That being said, that kind of defeats the point of Shadow DOM of applying only as little rules as possible to the elements in there).

Comment 9

[Brian Grinstead [:bgrins]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)
> (That being said, that kind of defeats the point of Shadow DOM of applying
> only as little rules as possible to the elements in there).

Yeah, it may be an interim solution while some things are using SD and some are using document styles. For example, given <widget-1> which is using SD then <widget-2> which is just a CE and has styles defined in a document sheet: if <widget-1> includes a <widget-2> in it's anon content, then the styles for <widget-2> won't apply. Given the number of elements in chrome we will certainly end up in that scenario, so it seems easier and less error prone to just load the shared styles directly. Note that I'm just talking about global.css here which is sort of intended to apply everywhere - I don't think we'd do the same with the browser.css theme file.