x)- [ x ] bug report -> please search issues before submitting
- [ ] feature request
@angular 4.1.3
@angular/cli: 1.0.6
node: 6.10.1
os: darwin x64
npm: 3.10.10
https://developers.google.com/speed/pagespeed/insights/?url=agentem.herokuapp.com&tab=desktop
PageInsight complains about the css bundle files created by Angular.
Demo: https://agentem.herokuapp.com
Source: https://github.com/isaklafleur/agentem
Google PageSpeed Insights complains on CSS bundles created by Angular.
https://developers.google.com/speed/pagespeed/insights/?url=agentem.herokuapp.com&tab=desktop
Who is wrong?
PageSpeed Insight Dev Team?
Angular Dev Team?
Me? :-)
Well, no one is wrong, it's just that we don't support neither CSS inlining nor deferred CSS loading.
I agree that these are important optimizations that we should look at enabling. It's sort-of part of a larger topic of Progressive Web Apps that we're looking at enabling by default.
Insights provided shows something I'm also experiencing, the blank page.
After moving to angular-cli from my custom webpack config, neither page insights nor 'fetch as google' are able to render the page.
I'm very certain this is caused by angular-cli, as I moved back and forward between commits.
Changes were custom webpack -> angular-cli, and angular 4.0 -> 4.1/4.2.
Is this common? I was hoping to find an answer here but with no luck. Not sure if I should open up a bug report, as I can't know for sure what's causing it.
Running stock cli and aot fetches just fine for me. It would be nice to have a higher page speed though
any solution from Angular to be compatible with PageSpeed Insight?
Nowadays I believe our default apps have very good Lighthouse scores, which I believe makes this issue obsolete.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
Well, no one is wrong, it's just that we don't support neither CSS inlining nor deferred CSS loading.
I agree that these are important optimizations that we should look at enabling. It's sort-of part of a larger topic of Progressive Web Apps that we're looking at enabling by default.