View contents
TBT (Total Blocking Time): Understanding Your Page’s Interactivity Delay
Introduction
Total Blocking Time (TBT) is a critical performance metric that measures how long your page’s main thread is blocked during page load. When the main thread is blocked, users cannot interact with your page—clicks don’t register, typing doesn’t appear, and the page feels “frozen.”
TBT quantifies this frustrating experience by measuring the total time between First Contentful Paint (FCP) and Time to Interactive (TTI) during which the main thread was blocked long enough to prevent input responsiveness.
What is TBT?
TBT measures the total amount of blocking time caused by Long Tasks during the page load process. Here’s how it works:
Understanding Long Tasks
A Long Task is any task that runs on the browser’s main thread for more than 50 milliseconds. During a Long Task, the browser cannot respond to user input.
Task Duration: 70ms
├─────────────────────────────────────┤
│ First 50ms │ Blocking: 20ms │
│ (acceptable) │ (counted in TBT)│
└─────────────────┴───────────────────┘
TBT Calculation
The blocking time of each Long Task is the portion that exceeds 50ms:
Long Task 1: 250ms → Blocking time = 200ms (250 - 50)
Long Task 2: 90ms → Blocking time = 40ms (90 - 50)
Long Task 3: 35ms → Blocking time = 0ms (not a Long Task)
Long Task 4: 155ms → Blocking time = 105ms (155 - 50)
TBT = 200 + 40 + 0 + 105 = 345ms
TBT Thresholds
According to Chrome Developers documentation, TBT scores are categorized as:
✅ Good: < 200 milliseconds
⚠️ Needs Improvement: 200 - 600 milliseconds
❌ Poor: > 600 milliseconds
Goal: Aim for a TBT under 200ms to provide a responsive user experience.
Why is TBT Important for SEO?
TBT directly impacts how users perceive your website’s responsiveness and has several important implications:
Key benefits of good TBT:
- User experience: Low TBT means users can interact with your page without frustrating delays
- Lighthouse score: TBT contributes 30% to your overall Lighthouse performance score
- Correlates with INP: TBT in lab testing predicts real-world INP (Interaction to Next Paint) scores
- Mobile critical: Especially important on mobile devices with slower processors
- Conversion impact: Unresponsive pages lead to higher bounce rates and abandoned interactions
TBT vs INP
While INP (Interaction to Next Paint) is the Core Web Vital for responsiveness, TBT is its lab-based proxy:
| Metric | Type | Measures | Use Case |
|---|---|---|---|
| TBT | Lab metric | Blocking time during load | Development, Lighthouse audits |
| INP | Field metric | Actual interaction responsiveness | Real user monitoring |
Improving TBT typically improves INP, making TBT valuable for development optimization.
What Causes High TBT?
Several factors can cause high TBT:
1. Heavy JavaScript Execution
Large JavaScript bundles that execute synchronously block the main thread:
JavaScript Download → Parse → Execute (Long Tasks) → TBT Impact
↑
Heavy computation blocks the thread
2. Third-Party Scripts
Analytics, ads, and social widgets often add significant blocking time:
<!-- Each script can contribute Long Tasks -->
<script src="analytics.js"></script>
<script src="chat-widget.js"></script>
<script src="social-buttons.js"></script>
3. Inefficient JavaScript
Poorly optimized code that does too much work at once:
// ❌ One large task blocking the thread
function processAllData(items) {
items.forEach(item => heavyComputation(item));
}
// ✅ Breaking into smaller chunks
function processDataInChunks(items) {
requestIdleCallback(() => processNextChunk());
}
4. Render-Blocking Resources
CSS and JavaScript that prevent the page from becoming interactive:
<!-- Blocks rendering and adds to TBT -->
<script src="large-bundle.js"></script>
Basic Best Practices
1. Break Up Long Tasks
Split heavy JavaScript work into smaller chunks:
// Use requestIdleCallback or setTimeout
function doWork(tasks) {
if (tasks.length === 0) return;
const task = tasks.shift();
processTask(task);
setTimeout(() => doWork(tasks), 0);
}
2. Defer Non-Critical JavaScript
<!-- Load JavaScript without blocking -->
<script src="analytics.js" defer></script>
<script src="non-critical.js" async></script>
3. Remove Unused JavaScript
Audit your JavaScript bundles and remove code that isn’t needed:
- Use tree-shaking in your build process
- Analyze bundle size with tools like webpack-bundle-analyzer
- Remove unused dependencies
4. Optimize Third-Party Scripts
- Load third-party scripts after the main content
- Use resource hints like
dns-prefetchandpreconnect - Consider self-hosting critical third-party resources
Common Mistakes to Avoid
Mistake 1: Loading All JavaScript Upfront
Problem: Downloading and executing all JavaScript before the page is interactive.
Solution: Code-split your application and load only what’s needed initially.
Mistake 2: Synchronous Data Processing
Problem: Processing large datasets synchronously blocks the main thread.
Solution: Use Web Workers for heavy computation or break work into smaller tasks.
Mistake 3: Ignoring Third-Party Impact
Problem: Assuming third-party scripts don’t affect your metrics.
Solution: Audit third-party scripts with Lighthouse and consider lazy-loading them.
Measuring TBT
Using Chrome DevTools
- Open DevTools (F12)
- Go to the Performance panel
- Click Record and reload the page
- Look for Long Tasks (red triangles) in the timeline
Using Lighthouse
Run a Lighthouse audit to see your TBT score:
- In Chrome DevTools → Lighthouse tab
- Select “Performance” and run the audit
- TBT is displayed in the metrics section
Related Articles
Improve other aspects of your site’s performance:
- LCP Explained - Optimize your largest content element
- INP Explained - Understand real-world interactivity
- FCP Explained - Improve initial content paint
- Speed Index Explained - Measure visual progress
📚 Back to Performance SEO Hub - Explore all performance topics
References
- Chrome Developers - Total Blocking Time
- web.dev - Total Blocking Time (TBT)
- Chrome Developers - Lighthouse Performance Scoring
Try It Yourself
Want to measure your page’s TBT?
🔧 Download UXR SEO Analyzer (Free, 100% local analysis)
Disclaimer: The analyzers in this extension are reference guides based on official Chrome Developers and web.dev documentation. They do not represent absolute truths about how search engines evaluate your content—only search engines know their internal algorithms. Use these recommendations as a starting point to improve your site.
Last updated: December 14, 2025