bug: stencil initial rendering issue

[danielleroux]

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.35.1

Current Behavior

We facing an issue regarding initial rendering inside a lazy rendering 3rd party grid like AGGrid. See Video:

In the column "Price" is a web component without usage of stencil
In the column "Electric" a stencil component.

Screen.Recording.2025-06-25.at.12.50.48.mov

If you use scrollbar to scroll the grid you can see that the grid has problems to render the stencil component but no problems with the none stencil component.

Also on the bottom you find a scenario where I re-render 100 of components. You see there no issues or only a minimal difference between both.

Maybe this is a side effect of the vdom?
Why is ag grid via scrolling by scrollbar so much worse than re-render it 100 times?

Expected Behavior

Initial rendering should be as fast a standard web component.

System Info

MacOS, Chrome

Steps to Reproduce (Layzloading)

Dont see any issue here, its lazy rendering fine

1. Checkout https://github.com/danielleroux/stencil-render-performance
2. npm install
3. npm run start
4. Scroll AGGrid via scrollbar
5. Click button to trigger fast re-render

Steps to Reproduce (dist-components)

1. Checkout https://github.com/danielleroux/stencil-render-performance
2. npm install
3. npm start.components
4. Scroll AGGrid via scrollbar
5. Click button to trigger fast re-render

Code Reproduction URL

https://github.com/danielleroux/stencil-render-performance

Additional Information

No response

[johnjenkins]

hey @danielleroux - thanks for raising!

I'm not sure however, how fair your comparison is, or to put another way ... there's nothing magic that makes Stencil less performant than native.

1. In your demo, you're using the lazy-loader which by it's very nature will always be less performant. The loader uses a skeleton proxy component which on connectedCallback, wires up your actual class < this will always have some overhead.
2. Stencil has to construct a dynamic virtual DOM from your JSX to initially render your component. This has pros and cons - pro - it's dynamically bound to your component's properties, con - it's not as performant to initialise as a string injected with innerHTML

I forked your repro here: https://github.com/johnjenkins/stencil-render-performance

1. I used the dist-custom-elements output instead (pnpm build then use something like http-server)
2. I swapped out the JSX for innerHTML = '...' on connectedCallback

With this I found no obvious performance disparity with the native variant

I'm not sure how either of the 2 performance bottle necks can obviously be 'fixed' in Stencil.
The vdom rendering could probably use some performance tune-ups (PRs welcome!) but for most use-cases it does the job fine.

As expected, I did find the dist-custom-elements to be much more performant than dist when initialising it's VDOM - although as discussed, still not as fast as a static string.

[danielleroux]

Maybe its more a discord topic then an github-issue tbh.
I can also close the issue and lets discuss this in discord.

Could it be possible in some way to use the hydration (toRenderToString) be a solution for the first time rendering?

[aeharding]

Maybe fixed by #6320. Check the performance of stencil 4.32.0

[danielleroux]

Maybe fixed by #6320. Check the performance of stencil 4.32.0

Good call! I will the pr regarding our scenario maybe it solves the issue.

[danielleroux]

Short update it gets fixed by setting the taskQueue to taskQueue: 'immediate', this will not schedule the first render into a queue.

It would be possible to skip the scheduler for the initial rendering and use the queueMicrotask or make a direct call also fine:
https://github.com/danielleroux/stencil/blob/e913f489685e8586ec96d1dd1ecdaff754795bfc/src/runtime/update-component.ts#L41-L48

Diff:
main...danielleroux:stencil:fix/initial-render-queuetime#diff-8f8ec5fb30b42a75159333489bc559f60b6c4858e46928e3439daeb982a1c591R40

@johnjenkins Do you think this will be a possible solution? Any concerns about performance?

//edit: I gave it a shoot lets maybe its a solution that works: #6331