bug: serializeShadowRoot: 'scoped' has a massive performance degradation.

[Armand-Lluka]

Prerequisites

• I have read the Contributing Guidelines.
• I agree to follow the Code of Conduct.
• I have searched for existing issues that already report this problem, without success.

Stencil Version

4.27.1

Current Behavior

Currently, when using serializeShadowRoot: 'scoped' to SSR render, there is a huge degradation in terms of parsing speed of the CSS. A single component, with many css classes attached to it, is taking around 16s to render using serializeShadowRoot: 'scoped'. This seems to be growing linearly with the amount of unique components used, as well as the amount of CSS these components contain.

From some local testing, it seems that the biggest culprit here is how the CSS being parsed in styles.ts or shadow-css.ts. I know that in the past there was a refactoring in how things work when moving things away from "scoped" parsing, so perhaps something was lost when it was re-introduced recently by @johnjenkins?

Expected Behavior

The performance should be the same for both DSD and Scoped versions, similar to how things were in the past.

System Info

System: node 20.18.3
Platform: darwin (24.3.0)
CPU Model: Apple M1 Pro (8 cpus)
Compiler: stencil-bug-reproduction/node_modules/@stencil/core/compiler/stencil.js
Build: 1741890846
Stencil: 4.28.2 🎤
TypeScript: 5.5.4
Rollup: 4.34.9
Parse5: 7.2.1
jQuery: 4.0.0-pre
Terser: 5.37.0

Steps to Reproduce

1. npm i
2. npm run build
3. npm run serve to spin up server
4. Visit http://localhost:8090/
5. Observe the time it takes to render.
6. Remove component css classes, run npm run build && npm run serve and notice that with fewer/no classes the performance improves.

Code Reproduction URL

https://github.com/Armand-Lluka/stencil-bug-reproductions/tree/renderToString-performance-example

Additional Information

No response

[johnjenkins]

hey @Armand-Lluka - thanks for raising - I'll take a look when I can.

Out of interest, did you use Stencil's old SSR: shadow > scoped > shadow behaviour with the same amount of styles etc?

*edit - i've just tried your repro with stencil ~2 and it is indeed, very fast

[Armand-Lluka]

hey @Armand-Lluka - thanks for raising - I'll take a look when I can.

Out of interest, did you use Stencil's old SSR: shadow > scoped > shadow behaviour with the same amount of styles etc?

*edit - i've just tried your repro with stencil ~2 and it is indeed, very fast

We are currently on version 4.18.3 and have been unable to migrate due to the changes made with DSD being the new default, and yes we relied on this functionality quite heavily without issue. I'd be willing to create PRs for this and the scoped styling issue.

[johnjenkins]

I think the scoped styling issue was fixed here #6224 ?

Regarding this issue - I have a horrible feeling that previously, the scoped-styles were hard baked into the hydrated app output and now we’re doing it dynamically (I don’t know, just speculation). If that’s the case we may need to rethink the whole approach e.g decide on SSR method at build time

[Armand-Lluka]

It looks like the scoped styling issue was not fixed. I've updated the stencil version in the example to reflect that.

[johnjenkins]

Regarding this issue - I have a horrible feeling that previously, the scoped-styles were hard baked into the hydrated app output and now we’re doing it dynamically (I don’t know, just speculation). If that’s the case we may need to rethink the whole approach e.g decide on SSR method at build time

It seems my assumptions are correct - Stencil is now doing this on the fly - before, it did it at build time < I guess rollup is much more efficient at doing text reading / manipulation than a node server.

So I guess we (@christian-bromann) need to either decide whether to try and make that call more efficient somehow or change the api to make users choose 'declarative-shadow-dom' or 'scoped' at build time

[christian-bromann]

Raised a PR with a potential fix, please review