You can Evaluate the TBT score by calculating the total amount of time that a page is blocked from responding to a user action. The total is calculated by adding the blocking time of all long tasks between First Contentful Paint (FCP) and Time to Interactive (TTI).
Let me explain better.
Every browser has a process that transforms the code into a web page. This action of processing all the code and styles needs to be effective because we want our page to be rendered as quickly as possible for the visitor. (Remember, we want to make a good impression and show the user how fast our website is!)
The browser has many tasks to complete until it can render the page, such as parsing the HTML script, building the structure and the content of a web page (DOM), and executing its CSS and JS code.
To avoid a high blocking time, the browser should not encounter the JS and CSS files when parsing the code and rendering the page. To keep your website going fast, we have to “tell” the browser what we want to prioritize and what we want to load first.
Understanding Long Tasks
If the tasks run longer than 50ms, it is referred to as a Long task and considered “blocked.”
In such a case, your page becomes unresponsive to user inputs like screen taps, keyboard presses, mouse clicks, etc.
The calculation of Total Blocking Time is based on those Long Tasks. A Long Task significantly monopolizes the web browser (> 50 milliseconds) and blocks the performance of other essential tasks (such as reacting to user actions with a mouse click). The main thread is considered “blocked” any time there’s a Long Task. The computer records this interval for each request as an individual blocking time. The sum of all individual blocking times is called total blocking time.
Let’s see an example. Every time Lighthouse detects a Long Task (>50 ms) then it will also Evaluate the blocking duration:
As you can see, the Total Blocking Time is a sum calculated by adding the “blocking” portion of the different Long Tasks. The blocking portion of a Long Task is the part of its duration beyond 50 ms (in red on our chart).
Let’s see another task’s breakdown to identify the TBT:
- The timeline below has five tasks, and three are Long Tasks (duration >50 ms):
- The next graph shows the blocking time for each of the long tasks, respectively 200 ms, 40 ms, and 105 ms (Total: 345 ms)
2 Tools to Evaluate Total Blocking Time
We recommend two different tools to Evaluate TBT and your performance using the Lighthouse technology.
- Google PageSpeed Insight (PSI):
Both tools provide a TBT score, but the numbers are slightly different, as you may have noticed. This is mainly due to various factors, including Lighthouse implementation, testing methodology, testing location, etc.
What’s a Good Total Blocking Time (TBT) Score?
You should always strive to have a TBT of less than 300 ms to ensure a good user experience. Your TBT score is simply a comparison of the TBT time of your page and the TBT times of high-ranking thousands of sites when loaded on mobile or desktop.
Scoring is classified as:
- Green: 0-300ms (Fast)
- Orange: 300-600ms (Moderate)
- Red: 600+ms (Slow)
What Is the Difference Between Total Blocking Time and First Input Delay?
While Total Blocking Time can be calculated without real-world users, First Input Delay (FID) is a field-only metric that requires real-user data for computations.
The FID calculation cannot be simulated in a lab environment. This form of data comes from multiple sources, such as the Chrome User Experience Reports (CrUX), where the data collected are from real-world users.
When your website does not have enough “real” data to compute the FID score, the alternative is to look at the TBT metric, Evaluated in the lab data section. The lab data has artificial and collected data from a single device based on a fixed set of network conditions.
In a different way, both TBT and FID Evaluate interactivity and capture a user’s first impression of a site’s interactivity and responsiveness.
For example, GTmetrix tests TBT instead of FID as it diagnoses almost the same optimizations with the suitable proxies:
By optimizing your Total Blocking Time, you’ll also improve the First Input Delay score, one of the Core Web Vitals metrics — there is a positive correlation between them. Of course, the opposite is also true.
If you keep your FID below 100ms, you’re in great shape:
What Is the Difference Between Total Blocking Time and Time to Interactive?
The main difference is that Time to Interactive Evaluates how long it takes for a page to become fully interactive, while Total Blocking Time tells you which JS tasks took the longest to execute.
Time to Interactive is another metric that is related to your page interactivity. It’s one of the six metrics tracked in the Lighthouse report to Evaluate the performance of your website.
Measuring TTI is vital because some sites focus on content visibility at the expense of actual interactivity. This can create a frustrating user experience: the user thinks that the site is ready, but when he tries to click somewhere, nothing happens.
TTI (in orange below) marks a page as fully interactive if the main thread has been free of long tasks for about 5 seconds.
Here’s a test for you. In the following image, when do you feel like you could interact? When does the blue-button become “clickable” in your mind?
What Is the Impact of Total Blocking Time on Performance?
To understand the impact of TBT on performance, once again we should highlight its weight on the Lighthouse Score.
As a user experience metric, TBT now holds up to 30% of the global performance score.TBT did not exist in Lighthouse v5, but it now represents 30% of the total grade in Lighthouse v8.
TBT Evaluates the total amount of time your webpage was completely blocked, preventing the user from interacting with the sections of your page. It’s an important lab metric because it defines if your page is usable or not.
There are several basic principles to follow to keep your TBT under 300ms but first, let’s have a look at the causes of a bad TBT.
What Causes a High Total Blocking Time?
There are four reasons that determines a TBT score longer than 300 ms, namely:
- A high JS Execution time
- A high main thread work
- Heavy use of a third-party code
Going to the opportunities and diagnostics section of your Lighthouse report will help in determining what solutions you can implement:
The report shows how much impact each error has on your estimated savings; resolving them will drastically improve your TBT and your site’s performance.
Here is the list of the PageSpeed Insights recommendations to address if you want to improve your TBT score:
- Minify CSS and JS
- Eliminate render-blocking resources
- Reduce the impact of third-party code
- Enable text compression
- Avoid chaining critical requests
- Avoid enormous network payloads
- Minimize main thread work