In the most recent update of Google PageSpeed, which happened in May 2020, users were introduced to several new metrics, like Cumulative Layout Shift, Largest Contentful Paint and Total Blocking Time. These new metrics were introduced as Google begins to shift towards a user experience (UX) oriented stance.

In this blog post we're going to introduce what total blocking time is, how it is scored, why it's an important metric to understand for your website, and how to improve it.

What is total blocking time?

Total blocking time is one of the six major metrics identified in Google Pagespeed insights. It measures the total amount of time that all user manipulatable elements in the page are blocked from input. TBT is calculated by adding the blocking portion of all long tasks between First Contentful Paint and Time to Interactive.

To better understand total blocking time, we need to define Long Tasks.

What are Long Tasks?

Long tasks are caused by JavaScript Code that uses the main thread of your server's processor when loading. This code causes the UI to become frozen, even if it looks visually ready for the user to access. An example would be a button that has loaded, but cannot be clicked.

When your UI is frozen, clicks, taps, drags, or any other user input is typically blocked because the event/click handlers have not yet been attached to the element (this is known as the blocking portion of a long task). If you need a simple explanation: The visual aspect of whatever element you're loading shows, but the code that makes it work hasn't loaded yet.

The “long” Part of long tasks is defined as any task that takes over 50 milliseconds to complete. The reason 50 milliseconds is the base mark is because it complies with the RAIL model. You can read more about the RAIL model here, but essentially it is a set of performance guidelines to ensure a good user experience.

The main takeaway of the rail model is that your website better load fast, or Google will penalize you and your visitors will be unhappy (or even abandon the site altogether)

This is in line with Google's recent pivot towards user experience.

TLDR; Total blocking time is the sum of all of the individual blocking times of long tasks.

How Is Total Blocking Time Scored?

The guidelines for total blocking time is pretty simple. If your total blocking time falls under 300 milliseconds, you're good to go. If it falls within 300 to 600 milliseconds, you need to improve it, and if it is over 600 milliseconds then it is essential that you address it immediately.

Total blocking time accounts for 25% of your PageSpeed Performance score, so getting this right is essential to a good score.

To calculate the actual score for total blocking time, Google will take the millisecond figure of TBT, and compared to the top 10000 websites that it has indexed. Something that we found interesting was that 404 pages were included in this index of the top 10,000 websites, and there probably impacting the median figure. 404 pages will have a much lower total blocking time when compared to a fully featured homepage, as 404 pages have very limited JavaScript to load.

Because you're being compared to the top 10,000 websites, you need to step up your game, and make sure that you're scoring under 300 milliseconds.

Why Should I Care?

If you think back to our definitions, the blocking time only comes into play if it takes 50 milliseconds or more to load. Due to the way websites are loaded coming blocking time is an aspect in any website. It only becomes a problem if it begins to take up access time and lock users from accessing content on the website.

Imagine that you're accessing a website, and you need to wait many seconds before you can actually click on buttons Or Scroll down the page. If I needed to browse through multiple pages on an individual website where this was the case, I'd be infuriated with the user experience. This new metric is Google's attempt at improving this aspect of user experience on web sites.

Not only does addressing this metric cause your users to have a better experience on your website, but it will probably also impact your search engine ranking placement. Google announced in May that in the coming six months, they will be transitioning to using web vitals (total blocking time is an aspect of web vitals) in their Google search engine algorithm (Alongside the existing pillars of SEO, which is good content and speedy websites). What this means is that there's a good chance that this individual metric directly impacts some aspect of the algorithm in the near future.

How Do I Address A Slow Total Blocking Time?

Total blocking time is directly caused by JavaScript, so you should optimize your JavaScript sitewide in every possible way.

We have several optimization guides for JavaScript and code on our website, but the major things you can do to address this are as follows.

General Optimization (Do This First)

Remove unused JavaScript.

Removing unused JavaScript is a no brainer. If you're loading scripts that aren't used, you're pointlessly loading data and inflating your page speed load time. There's no point to this, and removing the JavaScript will seriously impact the speed of your website. On WordPress, there is several tools that can help you do this. Our favorite tool is called asset cleanup, which allows you to enable and disable individual scripts on individual pages.

It shows you all the CSS and JavaScript files that are called on an individual page. For example, on your homepage, you could be loading multiple CSS and JavaScript files for plugins, themes, and more. If you know for a fact that you're not using a JavaScript file on this page, you can easily remove it by simply flipping a switch called “unload”. unloading your script file will ensure that it doesn't load on a page in which it's not used. You can also do this for all the CSS on individual pages as well.

We also go and disable plugins on pages that they aren't used. With acid clean up, we typically disable plugins sitewide, and then enable them for the individual pages on which they are used. For example, we only use gravity forms on our contact page, so we’ll only load gravity forms on the contact page created there's no point to loading the associated CSS and JavaScript that comes with gravity forms on our homepage, because there are no forms there.

Third party JavaScript can also be another major cause of a poor score in the total blocking time metric on Google PageSpeed insights. With third party JavaScript, you only want to load essential scripts. If you can choose to remove the script from your website, or serve it locally that's the best bet.

Your website is probably loading third party JavaScript from multiple sources. If you use Google analytics, you're loading third party JavaScript, if you use stripe or PayPal payment processing, you're loading third party JavaScript, and the list goes on and on.

Removing these scripts is typically impractical or impossible to do, so efficiently loading third party JavaScript is the best remedy.

Unless your script has to run before the page renders, you should always load it asynchronously (you can also defer it). the way you do this is by adding async or defer tags on the script element. However, if you're a casual WordPress user, this may be difficult as it could be hard coded into your themes or plugins. That means changing it on a code level doesn't make any sense, as every update to a plugin or theme would overwrite it.

This is where our favorite performance optimization tool comes back into play, Asset Cleanup. For individual JavaScript files, with the pro version of asset cleanup you can choose to load it asynchronously or defer it with a single check box.

Efficiently loading third party JavaScript falls into the “eliminate render blocking resources” category of speed optimization. If you'd like to learn more, we have a complete blog post on how to eliminate render blocking resources here: https://isotropic.co/how-to-eliminate-render-blocking-resources-for-wordpress-websites/.

Optimizing JavaScript as a whole will also directly impact your total blocking time metric. JavaScript optimization consists of merging and minifying all JavaScript files, and then loading them asynchronously or deferring them depending on how they are used in your page. With WordPress, there a bunch of automated tools that will allow you to do this. Our favorite is called WordPress rocket, which is a caching and performance plugin.

Here's what we have to say about the plugin, quoted from our article How To Eliminate Render Blocking Resources:

WP Rocket is our current favorite WordPress speed plugin. It’s paid, but extremely powerful – the price to value ratio is off the charts. It’ll allow you to do a lot, but specific to this post, you can load Javascript deferred, exclude some files from this optimization (the important ones that are required immediately) and run the deferral in “safe mode” which attempts to automatically exclude essential scripts from the deferral. On the CSS side, you can automatically determine which CSS should be loaded asynchronously on your site, and apply that loading style (all as a background process). We love this plugin because it’s super powerful (and easy) for both developers and less-technical website owners.

Let's say that you addressed all three of these optimization points, and you're still scoring poorly in your total blocking time.

If we go back to the individual elements that make up total blocking time, only long tasks are associated with this metric. The way to address pesky long tasks/scripts is to identify them, and break them up or remove them altogether.

If a standard optimization of your website does nothing for your total blocking time, then there are probably a few individual scripts that are causing a poor score in this metric. To fix this, you first need to identify the scripts that are causing the issue, and then remove/optimize them individually.

Individually Optimizing Long Tasks

To individually optimize a long task, you first need to identify it. If we think back to our standard definition, a long task is anything that takes over 50 milliseconds. In a recent update to the development tools offered in the chrome web browser, Google added a functionality that will allow you to easily identify long tasks.

This graphic visually identifies long tasks. you can see that the long tasks are exactly that, long tasks. They take over 50 milliseconds to load, and you can see that on the millisecond axis on the top of the graph.

You can access this chart in the performance panel of Chrome Dev tools. Under the performance panel, click the record button, and reload your website. This will record everything that loads and occurs during the rendering process of your page. Once the page is fully loaded, stop the recording, and it will create a chart similar to the one displayed above.

If you isolate the loading event The loading event of the website using the user interface on the top of the window, you can zoom in and up to see flagged long tasks.

We have adjusted the scale of the recording to only show where we re loaded the web page. In the recording, long tasks are identified by the Gray bar with a red corner triangle.

For example, the Gray bar with the red corner triangle and the hatching that takes up half of the bar is a long task. By hovering over it we can see how long it took to load. In this case it took 83 milliseconds, which is over the 50 millisecond limit toggling the long task. By clicking on the individual bar, more information will show in the bottom of the window.

This in itself isn't bad, but if you have too many long tasks that are over 50 milliseconds, they all get added up into total blocking time.

You can use this tool to identify long tasks that are extremely out of the mean. So say your average long task took anywhere from 50-150 milliseconds. If you visually identify a task that is taking much longer than your average task, then you would want to address it. So say you visually identified a task that was taking 600 milliseconds from start to finish. That seriously impacts your total blocking time score, so addressing it will definitely increase that metric.

If you have identified a task that needs to be optimized, the best way to do this is to split it up into smaller chunks. Preferably, you'd want to split up your code into 50 millisecond loading chunks. This means it falls under the threshold for the total blocking time, and will not apply to the aggregate metric.

If you would like to read about the theory behind code splitting, Google has published a great guide on how to do this.

https://web.dev/reduce-javascript-payloads-with-code-splitting/

However, this guide is more oriented towards developers who are creating digital properties from the ground up. If you're on the WordPress platform, you're already using a content management system, and a pre packaged platform.

https://www.smashingmagazine.com/2018/02/code-splitting-wordpress-pop/

If you took a look at the Smashing Magazine article, you will definitely see that it is fairly complicated to split code in WordPress.

It doesn't make much sense to address tasks that fall within the median blocking time period but if you find a task that is two times, four times, six times longer then every other task, that's something that you should take the time to fix.

Instead of doing this, if you have identified a super long task that needs to be optimized, it may be better to simply remove it and replace it with something that does the same thing. So, for example if it's coming from a third party script, replacing the third party script with something else may be a good idea. If it's coming from a plugin, disabling the plugin on pages that it's not used, or replacing the plugin may be a better idea than trying to split the JavaScript.

And, most of the times you won't need to even consider splitting code, as a general optimization of JavaScript should be more than enough to address a poor total blocking time metric with a WordPress website.

Conclusion

This article should have addressed the essential question of “what is total blocking time” by giving you a good overview of what goes into the metric, how it's calculated, why you should care, and how to improve TBT.

In summary, total blocking time is the total amount of time it takes long tasks to become interactive. Translated to English, this refers to the time between the loading of an individual element, and the interactiveness of an individual element. Total blocking time adds up all the individual blocking times and spits out the aggregate figure.

You want to score under a 300 millisecond cut off. If you're scoring over 300 milliseconds sent total blocking time, that means that you need to address this metric individually.

Improving total blocking time can be done by focusing on general JavaScript optimization. This means merging and minifying the files, optimizing or eliminating third party scripts, and loading it asynchronously or deferring it. If none of these methods work, you'll need to address the individual long task by manually going in and optimizing it.

If you have any question about total blocking time, and how to optimize your WordPress website, feel free to reach out in the comments -- we'd love to point you to some resources that may help.