You click “Contact” on a supplier’s site and the menu takes half a second to respond. It is not the network: the browser is running JavaScript on the main thread. Total Blocking Time (TBT) sums how long those long tasks last between FCP and Time to Interactive. In 2026 it remains one of the lab metrics that best matches a business website that feels slow even when LCP looks fine.
This article explains what TBT measures, Lighthouse thresholds, how it relates to INP, third-party scripts, and unoptimized JavaScript, and which changes usually cut blocking without dismantling your marketing stack.
What TBT is and what it measures
TBT is a lab metric (Lighthouse, simulated PageSpeed). It adds the duration of every long task on the main thread above 50 ms between First Contentful Paint and Time to Interactive, minus a 50 ms allowance per task.
- Each main-thread task > 50 ms contributes (duration − 50 ms) to TBT.
- It does not replace INP in field data, but it predicts interactivity pain.
- High TBT often means sluggish menus, delayed form validation, or janky scrolling.
- JS parse and execution, costly reflows, and some synchronous work feed blocking time.
The web.dev guide on Total Blocking Time documents the calculation and its weight in Lighthouse performance scoring.
Reference thresholds in 2026
Lighthouse still uses these bands for TBT:
- Good: 200 ms or less.
- Needs improvement: between 200 ms and 600 ms.
- Poor: above 600 ms.
Pages with embedded CRM, maps, or analytics tags often show yellow TBT on desktop and red on simulated mobile. Prioritize conversion templates: home, services, contact, and checkout if you run e-commerce.
TBT vs INP, FCP, and LCP
Core Web Vitals in the field measure real experience; TBT helps explain why the main thread does not respond. A strong LCP does not guarantee smooth menus if three JS bundles fight at load. Fast FCP with high TBT feels like “I can see the site but cannot use it yet.”
INP penalizes slow clicks and taps for real users; improving lab TBT is usually step one before validating INP in CrUX. Work both metrics on the same critical URLs.
Common causes on business websites
- Oversized JavaScript bundles without route-based splitting or on-demand loading.
- Marketing and chat tags that run synchronous code at startup.
- Duplicate libraries (two jQuery versions, sliders plus frameworks together).
- Main-thread work that belongs in Web Workers or on the server.
- Animations and scroll listeners without throttling that force layout every frame.
- CMS plugins injecting scripts on every page even when unused.
Excess third-party scripts is the top cause on marketing-heavy sites without periodic tag reviews.
How to measure TBT
- PageSpeed Insights / Lighthouse: “Total Blocking Time” and “Main-thread work” breakdown.
- Chrome DevTools → Performance: record load and spot red bars for tasks > 50 ms.
- WebPageTest: compare filmstrip and blocking time across devices.
- Coverage in DevTools: find JS downloaded but not executed on that view.
Test with cold cache and mobile throttling. Log TBT before and after each change; shaving 150 ms on contact can show up in form completion.
Actions that usually lower TBT
Less JavaScript on the critical path
Defer what is not needed for the first scroll: pop-ups, maps, players, and social widgets. Apply the same mindset as lazy loading, but for scripts: load on interaction or when entering the viewport.
Code splitting and routes
Split the home bundle from store or client-area code. Do not import a full charting library on text-only pages. Minification shrinks bytes; splitting shrinks executed work per view.
Third-party audit
Inventory tags in GTM or templates. Remove duplicates, fix load order, and use consent mode where required after your cookie banner. Every script that adds a 40 ms long task hurts more on mobile.
Less work in the browser
Heavy filters, sorting, and validation can move to the server or build step. Less JSON processed in the browser means less blocking and better INP.
Break up long tasks
Chunk expensive loops with requestIdleCallback or cooperative yields. Prioritize menu click response before decorative animations on first load.
Mistakes that keep TBT high
- Optimizing only images when Lighthouse flags “Reduce JavaScript execution time.”
- Adding another “light” plugin without measuring long-task impact.
- Loading the same tag in staging and production with different containers, duplicating execution after deploys.
- Confusing TBT with TTFB: faster servers do not unblock the main thread if JS stays heavy.
Checklist before you ship a fix
- Did mobile Lighthouse TBT drop on home, services, and contact?
- Are tasks > 50 ms fewer or shorter in Performance?
- Did INP or menu/form feel improve on the same URL?
- Does marketing still have the tags it needs after pruning?
Conclusion
TBT answers a direct question: “How long is the browser busy with JavaScript before it can respond smoothly?” On a business website, cutting it reduces friction on forms, menus, and CTAs and sets you up for strong INP in the field. Measure on your highest-converting URLs, attack long tasks, and validate impact alongside your other performance metrics.
If you want a prioritized plan for JavaScript, third parties, and Core Web Vitals tailored to your stack, AATSOFT audits templates, origin, and critical scripts and proposes changes with measurable conversion impact.
