Render blocking message keeps appearing

I am trying to improve my page speed and I keep getting the “render blocking assets” message. So I put ALL of the assets in the footer AND inline.

Which I admit doesn’t make much sense, but I have. I still get the error message. What more can I do to solve this?

  • Adam
    • Support Gorilla

    Hello rob

    I hope you’re well today and thank you for your question!

    I checked the site with PageSpeed Insights and I looked into its configuration. I admit that while it’s usually hard to go near 100% score and to eliminate all of render blocking resources, the current status of the site “doesn’t make much sense” if you take HB asset optimization settings into account.

    I do, however, see that you’re running Elementor (which creates some resources dynamically) and hosting with SiteGround (which might need some “special treatment”:wink:. Therefore, I’d like to ask you to start with one more “test”. It might be a bit time consuming but should give us some additional clues on the case:

    – first, clear and disable Hummingbird’s PageCache

    – second, reset Asset Optimization to default in Hummingbird and then disable it (site might go a bit “wild” at this moment)

    – third, login to SiteGround cPanel for your site and find cache settings; there should be more than one type of cache active so flush them all and disable them all

    – get back to the site and there should be an option in Elementor to “re-generate” assets (like CSS) so use it if it’s there

    – then try to setup Asset Optimization in Hummingbird again from scratch, trying to optimize it as much as possible. Please note: after saving changes (each time) you need to visit the front-end at least one to actually trigger optimization process and to give it a moment to complete.

    Then run performance test (ignore other issues than render blocking resources) and see if the changes you’re making are being reflected; if so you should be able to fine tune things then.

    After that’s done, enable the Hummingbird PageCache and let it build-up (you might want to “crawl” a site to speed it up, e.g. using this tool) and then test the site again.

    Let’s see when this gets us and based on the results we’ll then see what to do next to solve the case.

    Best regards,

    Adam

  • rob
    • Site Builder, Child of Zeus

    All done!

    The scripts are fine however nearly all of the css files are showing up as render blocking resources.

    I only have 4 css scripts that are not either “moved to footer” or “inline”. Whereas the performance report is saying that i have 17 scripts that are render blocking.

    Any ideas?

  • Predrag Dubajic
    • Support

    Hi Rob,

    First thing that I would like to mention is that you’re using a site with page builder and there are almost 60 files in asset optimization, and with that kind of configuration having a score over 80 on page speed is not a bad result at all.

    About the further CSS optimization, you can try enabling both move to footer and inline options for getting better results, of course, make sure that your site layout is not affected when doing these changes.

    Best regards,

    Predrag

  • Predrag Dubajic
    • Support

    Hi Rob,

    Yes, but you can try enabling both of the options for the reported files to try to get better results, and there are still few files that don’t have any optimization options applied, these are the files from your list and what you can try:

    astra-theme-css – style.min.css – nothing is enabled, try enabling all of the optimization options, or some of them.

    parent-theme – style.css – nothing is enabled, try enabling all of the optimization options, or some of them.

    child-style – style.css – nothing is enabled, try enabling all of the optimization options, or some of them.

    elementor-pro – frontend.min.css – nothing is enabled, try enabling all of the optimization options, or some of them.

    socicon – socicon.css – Inline is enabled, try moving to footer as well.

    genericons – genericons.css – Inline is enabled, try moving to footer as well.

    fontawesome – font-awesome.min.css – Inline is enabled, try moving to footer as well.

    Google fonts – Loaded from external source so can’t be affected in Hummingbird.

    astra-contact-form-7 – contact-form-7.min.css – Moved to footer, try enabling Inline as well.

    contact-form-7 – style.css – Moved to footer, try enabling Inline as well.

    elementor-icons – elementor-icons.min.css – Moved to footer, try enabling Inline as well.

    font-awesome – font-awesome.min.css – Moved to footer, try enabling Inline as well.

    elementor-animations – animations.min.css – Moved to footer, try enabling Inline as well.

    elementor-frontend – frontend.min.css – Moved to footer, try enabling Inline as well.

    elementor-global – global.css – Moved to footer, try enabling minification and Inline as well.

    elementor-post-738 – post-738.css – Moved to footer, try enabling minification and Inline as well.

    Best regards,

    Predrag

  • rob
    • Site Builder, Child of Zeus

    Hi Predrag,

    I can’t really understand why I would select both move to footer and inline as either one of these should stop them from being render blocking. As per your instructions I have now selected move to footer AND inline for all of the css files apart from four (the four at the top of your previous list).

    So I made the changes and ran another speed test. The following 8 files are still showing up as render blocking even though they have “move to footer” and “inline” selected.

    https://smbauthority.com/wp-content/themes/astra/assets/css/minified/compatibility/contact-form-7.min.css?ver=1.3.4

    https://smbauthority.com/wp-content/plugins/contact-form-7/includes/css/styles.css?ver=5.0.3

    https://smbauthority.com/wp-content/plugins/elementor/assets/lib/eicons/css/elementor-icons.min.css?ver=3.6.0

    https://smbauthority.com/wp-content/plugins/elementor/assets/lib/font-awesome/css/font-awesome.min.css?ver=4.7.0

    https://smbauthority.com/wp-content/plugins/elementor/assets/lib/animations/animations.min.css?ver=2.1.6

    https://smbauthority.com/wp-content/plugins/elementor/assets/css/frontend.min.css?ver=2.1.6

    https://smbauthority.com/wp-content/uploads/elementor/css/global.css?ver=1539185398

    https://smbauthority.com/wp-content/uploads/elementor/css/post-738.css?ver=1539286635

    All but one of them are to do with the elementor plugin, the other is from the parent theme. Any ideas?

    p.s. The two calls to the google font api is a custom call I wrote with JavaScript, I will make that call asynchronous.

  • Adam
    • Support Gorilla

    Hello rob

    I checked your site again.

    The Google calls – those indeed would have to be addressed “manually” and I believe you can just alter your code to load them asynchronously, like you said.

    As for other remaining resources.

    1. JS: it seems it’s jQuery and jQuery Migrate; I’m pretty sure that they actually should be ignored here as further changes might cause the site to break down. I wouldn’t do anything about them.

    2. CSS resources: this is a bit different but still – some of these resources are created dynamically by Elementor and it might not be possible to address them. However, you can try switching Elementor to not use CSS output to file and instead make it use “Internal Embedding” option. It’s worth checking, it gives different results on different setups.

    Please note: after changing that setting you’ll need at least user “re-check files” option in Hummingbird Asset Optimization and then clear Hummingbird’s cache via “Hummingbird -> Dashboard” page (the clear cache button at the top).

    If that doesn’t help, it might not be possible to go any further with that kind of optimization without either completely breaking the site or making a very significant changes to it’s configuration (like replacing/removing plugins and or switching themes and so on). This is because there are always some sort of relationships between resources and those must be maintained in order for everything to work. Hummingbird’s Asset Optimization attempts to maintain those relationships and that might affect the way some resources are optimized. This is very individual thing and depends strictly on a specific setup.

    Yet, 87 score for desktop is a very good score not even taking the kind of setup into account. 72 score for mobile is not ideal but should also be perfectly acceptable. These are good results. A thing worth remembering in that all is that nor the score neither the suggestions given by PageSpeed test are “ultimated” – score does not reflect site loading speed and the tips are just “most common practices” detected that may be possible to apply, that could possibly speed up the site. There’s, however, always a kind of a “limit” that you can’t go above without serious tweaking (often involving custom development) and that’s very different for different sites, I’m afraid.

    Kind regards,

    Adam