What Is Total Blocking Time?

TBT or Total Blocking Time is a key lab metric that is used to measure load responsiveness since it aids in quantifying the severity of a page’s non-interactivity before it becomes reliably interactive. If a page has a low TBT score, it will ensure the page can be easily used by visitors however if the score is high, that indicates that there is a problem that requires urgent rectification to speed up the page’s loading.

Essential, the Total Blocking Time metric will measure the length of time taken between FCP (First Contentful Paint) and TTI (Time to Interactive) where blocking of the main thread was long enough to stop input responsiveness.

Any time there is a Long Task (i.e. one which runs for over 50 ms on the main thread), the main thread is said to be “blocked” since browsers are unable to interrupt tasks that are already in progress. In such cases, if a user interacts with the webpage during the processing of a long task, it’s necessary for the browser to wait until the task has finished before it’s able to respond.

When tasks are long enough (for example, anything more than 50 milliseconds in length), users are likely to notice that there is a delay, and they will perceive that webpage as janky or sluggish, thus ruining their experience.

A long task’s blocking time is its duration when it is longer than 50 ms. Meanwhile, a page’s total blocking time (or TBT) represents the sum of the blocking times for every long task occurring between TTI and FCP.

TBT And TTI – How Do They Work Together?

TTI (Time to Interactive) and TBT work well together as companion metrics since TBT helps to quantify how severe a page’s non-interactivity is before it becomes reliably interactive. A page is considered by TTI to be reliably interactive when the main thread remains free from long tasks for a minimum of 5 seconds.

As a result, three tasks lasting 51 ms spread across 10 seconds could push TTI back the same length of time a just one long task lasting 10 seconds. However, to users interacting with that page, both scenarios feel extremely different.Three tasks lasting 51 ms each have a 3 ms TBT whereas one long tasks lasting 10-seconds has a 9950 ms TBT – a far worse experience for users.

How Is TBT Measured?

TBT should always be measured not in the field but in the lab. Running Lighthouse performance audits on your website is the best way to achieve this, although there are other tools such as WebPageTest and Chrome DevTools that can do the job too.

Although measuring TBT in the field is technically possible, it isn’t recommended since user interaction affects a page’s TBT in such ways that a lot of variance can be found in the reports. In order to understand the interactivity of a page in the field, measuring FID (First Input Delay) is the best course of action.

If a site is to give users a good experience, it should aim to have a TBT of under 300 ms when tested using standard mobile hardware.

How Can TBT Be Improved?

There are several ways to improve TBT including:

Reducing Request Counts of 3^rd Party Scripts

3^rd party scripts reduce the performance of a web page considerably, therefore reducing them as much as possible is imperative. Since most 3^rd party scripts won’t affect a web page’s content, delaying the download, parsing and execution of any 3^rd party scripts until the primary content is being downloaded represents a vital optimisation process which can improve FCP, LCP, FID and also Speed Index performance metrics. Third-party script sizes should also be decreased.

Minimising The Work Of The Browser’s Main Thread

When a main thread is busy for over 50 ms continuously, some Main Thread Work Sections must be optimised. You’ll need to determine which of the sections has taken most time in order to implement optimisations.

 These include optimising third-party scripts, reducing the Main Thread’s work with web workers, avoiding complex and long input handlers, reducing the variables’ scope for style calculations, avoiding layout thrashing, minifying, compressing and refactoring CSS, cleaning unused codes, deferring non-critical JavaScript and CSS and using code-splitting to reduce JavaScript payloads.

Decrease The Web Page Assets’ Size & Request Count

Transfer Amount and Request Size are key factors affecting the performance of a web page. Having smaller file sizes as well as lesser request amounts is vital when it comes to improving TBT performance as a browser’s main thread is capable of downloading smaller files more quickly with lesser request amounts.

You can achieve this goal by optimising images with pixel reducing algorithms and better extensions, creating JavaScript and CSS bundles, removing unused codes, optimising and compressing font files, cleaning unnecessary inline style & script tags and HTML nodes, and turning GIFs into automatically starting videos in a loop.

Optimising TTFB

Reducing TBT requires you to have a fast server and optimised TTFB. You can optimise TTFB by avoiding the usage of dynamic content and configuring your web server for lesser query. You could also optimise your back-end infrastructure and improve your server hardware as well as using a CDN service, advanced caching and service workers.

The Importance Of TBT

TBT is an incredibly important metric to consider when it comes to load responsiveness. When web pages aren’t responsive during loading, users become frustrated and are likely to go to a competitor’s website. Furthermore, since search engine algorithms place weight on users’ experiences during their ranking of web pages, failing to optimise TBT will negatively impact on your site’s SERP.

If you follow the advice laid out here, you should find that your TBT will be improved and your website visitors will enjoy a far better experience. This, in turn, will boost your site’s search engine results ranking, and will help to ensure that your site is as profitable and revenue-producing as possible.