• Resolved stuback

    (@stuback)


    Wordpress: 4.7.5
    WooCommerce 3.0.7
    Flatsome: 3.3.5
    wp-rocket: 2.9.11

    This is a great plugin and performs better than some other very popular choices! I have taken the time to correctly generate the critical css for our site. I have one question concerning the generated minified, cached, fvm/.css file. How can I defer this file just below the critical css? Currently it’s within the bottom third of my critical css when I use “above the fold optimization plugin”. Currently I can inline this through the mentioned plugin, but I just need to defer it further down the page so it doesn’t FOUSC/break style momentarily.

    Perhaps, if possible, you can include a css defer box for this purpose. Kind of tricky as you would only want to defer this file just below the first </style> tag of critical css which is obviously up high in the source code. Maybe even delay it’s loading by ms or even specify header or footer.

    Maybe you have an idea? I know you have another thread speaking of this file being render blocking, and not much you can do without heavy coding, but really it’s just landing a bit short of the end of </style> tag in critical css.

    Another valid point is it’s really just Google Page Speed that points this cached file as render blocking. However, it doesn’t effect the speed of our site. It would be nice to clear the suggestion though.

    Thanks again for this awesome plugin as it’s solved our other issues!

    Stu

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author Raul P.

    (@alignak)

    Hi,

    We actually had this feature a while back, but it has been removed.
    I’m still looking at other alternatives, so this eventually will come back.

    You can eliminate css render block, by selecting the “inline all css” option, but I don’t recommend this if your css is large.

    Be advised that async css does exactly that, meaning they load independently of each other and the order of the css files won’t be preserved.

    In other words, you should only use css defer if you either have one css file only, OR, if your css files do not overwrite others.

    For example, you have a parent and child theme.
    You also have some form that includes it’s own css styles, but which you have styles on the child theme to overwrite it.

    With async, the form css or the parent css, can end up loading later or earlier, thus your overwrites do not work. Furthermore, it’s not consistent and it can change every time you refresh the page.

    We had this implemented using LoadCSS but if something is missing on the critical path, it still gives out the same render blocking css (pagespeed detects that css file is needed, even if you remove the render block).

    Since you told me you extracted the critical path css, I will assume you have some dev skills… so I’ll suggest this instead.

    a) Collect all css files yourself (copy paste) to a file, in order, and including the inlined styles (the order in which they appear matters).

    b) Make sure you only have one single css file.

    c) Dequeue all css styles on your theme functions.php (you can use a loop, no need to do one by one)

    d) Rather than enqueueing your css file, print it on the header using something like this: https://github.com/filamentgroup/loadCSS or https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery

    That should get your css async, while ensuring it works fine (as long as your critical path is correct).

    In my opinion, you should not bother with it though.
    The benefit is almost insignificant.

    Thread Starter stuback

    (@stuback)

    Raul,

    You are a gentleman and a scholar at your craft and it’s greatly appreciated that you share your knowledge with a student of web development. You have educated me on this task and opened my horizons for pursuing solutions. For this I’am thankful for your generosity. I’m better because of this.

    I will investigate your suggestions and implement them. Feedback will be forthcoming as the process progresses. You are correct, this is insignificant to speed, but I need to understand why this works the way it does to better me, and help others.

    And yes, this is just one .css file which is the cache file. Also, inline isn’t an option as the css is far to great to justify it. I believe the answer is in the critical css. I do have a child theme which contains several style overrides. I should be able to determine what’s missing using WinMerge to compare. Not an easy task!

    Thank You!
    Stu

    Plugin Author Raul P.

    (@alignak)

    You’re welcome.

    If you are studying how to optimize speed on any site, you better dig into what “real” developers use (WinMerge is not one of them).

    The most efficient way of doing CSS optimization is to collect all css by the order of appearance in each page (on wordpress, this can change from page to page).

    The critical path is ok, but it’s not always the best solution. In many years doing optimization, I only had to resort using it for very few (large) sites… and even then, there would be alternatives if I wanted to.

    I recommend that you learn how critical path css work, but focus on more practical optimizations. For example, learning UNCSS on your merged, single css file.

    What this does is to remove unused CSS from your huge stylesheet, and make it a few KB size, which in turn are ok to be inlined. How you do this, is by using Gulp or Grunt.

    https://github.com/giakki/uncss
    https://github.com/addyosmani/grunt-uncss
    https://www.fourkitchens.com/blog/article/use-gulp-and-uncss-slim-down-your-css-framework/

    Gulp might be easier to learn, but there are caveats when using these techniques.
    A very common caveat, is that uncss removes what it doesn’t see…
    If you have a form that, upon submission shows a warning that is styled by css… that is not seen before submitting it (and uncss doesn’t know about it). This means, there’s always manual work after uncss, to add back any hidden styles.

    But the key of doing speed optimization, is to remove unused styles and then decide if you still need a critical path or if you can inline it.

    The “lazy way”, is to async the whole thing and add the critical path… however, you are not ultimately reducing the size, but rather increasing it. Your css stays the same, but now you’re adding the critical path extra code…

    Also, as a final tip, if you want to be a step ahead and be ready for the future, take a look at Calypso.

    https://github.com/Automattic/wp-calypso
    https://organicthemes.com/what-is-wordpress-calypso/
    https://premium.wpmudev.org/blog/future-of-wordpress-2016/

    Good luck with your studies.

    Thread Starter stuback

    (@stuback)

    Thanks for the info! Yes, studying this stuff and work full time is tough. Calypso looks interesting for sure. I played and read through the night and decided the most practical solution at this point is to inline the css. This puts me in the green across the board. Speed holds up and the site plays well together. I have lots to learn, but need to finish this project, so simplicity wins for now. That is, until traffic dictates otherwise.

    I actually tried both critical css vs inline and I always get a higher, “near perfect” google score, but with no noticeable speed gain. As you mention, just makes the css file larger. Inline or no inline speed is the same for the most part. The key for us is your FVM plugin by far. If traffic picks up, then I can remove inline and keep the same speed.

    I will try and make up the difference of Uncss with the proper server config, and cdn. This should serve us well for our small Woo site. Looking forward to studying UNCSS! That’s the way to go for sure.

    However, if you feel inclined to do so, creating a way to defer the large cached .css file just beneath any header/critical css would be grand. Maybe have choices to put url cached file in header, footer or under header css, or after </style> tag 1,2, or 3.

    As you mentioned and I have discovered, it won’t increase speed noticeably, but it does render 100’s.

    Thanks for your help. Probably be in touch later when I lose my mind, if you’re for hire.

    Stu

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Cached FVM/.CSS Render Blocking’ is closed to new replies.