autoptimize not differing css when critical path present

When you’re using “inline & defer” (potentially with the automated critical CSS plugin) the critical CSS is inlined and the full CSS is technically not deferred but “preloaded” meaning it is loaded without it being render-blocking (which is a separate GPSI recommendation). AO uses Filamentgroup’s loadCSS for this purpose.

The advantage of using “preload” is that the page below the fold is styled as soon as possible without the CSS being render blocking. If it would be deferred (as AO used to do a couple of versions ago) the chance was bigger that the user scrolled down to a part of the page that was not styled yet. Given the fact that preloading the full CSS does not block rendering, there is little advantage to be found in deferring it instead and the disadvantage might be significant.

hope this clarifies,
frank

And that makes total sense, and to the human audience…awesome…the problem is there is second audience and that is google page rank.

And now that google prioritizes the Mobile Page Speed result as a factor in the page rank…and because it does not respect this technique for mobile (test and you will see) then now we have a major problem.

Google page speed mobile is very very important….please check you will see it not respecting the technique you described for the MOBILE test. For desktop test…it loves your technique.

And also if you want, please test with Divi and Divi using a couple google fonts.

that’s the thing; the pagespeed score as such is not used as a ranking factor, with Google instead using more objective KPI’s such as time to first byte, time to start render (significant/ contentful paint), time to onload, time to interactive.

Here are some links that explain the relative importance of scores vs the importance (also on ranking) of load time:

https://wp-rocket.me/blog/the-truth-about-google-pagespeed-insights/
https://gtmetrix.com/blog/pagespeed-and-yslow-are-half-the-battle/
https://neilpatel.com/blog/does-speed-impact-rankings/
https://www.elegantthemes.com/blog/tips-tricks/how-page-speed-affects-search-engine-rank-and-what-you-can-do-about-it
https://blog.hubspot.com/marketing/page-load-time-conversion-rates

re. testing with divi; I don’t buy premium themes or plugins for testing purposes ??

hope this clarifies,
frank

@@optimizingmatters thanks for the quick response.

All these articles you linked to were written BEFORE the big Google announcement in January 2018. In January 2018 google announced that the algorithm will change to make mobile first page speed result a major factor starting July 2018.

“The Google Speed Update: Page speed will become a ranking factor in mobile search
Starting in July 2018, Google will finally use mobile page speed as a ranking in their mobile search results.”

https://searchengineland.com/google-speed-update-page-speed-will-become-ranking-factor-mobile-search-289904

So while I agree with all these articles, I can’t deny what Google says is law.

So please please make sure to test against the mobile version of google insights page speed test, they have lots of little detailed tweaks they want made to get that speed grade higher.

And by the way, I really appreciate all your work Frank!

• This reply was modified 6 years, 1 month ago by jiggaman.
• This reply was modified 6 years, 1 month ago by jiggaman.

(mobile) page speed yes, but that is not the same as google pagespeed insights score ??

from the linked FAQ on searchengineland;

Is it using the same data you use in the PageSpeed Insights tool? The Chrome User Experience Data?
The intent of the signal is to improve the user experience on search. While we can’t comment on the types of data, we encourage developers to think broadly how about performance affects a user’s experience of their page and to consider a variety of user experience metrics when improving their site.

so yeah, mobile page speed is _very_ important, but pagespeed insights is but a tool to help you improve your site’s speed, not a ranking factor. as I wrote; focus on objective metrics such as TTFB, start render and onload which indicate how fast a site renders for a visitor (use e.g. webpagetest.org, where you can test with different types of bandwidth and different browsers from different locations).

@optimizingmatters

Thanks for that link. That said, my other audience is the “client.” And even though with your plugin and a few other techniques I am able to achieve Desktop google page speed scores of 100, when the clients see the mobile page speed score in the orange 60’s range they get nervous.

Is it possible in your plugin to have the option to load your combined minified css in the bottom vs the technique employed right now for the sole purpose of appeasing the google insights mobile speed test if so desired. If I had that option, then with me loading the critical path css using your plugin (or via custom code in my divi theme header area) and then it would be much easier to appease the google gods.

Is it possible in your plugin to have the option to load your combined minified css in the bottom vs the technique employed right now

maybe, but that will (probably) not make it in AO25 ??

On the last few days I started seeing a huge drop in mobile on many of the sites that I optimized using AO. I guess that maybe is something related to a change in PSI algorithm, because nothing changed on this sites, and all of them dropped from 90+ in mobile to barely 70+. Defer unused CSS is the main cause of this.

If it would be deferred (as AO used to do a couple of versions ago) the chance was bigger that the user scrolled down to a part of the page that was not styled yet.

I agree with your answer, but clients are not happy with those orange warnings that appeared all of a sudden. May be getting the option to defer CSS to the bottom could be a great addition to this plugin.

Frank, which version is that? I would like to test how PageSpeed Insights tool performs with that previous version of AO.

Thanks a lot.

To be clear: I have 100GPSI on my own site, even though “defer unused CSS” is still mentioned as opportunity. So the “opportunity” as such does not have to be the reason for a lower pagespeed score. And pagespeed scores as such are not that important either. Clients need to be educated ??

Re. older version; try https://github.com/futtta/autoptimize/tree/2.0.2 maybe?

Re. older version; try https://github.com/futtta/autoptimize/tree/2.0.2 maybe?

Thank you!. I’ll give it a try

I have 100GPSI on my own site

By the way, https://autoptimize.com/ dropped to 85 on mobile in PSI. Seems to be a recent change/bug, lots of people are complaining on PSI Google support forum.

By the way, https://autoptimize.com/ dropped to 85 on mobile in PSI. Seems to be a recent change/bug, lots of people are complaining on PSI Google support forum.

people tend to attach way to much importance to GPSI and the changes implemented there. autoptimize.com did not get slower (it’s blazing fast) so the fact GPSI want down is merely … noise? ??

so the fact GPSI want down is merely … noise?

I agree, but you know that clients likes to easily measure results and the big G rules it all, even if we don’t like the way they do it. Anyway, I’m not criticizing AO, you make a tremendous job with this plugin.

Thank you for taking the time to answer ALL the questions ??

well, I did a quick test with full CSS deferred until the onload event and get the same warning.

my conclusion is that the only “fix” is to use something like “plugin organizer” to make sure plugins only load their CSS there where it is needed (used).

I also heard there is discussion to rename the opportunity from “defer unused CSS” to “remove unused CSS”, which at least makes a bit more sense ??

it seems as though google rolled their recent changes back, scores are back to where they were before the weekend?