Total Block time or TBT is a metric, which is used in the measurement of the total time after the First Contentful Paint. This is where the main thread has been blocked for some time to avoid any input responsiveness. There are various web tools that stop the monitoring of the TBT once the Time to Interactive or Time to Interactive has completed the page loading process.
Here the main thread is considered to be blocked if there is a Long task going on. This is the task that runs within the main thread for above 50 milliseconds. Talking about being blocked, the term is used as the browser is unable to interrupt a certain ongoing task.
Hence in such a case when the user manages to interact with the page while the long task is going on, the browser needs to wait for the task to complete before it can generate any response.
However, there are times when a certain task will take more than 50 milliseconds to complete, it is then that the delay will be noticed by the user that the page is ‘slow’, ‘sluggish’ or even broken. So, what precisely defines the total Block time?
By definition it is the total blocking time for a certain page and this is calculated as the sum of the blocking time for every long task that takes place once the FCP has been done for a certain timeframe. This is generally TTI incase of the page load tools and total trace time in case of other tooling.
TBT and TTI
Now, how is total blocking time different from Time to Interactive? Let us explore. To start with, total blocking time or the Total Block time is measured for a certain time period. In case of certain lab tools, which are normally used for the measurement of the page loads, such as Lighthouse, the total blocking time is measured till TTI.
This is because the latter helps to quantify just how severe the non-interactivity of the page is, before it grows reliably interactive. Nevertheless, the total blocking time can continue to be measured even after the page load is done and also after TTI. A classic example for this is the Lighthouse Timespan mode.
A page is considered to be ‘reliably interactive’ by TTI once the main thread grows free from the long task for a minimum of 5 seconds. For example, three 51 ms tasks spreading out for 10 seconds can cause the TTI to be pushed back almost as far as ‘one’ 10-second long task. However, both these situations will appear to be quite different for a user who is trying to interact with the page.
Nevertheless, when it comes to the first case, the three 51 ms tasks comprises a TBT of 3 milliseconds. Likewise a single 10-second long task would contain of a total blocking time of 9950 milliseconds. So, you see, greater is the total blocking time value as in the second case, it is categorized as a ‘bad’ scenario.
Now, you can understand why the total blocking time is usually considered to be a preferred metric as compared to the TTI, as it is far less prone to outliners. It is the same case even when the TTI is taken into account as an endpoint for calculating total blocking time.
Measuring Total Blocking Time
Basically, TBT is a metric which can be measured in a lab. However, the best way to measure the TBT is to have the Lighthouse performance audit run it within your site. Here the best known lab tool used are:
- WebPage Test
- Lighthouse
The Total Blocking Time Score
A Total Block time of less than 200 milliseconds is considered to be a ‘good’ TBT score. This implies that the user is offered a good experience as the Total Blocking Time is tested on an average mobile hardware.
Now, the good news is that there are plenty of ways to improve the Total Blocking Time score, let us take a look at a few.
The Best Methods to Improve the TBT Score
Here are some of the best:
-
The third-party code
Did you know that third-party scripts greatly affect the page load performance of your website. This usually occurs when you need to add an advertising network, A/B test, Social Media button or any analytics services to your page.
In this case you need to identify the slow third-party scripts in order to know how to use the Chrome DevTool and the other Lighthouse audits in order to detect those third-party codes that are causing problems.
-
To Reduce the JavaScript Execution Time
When the Javascript is taking too long to execute, then it tends to slow down the performance of the page in various manners:
The Network Costs: This implies more bytes that translates to longer download times.
Parse and Compile Cost: It is the Javascript that gets compiled and parsed within the main thread. Here, the page is not able to respond to the input by the user when the main thread is busy.
The Execution Cost: The Javascript is also executed within the main thread. However if there are innumerable threads that run on your page then, this can lead to delay in the Time to Interactive which is one of the prime metrics when it comes to how the page is perceived by the users.
Memory Costs: A lot of memory is consumed if the Javascript holds on to plenty of references. This is why the pages might appear to be slow. Also the memory leaks can lead your page to freezing-up all together.
-
To Minimize the Main Thread Work
It is because of the render process of the browser that the code is converted within your web page. However it is the main thread of the renderer process that generally manages most of the codes. This is done by parsing the HTML and building the DOM. Likewise, it also parses the CSS and applies it to the certain styles. Lastly it parses, evaluates and executes the Javascript.
CONCLUSION
What is total blocking time and How to Improve it? Well, now you know all about it. Write to us, on how you found our article and we would love a feedback