Total Blocking Time (TBT) sums the portions of every long task (over 50 ms) that fall between FCP and Time to Interactive. It is a lab-only metric reported by Lighthouse and is the closest synthetic proxy for the field metric INP.
Why it matters
A high TBT means the main thread is busy parsing, compiling, or executing JavaScript when the user is trying to click, tap, or scroll. web.dev's good threshold is under 200 ms on mid-range mobile; over 600 ms is poor. Because TBT runs in the lab, it surfaces during CI long before users feel the lag — making it the right gate to keep responsiveness regressions out of production. TBT is not a Core Web Vital itself, but it correlates strongly with INP, so improvements you make to lower TBT usually move field responsiveness in the same direction.
How to fix
- Profile long tasks in DevTools' Performance panel and look for tasks above 50 ms.
- Code-split routes and defer non-critical bundles with dynamic
import(). - Move heavy work off the main thread with Web Workers or
scheduler.yield(). - Audit third-party scripts — analytics, chat widgets, A/B tools — and load them after interaction when possible.
- Reduce framework hydration cost by hydrating components on demand or shipping less client JavaScript.
- Track TBT trends in lab data alongside the legacy FID and current INP.