Inlined “above the fold CSS” but AO css file is still loaded before the fold.

Image of the issue here: https://imgur.com/a/oVvzB8p

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.

Moreover Google has made it’s position more clear by deciding to rename the opportunity into “remove unused CSS” in Lighthouse (and thus GPSI), so issue is not really with “defer” ..

hope this clarifies,
frank

Frank,

Thanks for your detailed reply. What reload method is being used? Is it the “<link rel=”preload” href=”style.css” as=”style”>” method or some other method?

If so, where would I find the preload code when inspecting the web page and can you also let me know where the code that powers this is located in the plugin files?

I’m not sure or convinced that things are working as they should.

With the Critical CSS add on, every page of the site has Critical CSS (e.g. CSS required for the page to render) automatically generated . Therefore, the “autoptimize_xxx.css” would not necessarily be needed at all, or at least until later on in the load process. With the file loaded and with that file containing CSS for the entire site, PageSpeed rightly identifies that some CSS is loaded that is not needed for that page thus the “Defer unused CSS” warning.

Without the add on, your plugin provides only one field exists to manually input Critical CSS and therefore I opted (and most people would opt) to input Critical CSS for the home page. Therefore, on the home page itself the “autoptimize_xxx.css” should also not be needed (either at all, or until later on in the loading process), as the critical CSS should contain what is necessary to render the page.

I am going to experiment by tweaking the core of the plugin to see if I can get the file to load in such a way that it does not trigger the warning in PageSpeed, but I would also appreciate any further insight you can offer as I think there is a core issue here with how the plugin is handling Critical CSS versus the overall optimized CSS file.

Thanks
Zach

—-
Zach Nicodemous.
Developer: https://codeable.io/zach-nicodemous

AO uses Filamentgroup’s LoadCSS approach to load the full css, which adds an onload attrib. to the <link rel=preload tag; onload="this.onload=null;this.rel='stylesheet'" and which has a polyfill for browsers that don’t support rel=preload yet.

I can follow and agree with most of what you’re saying and have been discussing this in a LoadCSS issue and have been experimenting myself to load the CSS a bit later using AO’s filters instead of changing core as per this Gist, feel free to use that as a starting point ??

Lastly; the JS in this StackOverflow answer seems very interesting, as it takes the scrollevent into consideration (which makes sense; a user scrolling while the page is loading should get the full CSS asap to avoid seeing unstyled content).

Let me know how things go, I’ll be happy to test/ review whatever you come up with and if you can crack this I’ll be happy to accept it as a PR on Github! ??

frank