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.
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?
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.
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.
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.
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.
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.
Here's what we have to say about the plugin, quoted from our article How To Eliminate Render Blocking Resources:
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.
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.
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.
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.
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.
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.