Track costly browser main-thread delays with precision and context. Compare tasks, thresholds, and sessions easily. Turn timing data into practical optimization priorities starting today.
Use the fields below to model a single page flow and the task timings that shape its Total Blocking Time.
This example mirrors the default sample loaded in the calculator and produces a Total Blocking Time of 480 ms.
| Task | Start (ms) | Duration (ms) | Blocking Contribution (ms) |
|---|---|---|---|
| App bootstrap | 1400 | 180 | 130 |
| Route hydration | 2100 | 95 | 45 |
| Recommendation widget | 2870 | 260 | 210 |
| Analytics bundle | 4150 | 75 | 25 |
| Chat launcher | 5750 | 120 | 70 |
Assumptions: FCP = 1200 ms, TTI = 6200 ms, threshold = 50 ms, sessions per day = 12,000, page share = 100%.
Window duration = Time to Interactive − First Contentful Paint
Task overlap = max(0, min(task end, TTI) − max(task start, FCP))
Blocking contribution per task = max(0, task overlap − blocking threshold)
Total Blocking Time = sum of all blocking contributions inside the measured window
Impacted sessions per day = sessions per day × page share
Daily blocked seconds = (Total Blocking Time × impacted sessions per day) ÷ 1000
Total Blocking Time measures how long the browser main thread stays unavailable between First Contentful Paint and Time to Interactive. In practical audits, each task contributes only the time above the chosen threshold, commonly 50 milliseconds. This makes TBT useful for ranking scripts, hydration work, third party tags, and delayed interaction readiness across product, checkout, dashboard, and content pages.
Engineering and growth teams use TBT because it links technical execution to user frustration. When blocking rises, taps, clicks, and typing often feel delayed, especially on mid range mobile devices. A page with 650 milliseconds of TBT usually needs broader scheduling changes than a page at 180 milliseconds, even when their visual paint metrics appear similar during a lab review.
This calculator captures the main components required for a fast assessment: FCP, TTI, threshold, sessions, page share, and a task list with start times and durations. Those fields allow teams to compare isolated script costs with scaled business impact. By multiplying TBT by affected sessions, the tool translates milliseconds into blocked seconds that leadership can understand quickly.
The result panel highlights total blocking time, blocking density, largest blocker, average blocking per long task, and estimated blocked minutes per day. Together, these values answer three questions: how bad the contention is, which task deserves attention first, and how widely the issue spreads across traffic. The classification badge helps teams separate acceptable pages from pages needing immediate scheduling and code splitting work.
High TBT often comes from bundled application startup, synchronous parsing, heavy component hydration, long event handlers, or multiple third party tags competing in the same window. The strongest fixes usually involve reducing shipped JavaScript, breaking tasks into smaller chunks, deferring noncritical widgets, delaying analytics initialization, and moving expensive work off the critical interaction path whenever measurement confirms the gain.
Used consistently, the calculator supports sprint planning, release reviews, and performance budgets. Teams can compare scenarios before shipping a feature, estimate exposure on high traffic templates, and validate whether a deferred script meaningfully cuts user waiting time. That combination of technical precision and operational scaling makes Total Blocking Time a bridge between browser performance data and product decision making.
A practical target is 200 milliseconds or less. Between 200 and 600 milliseconds usually needs improvement, while values above 600 milliseconds often indicate noticeable interaction delay.
The threshold removes short tasks that are less likely to feel disruptive. Only time above the threshold counts toward blocking, which keeps the metric focused on meaningful main-thread contention.
Yes. If a task starts before FCP or ends after TTI, only the overlapping portion inside the measurement window is evaluated for blocking contribution.
Those inputs scale technical delay into operational exposure. They estimate how many users encounter the issue and how much blocked time accumulates across daily traffic.
Not always. TBT improves interaction readiness, but it should be reviewed with paint, loading, and field data to understand the full user experience picture.
Common wins include splitting large tasks, deferring noncritical scripts, trimming bundle size, reducing hydration cost, and delaying third party work until after interaction becomes reliable.
Important Note: All the Calculators listed in this site are for educational purpose only and we do not guarentee the accuracy of results. Please do consult with other sources as well.