Scully: [Question] Super poor performance in Google speed insights

Created on 23 Jul 2020  路  5Comments  路  Source: scullyio/scully

Description

All sites i have seen built with scully, have terrible performance statistics - specially "time to interactivity" and "blokcing by script" times... Why?

Example:
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fagitated-swartz-d8a163.netlify.app%2Fblog%2Fwhat-is-ivy%2F

Performance are usually way worse than standard angular rendering (no prerender) .

Thank you

enhancement

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.

All 5 comments

Running the test with Lighthouse on Chrome Devtools, there is the following warning :

image

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) :
image

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 :

image

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:

  • indexing
  • prerendered performance for user - SITE is server-statically generated (prerendered) = USER can be interactive with page almost instantly (HTML is served as already rendered - as static file) + on background angular is loaded, bootstrapped and then switched with static content
    = Scully works as SSR but with prerendering.

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.

Was this page helpful?
0 / 5 - 0 ratings