{"id":5,"date":"2019-09-14T09:49:13","date_gmt":"2019-09-14T09:49:13","guid":{"rendered":"http:\/\/sumitjangid.com\/?p=5"},"modified":"2019-09-14T09:49:38","modified_gmt":"2019-09-14T09:49:38","slug":"async-and-deferred-javascript-introducing-script_loader_tag","status":"publish","type":"post","link":"http:\/\/sumitjangid.com\/index.php\/2019\/09\/14\/async-and-deferred-javascript-introducing-script_loader_tag\/","title":{"rendered":"Async and Deferred JavaScript: Introducing script_loader_tag"},"content":{"rendered":"\n

Today I\u2019m going to discuss a new, and very nice, site speed improvement that became possible in WordPress 4.1. What changed? The introduction of a new filter, script_loader_tag<\/code><\/a>. This filter lets us easily change the HTML markup of enqueue<\/code>d script<\/code> elements\u2014that is, of JavaScript files that were correctly added into a WordPress site using WordPress\u2019s wp_enqueue_script<\/code><\/a> function.<\/p>\n\n\n\n

With script_loader_tag<\/code>, we can now easily fix a problem that can significantly impact page speed: lots of render-blocking JavaScript.<\/p>\n\n\n\n

The Problem: Render-Blocking JavaScript<\/h2>\n\n\n\n

Long JavaScript files in your head<\/code> can delay your browser from displaying page content, because its default behavior is first to interpret the JS files themselves.<\/p><\/blockquote>\n\n\n\n

Properly enqueued JavaScript shows up in the head<\/code> section of your HTML document. On the internet as in nature, the main thing about a head<\/code> is that it\u2019s above a body<\/code>\u2014and this means something fairly serious for site speed, because JavaScript can be render-blocking<\/em>.<\/p>\n\n\n\n

\u201cRender-blocking\u201d comes from a web browser\u2019s default behavior: It wants to completely receive and process everything that\u2019s come higher up in the page, before it moves any further down.<\/p>\n\n\n\n

This means that long JavaScript files in your head<\/code> can actually delay your browser from displaying the page content in the body<\/code>, because its default behavior is first to interpret the JS files themselves. In other words, JS is blocking<\/em> the browser\u2019s crucial function of rendering<\/em> the page out for the user to actually see. The result can be slow sites and frustrated users.<\/p>\n\n\n\n

Google\u2019s Pagespeed Insights<\/a> has been pointing out this issue for a while:<\/p>\n\n\n\n

\"blocking_js_before\"<\/a><\/figure>\n\n\n\n

Click to enlarge<\/p>\n\n\n\n

However, prior to 4.1 and script_loader_tag<\/code>, the only solution I knew of was to move scripts to the site\u2019s footer. This is difficult to do by hand, and the plugins that claim to do it automatically didn\u2019t work in our case.<\/p>\n\n\n\n

Let\u2019s move straight to our success story:<\/p>\n\n\n\n

The Goal: Much Less Render-Blocking JS<\/h2>\n\n\n\n

Here\u2019s what we got down to with the solution we\u2019ll present below:<\/p>\n\n\n\n

\"blocking_js_after\"<\/a><\/figure>\n\n\n\n

Click to enlarge<\/p>\n\n\n\n

Now we\u2019ve only got three JavaScript files that can possibly slow down a page\u2019s rendering. The rest are still there, but they load in parallel with<\/em> the page content, rather than before<\/em> it.<\/p>\n\n\n\n

The Fix: Defer and Async your JavaScript<\/h2>\n\n\n\n

The first thing to understand is the alternatives to render-blocking JS: defer<\/code><\/a> and async<\/code><\/a>. We\u2019ll explain the difference, but both work similarly: They let the browser load a JS resource \u201cas time permits,\u201d while attending to other things (like page rendering) as well. This means that you can\u2019t<\/em> rely on a deferred or asynced JavaScript file being in place prior to page render, as you could without these attributes\u2014but the advantage is that the file won\u2019t slow the speed at which the page becomes visible to users.<\/p>\n\n\n\n

Those are concepts\u2014now for code. (The full code is available on GitHub<\/a>.)<\/p>\n\n\n\n

1. GETTING YOUR SCRIPT HANDLES<\/h3>\n\n\n\n

Every properly enqueued WordPress script has a handle<\/em>: a \u201cnickname\u201d that the site knows to call it by. We\u2019re going to need these handles for all scripts, and getting them isn\u2019t dead-simple, unfortunately.<\/p>\n\n\n\n

It is possible, though:<\/p>\n\n\n\n

\/*\t\n* Getting script tags\n* Thanks http:\/\/wordpress.stackexchange.com\/questions\/54064\/how-do-i-get-the-handle-for-all-enqueued-scripts\n*\/\n\nadd_action( 'wp_print_scripts', 'wsds_detect_enqueued_scripts' );\nfunction wsds_detect_enqueued_scripts() {\n\tglobal $wp_scripts;\n\tforeach( $wp_scripts->queue as $handle ) :\n\t\techo $handle . ' | ';\n\tendforeach;\n}<\/code><\/pre>\n\n\n\n
This code prints out a list of enqueued handles, separated by | <\/code>, right into the head<\/code> of every page:<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
You\u2019ll only do this once, then use \u201cView Page Source\u201d to copy and paste the handles themselves.<\/p>\n\n\n\n
Once you\u2019ve done this, deactivate this section of the code: we\u2019ve got our handles, so let\u2019s not clog up our head<\/code> with them anymore. That\u2019s why this section is commented out in the code on GitHub\u2014I don\u2019t want it to run every time!<\/p>\n\n\n\n
2. DEFERRING AND ASYNCING RENDER-BLOCKING JAVASCRIPT<\/h3>\n\n\n\n
We found that we needed to use defer<\/code><\/a> and not async<\/code><\/a> for WPShout, so I\u2019ll walk through the defer<\/code> code. Most of the heavy lifting here is from an article by Scott Nelle<\/a>; thanks, Scott!<\/p>\n\n\n\n
add_filter( 'script_loader_tag', 'wsds_defer_scripts', 10, 3 );\nfunction wsds_defer_scripts( $tag, $handle, $src ) {\n\n\t\/\/ The handles of the enqueued scripts we want to defer\n\t$defer_scripts = array( \n\t\t'prismjs',\n\t\t'admin-bar',\n\t\t'et_monarch-ouibounce',\n\t\t'et_monarch-custom-js',\n\t\t'wpshout-js-cookie-demo',\n\t\t'cookie',\n\t\t'wpshout-no-broken-image',\n\t\t'goodbye-captcha-public-script',\n\t\t'devicepx',\n\t\t'search-box-value',\n\t\t'page-min-height',\n\t\t'kamn-js-widget-easy-twitter-feed-widget',\n\t\t'__ytprefs__',\n\t\t'__ytprefsfitvids__',\n\t\t'jquery-migrate',\n\t\t'icegram',\n\t\t'disqus',\n\t);\n\n    if ( in_array( $handle, $defer_scripts ) ) {\n        return '<script src=\"' . $src . '\" defer=\"defer\" type=\"text\/javascript\"><\/script>' . \"\\n\";\n    }\n    \n    return $tag;\n} <\/code><\/pre>\n\n\n\n
The add_filter<\/code> line tells us that this code should run anytime an enqueued JavaScript file is about to be printed onto the page as an HTML script<\/code> element. Letting us filter that HTML is what script_loader_tag<\/code> is for. (If you need an update on filters and WordPress\u2019s hooks system in general, start here!<\/a>)<\/p>\n\n\n\n
The biggest check in this code is doing a single thing defining the $defer_scripts<\/code> array. This array lists out the handles of all the elements we want to defer\u2014the handles we found in step 1. (Your handles will, of course, vary!)<\/p>\n\n\n\n
The logic below the array definition (beginning with if ( in_array( <\/code>) searches for the current script\u2019s handle attribute in the array we\u2019ve just defined. If the handle matches an element in the array, then we modify the script to have the same source, but with a new property: defer=\"defer\"<\/code>, which will cause the script not to block rendering. With this change made, we return<\/code> the HTML back, and we\u2019re good to go!<\/p>\n\n\n\n
(And finally, if the handle isn\u2019t found, we just return the original tag itself, unaltered.)<\/p>\n\n\n\n
You\u2019ll know this plugin is working when you view page source and see something like this in the head<\/code>:<\/p>\n\n\n\n
\"deferred_scripts\"<\/figure><\/div>\n\n\n\n
When to Use Async Instead of Defer<\/h4>\n\n\n\n
You use async<\/code><\/a> when you\u2019re linking directly to an external<\/em> JavaScript library. That link would look something like: <script src=\"https:\/\/oss.maxcdn.com\/libs\/respond.js\/1.4.2\/respond.min.js\"><\/script><\/code>. Notice how it\u2019s a link to the full URL, and the JavaScript will get pulled in<\/p>\n\n\n\n
enqueue<\/code>ing external<\/em> JS is a lot less common, at least for us, since most of our enqueued JS is in themes and plugins that host their own code. At any rate, the code for async<\/code> is precisely the same as the code for defer<\/code>\u2014but with the two words switched out. So if you do happen to have a lot of externally hosted enqueue<\/code>d scripts, getting them async<\/code>ed is a very similar technical process to the one we\u2019ve just covered.<\/p>\n\n\n\n
WHICH SCRIPTS TO DEFER AND ASYNC<\/h3>\n\n\n\n
You\u2019ll notice that we didn\u2019t defer everything\u2014a few scripts are still render-blocking. Here are rules of thumb on that:<\/p>\n\n\n\n