Skip to content

bug: stencil initial rendering issue #6317

Open
@danielleroux

Description

@danielleroux
Contributor

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

Activity

johnjenkins

johnjenkins commented on Jun 25, 2025

@johnjenkins
Contributor

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

Image

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

danielleroux commented on Jun 25, 2025

@danielleroux
ContributorAuthor

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

aeharding commented on Jun 28, 2025

@aeharding
Contributor

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

danielleroux

danielleroux commented on Jun 28, 2025

@danielleroux
ContributorAuthor

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

danielleroux commented on Jul 7, 2025

@danielleroux
ContributorAuthor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Participants

      @danielleroux@aeharding@johnjenkins

      Issue actions

        bug: stencil initial rendering issue · Issue #6317 · stenciljs/core