• Hi

    I use the CriticalCSS addon for Autoptimize and have it configured to use it.

    I’m still seeing an issue with “Defer unused CSS” in Google Page Speed Insights and the #1 culprit is the autoptimize_4f5035da460555b39c0083be68e69392.css file.

    I have a few points here.

    1. Could you add the regular CSS link in the head, but inside <noscript> tags then
    2. Add a JS snippet in the footer to lazy-load the CSS file?

    This would make the non-critical CSS lazy-load after page load resulting in a far better performance for mobile visitors.

    The page I need help with: [log in to see the link]

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Optimizing Matters

    (@optimizingmatters)

    1. Could you add the regular CSS link in the head, but inside <noscript> tags then
    2. Add a JS snippet in the footer to lazy-load the CSS file?

    that’s _almost_ exactly what AO does;
    * noscript CSS is indeed added in head
    * there is a JS snippet in the footer to load the CSS for browsers that don’t support rel="preload"

    Only difference; the full CSS is loaded before onload, without being render-blocking. I’m looking into this with the people behind loadCSS (which is what AO uses and what Google recommands), so it _could_ be that we change that.

    But, to put things into context; Google is renaming “Defer unused CSS” into … “Remove unused CSS” in Lighthouse, which GPSI is based upon, implying their focus is not so much on the deferring part, but rather the “unused CSS” aspect.

    hope this clarifies,
    frank

    Thread Starter hades200082

    (@hades200082)

    Thanks for the swift reply… I noticed the subtle naming difference in GPSI just after posting.

    One thing to note re your approach though…

    using the onload attribute of the <link> tag causes the onload action to fire when the <link> tag has loaded… not when the page has loaded. This can cause it to be fired prior to the page load completing, resulting in a blocking resource still, especially on slower connection like mobile.

    Could it be better to do it as follows… ?

    1. Continue rendering the preload & noscript, but without an onload
    2. Add a small async script tag to the footer, just before the closing body tag that looks for all link[rel="preload"] and swaps them to rel="stylesheet"

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    If I’m not mistaking it’s the downloading of CSS that is considered render-blocking, not the parsing, which is why inlined (critical) CSS is not render-blocking either.

    But more general; I want to keep up with the industry-standard and (somewhat) Google-endorsed loadCSS-solution instead of going my own way ??

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Defer CSS’ is closed to new replies.