Description
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
- Checkout https://github.com/danielleroux/stencil-render-performance
- npm install
- npm run start
- Scroll AGGrid via scrollbar
- Click button to trigger fast re-render
Steps to Reproduce (dist-components)
- Checkout https://github.com/danielleroux/stencil-render-performance
- npm install
- npm start.components
- Scroll AGGrid via scrollbar
- Click button to trigger fast re-render
Code Reproduction URL
https://github.com/danielleroux/stencil-render-performance
Additional Information
No response
Activity
johnjenkins commentedon Jun 25, 2025
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.
innerHTML
I forked your repro here: https://github.com/johnjenkins/stencil-render-performance
dist-custom-elements
output instead (pnpm build
then use something likehttp-server
)innerHTML = '...'
on connectedCallbackWith 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 thandist
when initialising it's VDOM - although as discussed, still not as fast as a static string.danielleroux commentedon Jun 25, 2025
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 commentedon Jun 28, 2025
Maybe fixed by #6320. Check the performance of stencil 4.32.0
danielleroux commentedon Jun 28, 2025
Good call! I will the pr regarding our scenario maybe it solves the issue.
danielleroux commentedon Jul 7, 2025
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