Fixing High Total Blocking Time (TBT)

How Total Blocking Time is calculated

A browser does most of its work on a single main thread: parsing HTML, running JavaScript, working out styles and layout, and responding to taps and clicks. While a piece of JavaScript is running, anything else has to wait. Any continuous chunk of main-thread work that lasts longer than 50 milliseconds is called a long task.

TBT only counts the part of each long task beyond the first 50 ms, because a delay under 50 ms is too short for a person to notice. It adds those excess amounts together for the period between First Contentful Paint and the point where the main thread becomes reliably quiet.

This is why one 400 ms task is much worse than eight 50 ms tasks doing the same work: the single long task contributes 350 ms of blocking time, the eight short ones contribute nothing. Most TBT work is therefore about doing less and doing it in smaller pieces.

In the Lighthouse report for mobile, TBT of 200 ms or less is shown in green, 200 to 600 ms in amber and over 600 ms in red. Those bands are Lighthouse's own scoring, not a Google ranking threshold.

Why TBT matters when it is not a Core Web Vital

Lighthouse cannot measure Interaction to Next Paint because nobody taps or clicks during a lab test. TBT is its substitute. A page with lots of long tasks during load is likely to respond slowly when real visitors try to open the menu, tap "add to basket" or type in a search box while scripts are still running.

The link is not exact. TBT only looks at the loading period, and INP covers interactions throughout the whole visit, including slow event handlers long after load. A page can have low TBT and still fail INP because one button runs an expensive handler, and a page can have high TBT but pass INP if visitors rarely interact during the first few seconds. Use TBT to spot heavy start-up JavaScript, and use field INP data to decide whether real visitors are affected. The INP guide covers interaction handlers in depth.

TBT also carries the largest weight of any metric in the Lighthouse performance score in recent versions, so reducing it is usually the quickest way to lift that score. Remember that the score is a lab summary; the Core Web Vitals pass or fail comes from real users.

Finding the scripts behind the blocking time

Start with the lab section of the Core Web Vitals checker or a Lighthouse report. The diagnostics that list long main-thread tasks, JavaScript execution time per script and the impact of third-party code are your first map. Note the scripts that appear near the top of each list.

Recording a trace

1. Open Chrome DevTools, go to the Performance panel and set CPU throttling to a 4x or 6x slowdown to imitate a mid-range phone.
2. Click the reload-and-record button. When it finishes, look along the Main track for grey task bars marked with a red corner. Each one is a long task.
3. Click a long task and open the Bottom-Up tab, grouped by domain or by URL. This shows which files and which functions used the time.
4. Look at the Summary for each task: time split between scripting, rendering and painting. Heavy "Recalculate style" or "Layout" inside a task suggests a script that is changing the page in a loop.

Grouping by owner

Sort what you find into three groups: third-party tags (analytics, advertising, chat, reviews, heatmaps, consent tools), your own framework and application code, and platform or plugin code you did not write. Each group has a different fix, and on many small-business sites the third-party group is the largest by a wide margin.

// Paste into the console, then reload, to log long tasks as they happen
new PerformanceObserver((list) => {
  for (const task of list.getEntries()) {
    console.log('long task', Math.round(task.duration), 'ms at', Math.round(task.startTime));
  }
}).observe({ type: 'longtask', buffered: true });

The newer Long Animation Frames API gives richer detail, including the script source for each slow frame, and is what the web-vitals library uses for INP attribution in the field.

Third-party tags

Every tag you add runs on the same main thread as your site. Tag managers make it easy to add tags and hard to remember why each one is there.

• Audit the container. Open your tag manager and list every tag with its owner and purpose. Tags for campaigns that have ended, tools nobody logs into and duplicate analytics are common.
• Fire after consent. Under UK GDPR and PECR, non-essential cookies and similar tracking generally need consent before they are set, so advertising and analytics tags that set them should not run until the visitor agrees. This is not legal advice, but it is also a performance win, because those tags do not run for visitors who decline.
• Load on interaction. Chat widgets, video players and review carousels can be replaced by a lightweight placeholder that loads the real script when the visitor clicks, hovers or scrolls near it.
• Delay until idle. Tags that must run for everyone but are not urgent can wait until after the load event.

// Load a chat widget only when the visitor asks for it
document.querySelector('#chat-button').addEventListener('click', () => {
  const s = document.createElement('script');
  s.src = 'https://chat.example.com/widget.js';
  s.async = true;
  document.head.appendChild(s);
}, { once: true });

The third-party tags guide goes further into facades, consent-based loading and moving tags to server-side tagging.

Your own JavaScript

Ship less on first load

• Code splitting. Use dynamic import() so code for a feature only downloads when that feature is used, and split bundles by route so the home page does not carry the checkout.
• Remove unused libraries. A bundle analyser shows what is inside each file. Large date libraries, whole icon sets and utility libraries imported in full are frequent finds.
• Drop old polyfills. If your build targets browsers that are years out of date, it may be adding code modern browsers do not need.
• Reduce hydration. Frameworks that render on the server and then "hydrate" in the browser run a lot of JavaScript at start-up. Hydrate only interactive parts, use server components or islands where your framework supports them, and keep static content static.

Break up what remains

Work that genuinely has to happen during load can be split so the browser can respond between pieces. Yielding hands control back to the main thread briefly:

function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function initWidgets(widgets) {
  for (const widget of widgets) {
    widget.init();
    await yieldToMain();
  }
}

scheduler.yield() is not yet available in every browser, so feature-detect it and fall back to setTimeout as above. For heavy calculations that do not touch the page, such as parsing a large data file or filtering thousands of products, move the work into a Web Worker so it runs off the main thread altogether.

Platform notes

• WordPress. Each plugin can enqueue scripts on every page. Use a plugin that shows which scripts load where, and stop plugins loading scripts on pages that do not use them. "Delay JavaScript until interaction" features in optimisation plugins can cut lab TBT sharply, but test carefully, because delayed scripts can make the first real interaction slower. See Core Web Vitals in WordPress.
• Shopify. Installed apps inject scripts through app embeds and theme code. Disable app embeds you do not use and check for leftover code from removed apps. See Core Web Vitals in Shopify.
• React, Next.js and similar. Hydration and large client bundles are the usual cause. See Core Web Vitals in Next.js and Nuxt.

The fix, step by step

Stopping blocking time creeping back

• A tag approval rule. Nothing goes into the tag manager or theme without an owner, a purpose, a loading rule (after consent, on interaction or after load) and a review date.
• A JavaScript budget. Set a limit for script size per template and have your build fail or warn when a change exceeds it.
• Lighthouse in the pipeline. Run Lighthouse against key templates on each deployment and alert when median TBT rises above an agreed limit.
• Field INP monitoring. Keep real-user monitoring running with attribution, so you see which scripts slow real interactions, not just the lab load.

For a closer look at splitting work up, see the long tasks guide.