All sites i have seen built with scully, have terrible performance statistics - specially "time to interactivity" and "blokcing by script" times... Why?
Performance are usually way worse than standard angular rendering (no prerender) .
Thank you
Running the test with Lighthouse on Chrome Devtools, there is the following warning :

But it only appears testing on mobile device.
On desktop, the test is fine (on your link, switch on the second tab for the desktop version of the test) :

Try this one then please:
https://pragozor.golemio.cz/
but maybe, here is the problem with "on scroll" animations / elements
The problem comes from the build of your application as it isn't a production build.
The following message is displayed in the devtools console :

It affects the performance of your application.
You can fix it by adding --prod when running the build script.
By the way it applies to your first link too.
Well... i thought reasons for scully are:
So... if Scully is for better user experience - user can interact with static - server prerendered page, it doesnt matter how is angular application built - google lighthouse tool should measure that static page (prerendered) and not measure time between:
[StaticPage] -> angular app downloading -> angular app bootstrapping -> angular app IS stable -> [Stable Angular APP]
Am i wrong?
@montella1507 Due to changes in web vitals (aka lighthouse in the past) currently _all_ SSR and pre-rendered apps are penalized. We have been talking with the Angular team for a while on this.
The Chrome team is making changes to how LCP is calculated, this will take a while, but if you are inclined, you can already see early results if you follow this](https://github.com/angular/angular/issues/13446#issuecomment-662233495).
And you are right, performance is a big reason for Scully, and we _are_ delivering on that. One of our big clients sees an uptick of 3% of their conversion, which is directly related to using Scully.
Nevertheless, it still matters how you build your application. Development mode _still_ has an impact.
Making sure all data needed for the initial view is there before Angular starts will prevent layout-shift and a visible flash. We provide the transferState-service for that. Those things matter, and will still matter after the web-vitals team has adapted their LCP calculations.
You are right, being penalized for doing the right thing is not very stimulating.
We do what we can do about this, by working with other teams. I will close this issue now, as there is _no change_ in Scully that can change this. I will happily reopen the issue when things change. Just let us now.
Most helpful comment
@montella1507 Due to changes in web vitals (aka lighthouse in the past) currently _all_ SSR and pre-rendered apps are penalized. We have been talking with the Angular team for a while on this.
The Chrome team is making changes to how LCP is calculated, this will take a while, but if you are inclined, you can already see early results if you follow this](https://github.com/angular/angular/issues/13446#issuecomment-662233495).
And you are right, performance is a big reason for Scully, and we _are_ delivering on that. One of our big clients sees an uptick of 3% of their conversion, which is directly related to using Scully.
Nevertheless, it still matters how you build your application. Development mode _still_ has an impact.
Making sure all data needed for the initial view is there before Angular starts will prevent layout-shift and a visible flash. We provide the transferState-service for that. Those things matter, and will still matter after the web-vitals team has adapted their LCP calculations.
You are right, being penalized for doing the right thing is not very stimulating.
We do what we can do about this, by working with other teams. I will close this issue now, as there is _no change_ in Scully that can change this. I will happily reopen the issue when things change. Just let us now.