Total Blocking Time (TBT) Optimization Turnkey

Total Blocking Time (TBT) Optimization Turnkey

High Total Blocking Time is the main cause of poor INP (Interaction to Next Paint) and, consequently, conversion loss. We see this on every second audit: sites with React and Next.js often show TBT over 500 ms, directly degrading user experience. Our team, with 5+ years of experience in Core Web Vitals optimization, knows how to bring TBT down to the green zone — under 200 ms on desktop and 300 ms on mobile with CPU throttling 4×.

TBT consists of Long Tasks, each lasting more than 50 ms. If three tasks of 80 ms execute, blocking totals 90 ms. Each such millisecond delays the next frame render, increasing time to full interactivity. Reducing TBT by 100 ms can improve INP by 30–50%, as confirmed by field measurements.

We offer comprehensive TBT optimization turnkey: from diagnostics to monitoring implementation. Request an audit — we will prepare a plan with timelines and impact estimate at no charge.

How to Diagnose the Causes of High TBT?

The first step is finding Long Tasks. Chrome DevTools, Performance tab: record page load, look for red bars above the main thread. Programmatically, use the Long Task API:

const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { console.log({ name: entry.name, duration: entry.duration, startTime: entry.startTime, attribution: entry.attribution, }); } }); observer.observe({ type: 'longtask', buffered: true }); // Data can be sent to analytics via fetch with keepalive 

attribution shows in which frame or script the task occurred. This is the first step toward targeted optimization.

Cause #1: Heavy JavaScript at Startup

The most common cause of high TBT is a large JS bundle that is parsed and executed synchronously on load. Each megabyte of JS requires ~1 second of parsing on an average mobile device. Solution: code splitting + lazy loading:

const HeavyChart = lazy(() => import('./HeavyChart')); const DataTable = lazy(() => import('./DataTable')); function Dashboard() { const [showChart, setShowChart] = useState(false); return ( <div> <button onClick={() => setShowChart(true)}>Show Chart</button> {showChart && ( <Suspense fallback={<Skeleton />}> <HeavyChart /> </Suspense> )} </div> ); } 

For routes: React.lazy + react-router. Code splitting reduces TBT by 2–3 times, as the initial chunk becomes under 150 kB gzip.

Cause #2: Synchronous Third-Party Scripts

Google Tag Manager, chats, ad network pixels — each third-party script can create Long Tasks. Diagnostics in Chrome DevTools: Performance → Bottom-up → group by domain. Solutions:

<!-- Use async or defer: --> <script src="https://widget.example.com/chat.js" async></script> <!-- Or deferred loading after interaction: --> <script> function loadChat() { const s = document.createElement('script'); s.src = 'https://widget.example.com/chat.js'; document.head.appendChild(s); } ['click', 'scroll', 'keydown'].forEach(event => { window.addEventListener(event, loadChat, { once: true }); }); </script> 

For GTM: delayed trigger "DOM Ready" instead of "Page View" for non-critical tags.

Cause #3: Heavy Computations on the Main Thread

Sorting large arrays, complex DOM manipulations — all block the main thread. Web Worker offloads computations to a separate thread:

// worker.js self.onmessage = function(e) { const { data, operation } = e.data; let result; switch (operation) { case 'sort': result = heavySort(data); break; case 'filter': result = complexFilter(data); break; } self.postMessage(result); }; // main.js const worker = new Worker('/worker.js'); worker.postMessage({ data: largeArray, operation: 'sort' }); worker.onmessage = (e) => setTableData(e.data); 

To break up long synchronous cycles, use scheduler.yield() (Chrome 94+) or polyfill via setTimeout.

Cause #4: Heavy Hydration in SSR/SSG

Next.js, Nuxt, Gatsby — during hydration, the framework rewalks the entire DOM. Solutions: Partial hydration (Islands architecture), Progressive hydration, React 18 startTransition:

import { startTransition } from 'react'; function SearchResults() { const [results, setResults] = useState([]); function handleSearch(newQuery) { startTransition(() => setResults(fetchResults(newQuery))); } } 

Measuring TBT in the Field

TBT cannot be measured directly in the browser, but INP is its production proxy. We use web-vitals:

npm install web-vitals 

import { onINP } from 'web-vitals'; function sendToAnalytics(metric) { navigator.sendBeacon('/api/vitals', JSON.stringify({ name: metric.name, value: metric.value, rating: metric.rating, id: metric.id, url: location.href })); } onINP(sendToAnalytics); 

Set alerts when INP exceeds the green zone.

Comparison of TBT Optimization Methods

What's Included in the Work

• Diagnosis of TBT and Long Tasks with a report on blocking sources
• Optimization plan with specific steps and impact estimates
• Implementation of code splitting, lazy loading, Web Workers
• Optimization of third-party scripts and hydration
• Setup of field INP monitoring with alerts
• Handover of documentation and access to tools
• Free consultation and 2 weeks of support after delivery

Timelines and Pricing

Diagnostics and planning: 1–2 business days. Code splitting + lazy loading for a typical React app: 3–5 business days. Full cycle: diagnostics, optimization, production INP monitoring setup — 1.5–3 weeks depending on application complexity. Pricing is calculated individually after audit.

Contact us — we will assess your project and prepare a TBT optimization plan with guaranteed results.