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 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,
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.
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.