I had a quick look at the pagespeed insights report for your site and the main thing that critical css aims to fix, which is making sure CSS is not render blocking to speed up the first render/ contentful paint, is indeed fixed.
Your main concern now is the “server response time”, which is 1.68s on mobile (first contentful paint is at 1.8s so 0.12s later which is super).
The “defer unsused CSS” opportunity is the topic of a lot of discussion these days; 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.
But we’re considering alternative approaches to how CSS is loaded, so this “opportunity” might be “fixed” in a next version of Autoptimize 🙂
hope this clarifies,
frank
@optimizingmatters Currently the mobile version is totally breaking after using critical CSS plugin. Do you have any idea of fixing that?
I would have to see what is wrong @karkidennis, but critical CSS seems off now and I don’t see autoptimized CSS either?
In that case *something* is messing things up (badly); I don’t see any sign of critical CSS or deferred Autoptimized CSS in the homepage’s HTML source I’m afraid.
To troubleshoot this you could briefly disable/ re-enable plugins one by one (and temporarily switch to another theme) to see who is breaking this?
OK, now I see them as well 🙂
Let’s for starters take a step back; if you disable “inline & defer CSS”, is your mobile site also broken, or not?
Have been looking into this some more, the issue occurs in the autoptimized (deferred) CSS-file (and is probably ‘inherited’ by the critical CSS) when the viewport is smaller then 992px.
The problem seems to be that (the long) line 32 of the autoptimized CSS-file seems to be missing a } somewhere and adding that closing bracket in my browser’s developer tool’s “style editor” or even bluntly removing the line indeed makes the mobile page render correctly.
Now I *think* the origin of that line is in your parent or child-theme’s stylesheet, so try adding wp-content/themes/cargopress-pt and/ or wp-content/themes/cargopress-pt-child to the comma-separeted CSS optimization exclusion list?
Next to that, in AO Critical CSS advanced settings, tick the “fetch original CSS” option to avoid the issue to be bleed over into the critical CSS.
frank
@optimizingmatters Do I have to disable “inline & defer CSS” if so where can I find that setting?
no, just try excluding one or both of the files mentioned in my reply above + tick that “fetch original” in the critical CSS advanced options 🙂
@optimizingmatters I have this in the setting http://prntscr.com/mievt8
I have excluded both in AO http://prntscr.com/miew9z now the menu has gone 😀
well, have you tried excluding just the parent theme one or just the child theme? 🙂
@optimizingmatters Thanks Man the error was coming from the main theme css now it is looking good. If anything comes will inform you.
great! feel free to leave a review of the plugin and support here! 🙂
have a nice weekend (well, almost),
frank
@optimizingmatters One more thing can’t we remove that menu and content flashing in the first load?
