You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using the info spelled out on web.dev and using the API in puppeteer, detect the critical css per view rendered, and then inline it and lazily load the css from the Angular build. This would allow for the most efficient version of Scully to run.
I already started to create a plugin for this a couple of days ago. I just learned about the "official" tool fir this, so I will use that instead of juice.
@hisham Our critical-CSS tool works differently from what Angular is doing.
Also, we do inline all the CSS that is needed above the fold for that 1 exact route, and then lazy load the rest.
As the CLI doesn't know what route it is going to serve, it needs to put way more blocking CSS in place.
What the CLI team has done is a big step forward. Our Critical-CSS plugin might now be a bit more optional as before, but it still brings a pretty good optimization to the table. Also, it does include all 3rth party CSS in the app. even the parts that are dynamically loaded by some routes.
🧩 Feature request
Using the info spelled out on web.dev and using the API in puppeteer, detect the critical css per view rendered, and then inline it and lazily load the css from the Angular build. This would allow for the most efficient version of Scully to run.
Link to the web.dev article: https://web.dev/unused-css-rules/
Description
A clear and concise description of the problem or missing capability...Describe the solution you'd like
If you have a solution in mind, please describe it.Describe alternatives you've considered
Have you considered any alternative solutions or workarounds?The text was updated successfully, but these errors were encountered: