Degraded performance after upgrading to 1.x.x

[wintercounter]

Stencil version:

 @stencil/core@1.0.3

I'm submitting a:

[x] bug report

Current behavior:
Initial render got MUCH slower after upgrading to 1.0.3. All components feel like they have an exponentially increasing 300ms delay. With 0.18.0 Everything works perfectly, fast and snappy. We had to revert back to 0.18.0. In overall rendering time we have ~ 4sec difference between the 2 versions.

Expected behavior:
Same initial render performance as 0.18.0.

Steps to reproduce:

I don't really know how to reproduce this as it's affecting a whole website.

• The components are being used with-in a React application.
• We're not using shadow-dom.
• We fixed the necessary breaking changes.
• We heavily relying on hostData and :host.
• We're not using Stencil's service worker.

Related code:

I can show how we initialize Stencil.

import { defineCustomElements, applyPolyfills } from 'my-web-components/dist/loader'

const edge = /Edge/
const promise = document.documentMode || edge.test(navigator.userAgent) ? applyPolyfills : Promise.resolve.bind(Promise)

promise().then(() => {
    defineCustomElements(window)
    MountReactEtc()
})

[manucorporat]

We might need more information, because we measure exactly the opposite, Stencil 1.0.x is much much faster.

[wintercounter]

We really don't have any clue what's happening, tomorrow I'm going to try to debug it more detailed, in the very worst case I'm going to start removing stuff to find the bottleneck.

[manucorporat]

You can profile both startups with the Chrome Dev Tools and share the results here too.

[wintercounter]

Unfortunatelly it's not as easy because page load profiling stops earlier than the components being rendered. I did many investigations for many other things, because we also have huge issues with the performance in Edge (we had that previously also with 0.18).

Turns out render is indeed faster than before. Let's say the faster loading of 0.18 was only an illusion. Seems like 0.18 added hydrated class later, when the components were fully finishing render (feels like all of them together got hydrated at once). Now with 1.0.x I can see the site assembling itself.

Relating to my performance issues in Edge, seems like components having deeper hierarchy using multiple slots are being the biggest issue in terms of performance, adding + 15-18sec to a single page render. In out case that means 5-6 components inside eachother, with 2-3 having 4-5 slots supported.

I'm going to close this issue now, but I'd still be interested in a solution that makes render look like in 0.18 (wait all componenets to be rendered, than add hydrated only).

[manucorporat]

wait all componenets to be rendered, than add hydrated only

it should still work that way, not sure how you are reproducing that

[wintercounter]

Seems like something is causing a Re-Layout each time a component is being mounted :S

[wintercounter]

What I could track down is that this line of code is initiatin the re-layout.

// add it back to the dom but in its new home
parentNodeRef.insertBefore(relocateNode.nodeToRelocate, insertBeforeNode);

I'll try to check which component is causing this but I have no ide so far.

[shreeshbhat]

@wintercounter : Interesting. Is it happening only in Mac chrome?
I am facing an issue with re-layouting on initial load as well.
Not able to figure out why it is happening either.

[wintercounter]

No, actually on Mac Chrome seems everything faster (still have the relayouts on the performance tab). For me it is Windows + Chrome and Edge.

Edge is so bad that we cannot go live, probably related to polyfilling slots and moving DOM elements around.