Support » Plugin: Jetpack - WP Security, Backup, Speed, & Growth » Render-blocking JavaScript and CSS

  • Resolved iwords

    (@iwords)


    I’ve been spending some time trying to improve my site’s speed in the eyes of Google, using PageSpeed Insights.

    Google consistently complains about the presence of a render-blocking JavaScript, and a blocking CSS file, specifically:

    http://stats.wp.com/e-201444.js

    …and…

    [my site]/wp-content/plugins/jetpack/css/jetpack.css

    I presume the former is used to power Jetpack’s stats module, but I don’t know what the CSS file is for.

    I use the Speed Booster Pack plug-in which does an excellent job of unblocking most CSS and JS resources. However, it seems that these last two it can’t do anything about.

    Is there something that can be done to unblock these two resources?

    https://wordpress.org/plugins/jetpack/

Viewing 11 replies - 1 through 11 (of 11 total)
  • Plugin Author Jeremy Herve

    (@jeherve)

    Jetpack Mechanic 🚀

    I don’t know what the CSS file is for.

    That file loads all CSS resources used by Jetpack. It includes styles for the contact form, for Jetpack widgets you may use, for the subscription form, for the Carousel view, … It is basically used by all Jetpack modules adding something to the frontend of your site.

    The Stats JS file should not be considered blocking, since it’s loaded in the footer of your site, after the rest of the page has been rendered. In my tests, Google Pagespeed Insights doesn’t report that file. Could you let me know your site URL so I can take a look?

    Jetpack’s CSS file, on the other hand, has to loaded in the head, before the rest of the page, like your theme’s stylesheet. If you were to load it later, there could be a brief moment when the styles are not applied on your site, until the file has loaded. That CSS file is not huge, and can be cached if you use a caching plugin on your site, so that shouldn’t really be a problem.

    Let me know if it helps.

    Thread Starter iwords

    (@iwords)

    Thanks for the response, Jeremy.

    I’ve spent some more time on this and I’ve discovered something strange: PageSpeed only complains about it on certain pages. Here’s an example:

    http://www.testdriven.co.uk/ford-adds-20-litre-tdci-and-25-litre-duratec-to-kuga-range/

    If you run that through PageSpeed, on the Desktop tab it says:

    Eliminate render-blocking JavaScript and CSS in above-the-fold content
    Your page has 1 blocking script resources and 2 blocking CSS resources. This causes a delay in rendering your page. Approximately 62% of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.

    Remove render-blocking JavaScript:

    http://stats.wp.com/e-201445.js

    Optimize CSS Delivery of the following:

    http://www.testdriven.co.uk/…-content/plugins/jetpack/css/jetpack.css

    But if I run another page through PageSpeed:

    http://www.testdriven.co.uk/skoda-octavia-greenline-hatchback/

    …there’s no mention of any render-blocking scripts or CSS. Yet both these pages use the same theme code to display.

    Strange.

    Plugin Author Jeremy Herve

    (@jeherve)

    Jetpack Mechanic 🚀

    Strange indeed, because the Stats tracking code is in the footer on that page as well. I’m not exactly sure what’s happening here.

    Could your post in the Pagespeed Insights support forums about this problem, and ask the volunteers what they think about it?
    https://groups.google.com/forum/#!forum/pagespeed-insights-discuss

    They might have run into this issue before.

    Let me know how it goes.

    Thread Starter iwords

    (@iwords)

    I’ve started a thread in the Insights group, but I don’t hold out much hope I’m afraid.

    On the subject of the jetpack.css file, it does seem to be included by a conventional <link rel line, and this appears to be preventing the Speed Booster Pack from inlining it.

    I presume this is happening because it isn’t enqueued like the other CSS files – is it possible this could be changed in a future release?

    Plugin Author Jeremy Herve

    (@jeherve)

    Jetpack Mechanic 🚀

    this appears to be preventing the Speed Booster Pack from inlining it.

    I’m not really familiar with how Speed Booster Pack works. Could you let me know what the expected output is, for a CSS file to be handled by that tool?

    Thanks!

    Thread Starter iwords

    (@iwords)

    Sure, I’ll try my best!

    Speed Booster, among other things, looks through the list of resources (CSS and JS) that are enqueued using wp_register_style() and wp_enqueue_style(), plus wp_register_script() and wp_enqueue_script(), and provides the option of deferring, minifying and/or inlining them.

    This makes Google PageSpeed happy. 🙂

    As long as the resources have been included (‘enqueued’) using wp_enqueue_style() and wp_enqueue_script() – which seems to be the way the WordPress guys want us to load CSS and JS files anyway – Speed Booster can intercept and place them in a more optimal position.

    I’ve assumed by looking at the position of Jetpack’s CSS and JS files, that they aren’t being loaded by wp_enqueue_style() and wp_enqueue_script(). This means Speed Booster doesn’t know about them, so can’t do anything to optimise their loading.

    If they were enqueued, it shouldn’t affect anything for most people, but those that use caching or optimisation plug-ins like Speed Booster should find they become available for optimisation. In the case of Speed Booster, it would be able to inline the jetpack.css file and it may also fix the problem of PageSpeed complaining about the stats.wp.me JS being a render-blocker.

    Hope that makes sense; not trying to teach anyone to suck eggs!

    Plugin Author Jeremy Herve

    (@jeherve)

    Jetpack Mechanic 🚀

    Makes sense, thank you!

    Jetpack’s CSS and JS files are all enqueued using the functions you mentioned above, but jetpack.css is a bit different: this file is generated by concatenating all of Jetpack’s CSS files into one, to save on the number of requests on each new page.

    If you use another tool to concatenate CSS, like Speed Booster, it’s probably best not to use Jetpack’s concatenated CSS. You can deactivate it by adding the following code to your theme’s functions.php:

    add_filter( 'jetpack_implode_frontend_css', '__return_false' );

    Thread Starter iwords

    (@iwords)

    That seems to stop the CSS from being render-blocking, thanks!

    Is there anything we can do to try to address this issue with http://stats.wp.com/e-201446.js being considered render-blocking?

    Is there a way I can make it add a defer or async to the script tag, for instance?

    Plugin Author Jeremy Herve

    (@jeherve)

    Jetpack Mechanic 🚀

    Is there a way I can make it add a defer or async to the script tag, for instance?

    That’s something we’re considering, and you can follow our progress here:
    https://github.com/Automattic/jetpack/issues/566

    I’m not sure it would have huge performance benefits, though, as the script is already loaded in the footer, after everything else, and from WordPress.com servers.

    Thread Starter iwords

    (@iwords)

    Oh, I fully expect it to have very limited real-world performance benefit, but not having it defer’d or async’d does seem to upset Google.

    Now that Google has openly declared that a site’s measurable performance is being considered a factor in its ranking, I think it’s only going to become increasingly important that site owners optimize whatever they can – even if that means making a few changes just to please Google.

    So, it’s good to see it’s being considered. And thanks for your help so far.

    Looking forward to a solution to this issue of defering the script tag 🙂

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Render-blocking JavaScript and CSS’ is closed to new replies.