You’ve probably already come across Total Blocking Time (TBT) if you’re looking to optimize your Google Core Web Vitals and PageSpeed Insights score.
To summarize, this webperf metric is an equivalent of the First Input Delay (FID, which is part of the Core Web Vitals) which allows to evaluate the responsiveness of the pages. The shorter the TBT, the more likely the page is to be responsive.
But let’s go beyond this brief summary to understand exactly what Total Blocking Time measures, how to evaluate it, and techniques for improving it.
What does Total Blocking Time (TBT) measure?
After clicking on a button or a link, the Internet user expects an immediate response, and this feeling of immediacy is around 100 ms . Ideally, for an optimal user experience, the browser’s reaction time should even be 50 ms. Quite a challenge!
Now, if a page does not react to clicks or does not respond to interactions, it is a sign that the browser’s main thread is busy with other tasks. These tasks can be more or less long, and we speak of “ long tasks ” when they last more than 50 ms . Without wanting to denounce, these long tasks are in most cases caused by JavaScript scripts .
Thus, TBT evaluates the accumulation of all task-related time ranges that exceed 50 ms, beyond these 50 ms, and during which the browser cannot respond to interactions .
In practice, here is how the Total Blocking Time is calculated:
The main thread on page 1 has half as many tasks to process, but its TBT is 6 times longer because the accumulation of execution time of long tasks that exceed 50 ms is greater
What are the differences between Total Blocking Time and First Input Delay (FID)?
While TBT is an accumulation of times a browser cannot respond to interactions – as we just saw – First Input Delay measures the time between when a user first interacts with a page and when the browser is actually able to respond to that interaction.
Another notable difference is that FID is measured based on real user interactions with Real User Monitoring (RUM), while TBT is measured in a synthetic or simulated environment. As such, TBT does not take into account user behaviors, or whether or not the page has an interactive aspect that can influence when users are tempted to click somewhere or scroll.
Finally, First Input Delay is part of the Core Web Vitals, but not the PageSpeed score.
However, since version 6 of Lighthouse, which serves as the basis for the PageSpeed Insights score, the TBT is part of the PageSpeed score calculation .
Although these two webperf KPIs are correlated, since TBT and FID are not measured under the same conditions, the scores can be different, or even really far apart. Thus, a page can have a bad FID despite a very good TBT if the responsiveness is poor following the first interaction of a user.
The reasons for these discrepancies are explained in this article dedicated to FID , and we also did a test to see what could happen to the PageSpeed score if Google took into account the FID instead of the TBT …
How to measure Total Blocking Time?
Total Blocking Time can be measured using Lighthouse or PageSpeed Insights , knowing that these tools impose the test conditions defined by Google , and over which you have no control (these conditions are not necessarily to your advantage, nor always representative of your website’s audience).
On PageSpeed, you can find your Total Blocking Time in the Lab data section , with details on Google’s recommendations to optimize your performance. Note that TBT can be measured with Field data, but Google does not recommend it and instead recommends FID or INP to measure interactivity with field data.
Total Blocking Time can also be evaluated with Chrome Dev Tools, and also Web Page Test if you want to define specific test conditions (browser, device, geographic area…), as well as GTmetrix, SpeedCurve, Calibre…
Visualization of tasks in Chrome Dev Tools,
with each task represented on the horizontal axis with its duration
Choosing test conditions is particularly relevant to simulate conditions that correspond to those of the majority of your visitors, and which you can discover using Google Analytics , or via your web analysis tools.
Why optimize Total Blocking Time?
This question may seem rhetorical, but here are the main benefits to remember for a site that optimizes Total Blocking Time:
- improved user experience through more responsive pages
- and therefore better conversion rates with satisfied and engaged users,
- lower bounce rates , as users are less likely to leave the site in frustration because it doesn’t work,
- a better image of the quality of your site and your brand;
- a better PageSpeed Insight score , since TBT is included in the calculation of this score;
- potentially a better First Input Delay too, since what improves interactivity contributes to a better FID,
- therefore better Core Web Vitals ,
- and logically, better SEO , since Google takes into account the quality of UX in its ranking algorithm .
How to improve Total Blocking Time?
Before you take action to optimize your loading speed, think about the Performance Budget !
It is essential for an overview, knowing where you are starting from, defining your objectives, and evaluating the impact of your actions to speed up the loading of your pages.
Regarding Total Blocking Time, the threshold recommended by Google is a maximum of 200 ms (although, as we saw earlier, the threshold for a good UX is 100 ms).
And concretely, what are the techniques for improving Total Blocking Time?
- Reduce the impact of third-party scripts
- remove scripts that are not useful for your pages,
- defer non-essential scripts to the beginning of the page load,
- use fast loading facades , while waiting for your third parties to load;
- Reduce the amount, weight and execution time of your JavaScripts
- optimize your JavaScript code (minify, concatenate and compress);
- Serve your resources with HTTP/3 to parallelize your requests;
- Reduce the work of the main thread
- move long running tasks to a separate thread,
- break down long tasks into smaller ones, and use APIs that let you know the browser is busy or available to respond to interactions,
- check for JavaScript errors and file conflicts to avoid thrashing which causes pages to reload or repaint ,
- use CSS for animations and effects instead of JavaScript when possible.
Total Blocking Time: monitor, optimize, automate
We have just seen the main good practices for measuring and improving TBT.
With optimized pages and code, you will save your users time, and at the same time improve your UX, SEO and turnover. On our side, we have the solution to also save your technical teams time .
Indeed, the work of optimizing the front-end of a site requires constant attention , but a site evolves continuously. It is enriched with new content, new functionalities…
So, to not lose the fruits of your hard work and for the results to remain visible in the long term, automate all the optimizations necessary to comply with Google’s recommendations, and maintain them over time without effort : trust our engine!
In addition to automatically applying techniques to optimize your TBT, and all of your web performance metrics, Fasterize takes care of maintaining them even when your site evolves or is redesigned .
You relieve both your users and your technical teams, in addition to supporting your SEO and your business.
TBT, Core Web Vitals, Speed Index…
Do you want to master all the essential web performance metrics?
