Total Blocking Time is one of six metrics that website owners can find in the Performance section in Lighthouse, it is not necessarily part of the Core Web Vitals, but we can learn a lot from it.
Definition of Total Blocking Time
TBT is measured in milliseconds (ms) and assess how responsive your website is to input from the user. Put simply; the Total Blocking Time measures the amount of time that your webpage was blocked for, therefore preventing the user from interacting with the page.
The main thread is where the browser will parse HTML, construct DOM, execute JavaScript and CSS, process events and other essential tasks. If any one of these runs for longer than 50 ms, it is considered a Long Task. When this happens, the main thread is seen as “blocked” because the browser cannot interrupt a task that is already in progress.
The excess time beyond 50 ms is considered as the individual blocking time for that request. The sum of all these blocking times is your page’s Total Blocking Time. So in the above image, while the total time spent running tasks on the main thread is 560 ms, 345 ms of that time is considered blocking time.
Why the TBT Matters
The TBT matters because if the main thread is blocked, your page can’t respond to user inputs like screen taps, keyboard actions, or mouse clicks. For this reason, optimising your TBT can often make one of the most impactful improvements in your website’s responsiveness. What’s more, TBT accounts for 25% of your PageSpeed Performance score, so getting this right is key to a good score.
The Total Blocking Time thresholds are as follows:
- Less than 300 ms = good; no action needed.
- Between 300 – 600 ms = moderate; some changes recommended.
- Greater than 600 ms = bad; changes needed.
According to Google, “sites should strive to have a Total Blocking Time of less than 300 milliseconds when tested on average mobile hardware” to provide a good user experience.
How to Optimise for Total Blocking Time
Once you’ve found the Long Tasks that are causing you issues in Lighthouse, I would suggest the following:
- Reduce requests for third-party scripts,
- Reduce the size of third-party scripts,
- Minimise the browser’s main thread work,
- Clean-up unused JavaScript and CSS,
- Compress JavaScript and CSS files,
- Use code-splitting to break up JavaScript assets.
You can start by removing third-party scripts and explore ways to delay the downloading, parsing, and executing these third-party scripts until the main content is downloaded to make a big difference.
You can use Chrome Dev Tools to see all of the main thread processes in the performance tab. Knowing which tasks took the most time to load, you can better understand where to start. In the below image, we can see the long tasks present and see the asynchronous loading events that could be optimised.
Removing unused CSS and JavaScript is also a no-brainer. If your website loads scripts that aren’t used, you’re pointlessly loading data and inflating your page load time. Optimising JavaScript as a whole will also directly impact your total blocking time. JavaScript optimisation involves merging and minifying all JavaScript files and then loading them asynchronously or deferring them depending on how they are used on your page.
Going back to the image above, by clicking on the first long task, we see some more details about the task, including the task’s length, which in this case was 229.51 ms. This is where code splitting can help break them up into chunks that load under 50 ms. Google has published a guide on how to do this.
Tools for Measuring Total Blocking Time
TBT is a metric that should be measured with lab data. For me, the best way to measure this is to use Lighthouse, but Google lists the following as lab tools (with simulated data) for measuring Total Blocking Time:
