Front-End’s Missing Metric: The TBT Window – CSS Wizardry

Arrange a Masterclass

1 June, 2026

Front-End’s Missing Metric: The TBT Window

Written by Harry Roberts on CSS Wizardry .

Table of Contents

Independent writing is brought to you via my wonderful<br>Supporters.

A Quick Refresher

The TBT Window

The LCP Improvement That Tanked TBT

Why TTI Can Move

Causality Can Run Both Ways

How We Fixed It

Make the Window Visible

Closing Thoughts

Citation

An incident (and it was an incident!) on a client project got me thinking<br>about the metrics we use, and the importance of fully understanding their exact<br>definitions. Bizarrely defined and often overlooked specs sent panic around<br>a team, but ultimately shed light on a tangible gap in our front-end tooling.

For my client, from one SpeedCurve synthetic test<br>to the next, their Total Blocking Time (TBT) skyrocketed from 495 ms to<br>5,789 ms . That’s more than a tenfold increase! Naturally, it was all<br>hands on deck to pin down the cause, and I was called in to help<br>out.

What I found was both enlightening and calming, but it did shine a light on<br>a gap in the way we tend to talk about modern web performance metrics.

This is the story behind a new web performance<br>metric I like to call<br>the TBT Window.

Get in touch

Need Some Help?<br>I help companies find and fix site-speed issues. Performance audits , training , consultancy , and more.

A Quick Refresher

Total Blocking Time is a lab metric intended to<br>quantify how unavailable the main thread is during page load. It looks at long<br>tasks—work that occupies the UI thread for<br>more than 50 ms—and counts only the blocking portion of each one.<br>A 70 ms task contributes 20 ms to TBT; a 250 ms task contributes<br>200 ms. The first 50 ms of any task is effectively tolerated, and<br>anything beyond that is considered blocking time.

It is a lab-based proxy for the more real user-centric Interaction to Next<br>Paint field metric.

This much is probably familiar, but the part that is often overlooked is that<br>TBT is not an unbounded sum of all blocking work in the trace: it is a sum of<br>all the blocking time between First Contentful Paint and Time to<br>Interactive.<br>This is key to understanding the context of the TBT metric itself.

First Contentful Paint (FCP) opens the window<br>and is the first point in the page-load timeline at which the user can see<br>something contentful on screen—the page is responding. Time to<br>Interactive (TTI) closes the window and is the<br>point at which the page is considered reliably interactive.

TBT is the blocking work that happens between those two moments.

This is slightly clumsy or even unexpected because TTI itself has largely<br>disappeared from our day-to-day vocabulary. Lighthouse 10 removed<br>TTI from the performance<br>score after a deprecation process that began in Lighthouse 8, and for perfectly<br>sensible reasons: TTI was highly variable and overly sensitive to outlier<br>network requests and long tasks. It is also seemingly arbitrarily defined<br>and hard to reason about:

Start at First Contentful Paint (FCP).

Search forward in time for a quiet window of at least five seconds, where<br>quiet window is defined as: no long tasks and no more than two in-flight<br>network GET requests.

Search backwards for the last long task before the quiet window, stopping<br>at FCP if no long tasks are found.

TTI is the end time of the last long task before the quiet window (or the<br>same value as FCP if no long tasks are found).

Wow.

TTI is found by identifying the quiet window first, then walking back to the last long task before it.

The fact that TTI has been retired from the report, however, does not mean it<br>has stopped influencing the numbers we still care about. If you are monitoring<br>TBT, TTI still defines the far edge of the measurement window and changes in TTI<br>scores can impact your TBT scores even in cases you might not expect.

Hopefully now you can see the problem. Per Google’s own documentation, TTI<br>proved overly sensitive to outlier network requests and long tasks, yet<br>if TTI also defines the upper bound for TBT, those same outliers can increase<br>(or decrease) the surface area you’re being tested against.

A degraded TTI score can degrade your TBT score. You’re effectively still<br>being measured against it. This is exactly what happened to my client.

The TBT Window

You might also like…

Tags in CSS files<br>(2012)

Once you think of TBT as a windowed metric, a few otherwise surprising<br>behaviours become much easier to explain. The TBT Window is the interval between<br>FCP and TTI during which TBT is allowed to count blocking work. If FCP moves<br>earlier, the TBT Window opens earlier, so long tasks that used to sit before FCP<br>can suddenly fall inside the window. If FCP moves later, the opposite can<br>happen: long tasks can fall out of scope without having been removed from the<br>page.

The same is true at the other end. If TTI moves earlier, the window closes<br>sooner and late long tasks may stop contributing to TBT. If TTI moves later,<br>the...