Total Blocking Time (TBT) Test
The Total Blocking Time (TBT) Test measures how long the main thread was blocked by long JavaScript tasks between first paint and full interactivity.
- Results in seconds
- Pass / fail + fix guidance
- No account required
The Total Blocking Time (TBT) Test measures how long the main thread was blocked by long JavaScript tasks between first paint and full interactivity. TBT is the lab metric Lighthouse uses to estimate responsiveness, and it is the lab proxy for the field Core Web Vital Interaction to Next Paint (INP). A high TBT means the page looks loaded but taps and clicks feel sluggish. Long blocking almost always comes from heavy JavaScript on the main thread.
What This Tool Checks
- Total Blocking Time (TBT) lab measurement
- Long tasks (over 50 ms) on the main thread
- Third-party JavaScript impact on responsiveness
- JavaScript execution time attributed per script
- Hydration cost on JavaScript-rendered pages
Why It Matters for SEO
TBT is the lab signal behind INP, the Core Web Vital Google ranks against. In Lighthouse, TBT under 200 ms is good, 200-600 ms needs improvement, and over 600 ms is poor. High TBT comes from JavaScript hogging the main thread; common causes are heavy hydration on SSR frameworks, large component trees, and third-party tag managers. Fixing TBT usually improves INP and the overall page-experience signal.
How to Fix It
Audit the long tasks in this report. Break them up by yielding to the main thread between expensive operations. Defer or remove third-party scripts that run during load. Use code splitting so only the JavaScript needed for the current page is loaded. Move expensive work off the main thread with web workers.
How It Works
We launch the page in headless Chrome, capture the Total Blocking Time between First Contentful Paint and interactivity, and walk the JavaScript execution timeline to attribute every long task (>50 ms) to its source script. The report sorts opportunities by blocking time so you target the biggest wins first.
Common Mistakes to Avoid
- Heavy hydration on every page even when no interaction is needed
- Third-party tag managers running synchronously during load
- Long synchronous tasks blocking the main thread
- Shipping the whole bundle instead of code-splitting per route
- Large first-party JavaScript with no yielding to the main thread
Quick Checklist
- Total Blocking Time under 200 ms
- No main-thread tasks longer than 50 ms
- Third-party scripts deferred
- JavaScript code-split per route
- Hydration cost minimized on SSR pages
Put your whole site on autopilot — SEO and AI search
PositionMySite monitors every signal on this page across your entire website 24/7 — plus keyword rankings, competitor moves and AI-search readiness (llms.txt, schema, ChatGPT & Gemini visibility). When something breaks, you know before Google does.
Every feature unlocked · No commitment · Cancel anytimeFrequently Asked Questions
TBT is the total time between First Contentful Paint and interactivity during which the main thread was blocked long enough (tasks over 50 ms) to prevent the page from responding to input.
In Lighthouse, under 200 ms is "Good", 200-600 ms is "Needs Improvement", and over 600 ms is "Poor". Lower is always better for responsiveness.
TBT is the lab proxy for INP, the field Core Web Vital. You cannot measure INP in a lab without real user interactions, so Lighthouse uses TBT to estimate how responsive the page will feel. Improving TBT almost always improves INP.
Long synchronous tasks on the main thread — usually heavy JavaScript during hydration, third-party scripts loading during page load, or large first-party bundles that never yield.
Indirectly. TBT is not a ranking factor itself, but it drives INP, which is one of three Core Web Vitals Google uses in its page-experience signal. Reducing TBT improves INP and helps rankings.