For reusable components: has anyone stress tested the seams around Light versus Shadow DOM?
Hypothetically: 20 light DOM nodes per instance versus 1 light DOM node (with 19 shadow DOM nodes) per instance. 40 vs. 1+39? and instances?
I don’t think I have a baseline intuition on the costs there.
Zach Leatherman 3030 replies 1919 likes33 reposts Original on BlueskyOriginal on MastodonAlso posted to Mastodon.
30 replies
-
I’m curious what the costs are. My hunch would be that Shadow DOM has overhead costs but are those costs better than dumping everything into light dom when you hit 100 instances? 1000? I suppose i can test this myself just curious if folks have done it already
-
This is about right. ShadowRoots and slots are Nodes and have some unavoidable costs. But then some style calcs are cheaper, and quite often you can make simpler DOM and styles when you don't have to be defensive.
-
Nolan Lawson made some measuring a few years ago about style performance:
nolanlawson.com/2021/08/15/d...
nolanlawson.com/2023/12/30/s...
And even made a talk about it:
nolanlawson.github.io/css-talk-2022/Seems like a good thing to add to chrome.dev/css-selector....
I'll try and take a stab at it later tonight.
Here you go: chrome.dev/css-selector...
@zachleat cc: @bendelarre @westbrook have either of you done testing about this?
@knowler @zachleat @westbrook I haven't. But I'd be interested to hear about the results of such testing.
My high level understanding is that shadowdom should outperform lightdom in cases where style and layout computation can be delineated. But having real numbers on this would be really great.
@knowler @zachleat @bendelarre
I've found that DOM generally has a cost and that a lot of devs end up putting an extra node inside of each custom element node, for funzies, which adds up in a complex application... something, something control vs trust. 😱
One for one, there is a small setup cost to having a shadow DOM hosting node over a DOM node without a shadow DOM. But, once you've paid it, there are similar runtime benefits to making changes to the DOM/CSS in that encapsulated context. ⚖️
@zachleat IIRC this can easily become engine-specific, but the general/ambient costs between shad/light can be easily dwarfed by communication between them
Optimist take: initialize once and respond responsibly and you're gold
Pessimist take: light DOM everywhere since you can't trust others not to junk up the communication boundaries
Cynicist take: "we need to bootload Adobe analytics separately inside each of the Shadow roots by EOW"
@bram.us added some benchmarks: chrome.dev/css-selector...
Seems like Light > Shadow > Light/Shadow 50/50 mix
With the recalcs I’m also curious if css containment has any positive impact. That was a thing I wanted to see stencil have back in the day since adding the style tag would trigger expensive recalcs but using the constructae/adoptedStylesheets significantly improved recalc/restyles.
Constructible* lol
that would be interesting to test!
@bramus added some benchmarks: https://chrome.dev/css-selector-benchmark/?category=Shadow+DOM
Reads to me as Light > Shadow > Light/Shadow 50/50 mix
-
sure, but are you saying that isolation has perf benefits or downsides?
-
that makes sense, thanks! appreciate your insight!
-
-
I sent my thank you too early! you had more to share! (still appreciated!)
-
-