A website can appear visually complete while still feeling frustratingly slow. A visitor may see the headline, navigation, and images, yet clicking a button or opening a menu produces no immediate response. This disconnect often happens because the browser is busy processing work behind the scenes and cannot respond to the user at that moment.
Total Blocking Time, commonly shortened to TBT, helps identify this problem during website performance testing. It measures how long the browser’s main thread is blocked by lengthy tasks after the first visible content appears. A high Total Blocking Time suggests that users may experience delayed clicks, frozen controls, or an interface that feels less responsive than it looks.
TBT remains an important Lighthouse lab metric, although it is not one of Google’s current Core Web Vitals. Interaction to Next Paint, or INP, is now the Core Web Vital used to assess real-world responsiveness. TBT is still valuable because it can reveal main-thread congestion during page loading and help developers locate potential responsiveness problems before they reach users.
Improving TBT is therefore not about chasing a perfect PageSpeed score. It is about making a website easier and more pleasant to use, particularly for visitors on slower mobile devices. By understanding long tasks, JavaScript execution, third-party scripts, code splitting, and browser responsiveness, businesses can create faster digital experiences that support engagement, conversions, and customer trust.
What Is Total Blocking Time in Simple Terms?
Total Blocking Time measures the combined amount of time during page loading when the browser cannot respond promptly to user input. It focuses on the period between First Contentful Paint and Time to Interactive in a standard Lighthouse test. During this window, the page may be visible, but the browser may still be occupied with JavaScript or other main-thread work.
The main thread handles many of the activities required to display and operate a webpage. It processes JavaScript, updates page layouts, performs rendering work, manages certain browser operations, and responds to user interactions. When one task occupies this thread for too long, other work must wait, including the work needed to respond to a click, tap, or keyboard input.
Lighthouse considers a main-thread task to be a long task when it runs for more than 50 milliseconds. The entire task is not added to the TBT result. Only the portion exceeding the first 50 milliseconds is treated as blocking time because the initial 50-millisecond allowance represents the maximum task length before responsiveness is likely to become noticeably affected.
For example, a task lasting 130 milliseconds contributes 80 milliseconds to Total Blocking Time. A separate task lasting 70 milliseconds contributes another 20 milliseconds. Together, they add 100 milliseconds to the page’s TBT. This calculation helps teams understand not only whether long tasks exist, but also how severely those tasks may block the browser during loading.
How Is Total Blocking Time Calculated?
Total Blocking Time is calculated by identifying every long task that runs during the measured loading period. For each task longer than 50 milliseconds, the first 50 milliseconds are removed from the calculation. The remaining duration is counted as blocking time, and the blocking portions of all qualifying tasks are added together to produce the final TBT value.
The basic calculation can be expressed as: blocking time equals task duration minus 50 milliseconds. A 60-millisecond task contributes 10 milliseconds, while a 250-millisecond task contributes 200 milliseconds. Tasks lasting exactly 50 milliseconds or less contribute nothing, even though many short tasks can still create meaningful processing work when they occur repeatedly.
Imagine that Lighthouse records five tasks lasting 40, 90, 160, 45, and 220 milliseconds. The 40- and 45-millisecond tasks add no blocking time. The remaining tasks contribute 40, 110, and 170 milliseconds respectively, giving the page a Total Blocking Time of 320 milliseconds. This result indicates a noticeable amount of main-thread congestion during the loading experience.
TBT does not measure every moment across a visitor’s complete session. In a typical Lighthouse page-load audit, it focuses on the loading period between First Contentful Paint and Time to Interactive. Other tracing tools may use a different endpoint, which is one reason results should always be interpreted according to the tool, test conditions, and measurement window being used.
What Is a Good Total Blocking Time Score?
For Lighthouse mobile testing, a Total Blocking Time between 0 and 200 milliseconds is classified as fast and displayed in green. A result between 200 and 600 milliseconds is considered moderate, while a result above 600 milliseconds is classified as slow. Aiming below 200 milliseconds is therefore a practical target for a responsive mobile loading experience.
Desktop thresholds are stricter because desktop devices generally have greater processing power. Lighthouse classifies a desktop TBT of 0 to 150 milliseconds as fast, 150 to 350 milliseconds as moderate, and anything above 350 milliseconds as slow. Mobile and desktop reports should therefore be reviewed separately rather than assuming that one result accurately represents every visitor.
A single test should not be treated as a permanent judgment of website quality. Lab results can vary because of test location, device emulation, CPU throttling, network conditions, cached resources, server response, and changes in page content. PageSpeed Insights also notes that laboratory data represents a controlled simulation, while field data reflects real experiences across different devices and connections.
The best TBT target also depends on the starting point and the type of website. Reducing a result from 1,200 milliseconds to 400 milliseconds can create a meaningful improvement even though the score remains outside the green range. Teams should prioritize the longest tasks and most important user journeys instead of delaying useful improvements until a perfect number becomes achievable.
TBT, INP, FCP and TTI: What Is the Difference?
First Contentful Paint, or FCP, marks the point when the browser first renders visible content from the page. That content may be text, an image, an SVG element, or another meaningful visual component. FCP answers an early loading question: when does the visitor first receive visible confirmation that the requested page is beginning to appear?
Time to Interactive, or TTI, estimates when a page becomes reliably capable of responding to user input. TBT traditionally examines the long tasks that occur between FCP and TTI, making it more detailed than a single interactivity timestamp. Google’s current performance guidance generally recommends newer metrics such as TBT and INP instead of relying heavily on TTI alone.
Interaction to Next Paint measures the latency of user interactions throughout a real visit. It observes how quickly the page presents visual feedback after clicks, taps, and keyboard activity. INP officially replaced First Input Delay as a Core Web Vital in March 2024 and is now reported alongside Largest Contentful Paint and Cumulative Layout Shift.
TBT and INP are related, but they are not interchangeable. TBT is primarily a controlled lab measurement of blocking work during page loading, while INP is a field metric based on actual user interactions. A low TBT often correlates with better INP, but TBT may flag tasks that users never encounter or miss delays that happen during later interactions.
Why Does Total Blocking Time Matter?
A high TBT can make an otherwise attractive website feel unreliable. When the main thread is occupied, navigation buttons may not open, form fields may respond slowly, and product filters may appear broken. Visitors do not know that JavaScript is being parsed or executed; they simply notice that the website failed to respond when they expected it to.
These delays are especially noticeable on mobile devices with limited processing power. JavaScript that executes quickly on a developer’s high-performance computer may take considerably longer on an older smartphone. Main-thread performance can vary significantly according to device capability, making efficient code important for serving a broad and realistic audience.
TBT also has a substantial influence on the Lighthouse performance score. Chrome’s current Lighthouse scoring documentation assigns Total Blocking Time a weight of 30 percent, making it one of the largest contributors to the overall performance category. Reducing TBT can therefore improve both the responsiveness of the page and its Lighthouse score.
However, TBT is not itself a Core Web Vital or a standalone Google Search ranking signal. Google recommends evaluating page experience across multiple areas rather than optimizing one score in isolation. Core Web Vitals are used by Google’s ranking systems, but good scores do not guarantee high rankings because relevance, content quality, and other signals also matter.
What Causes a High Total Blocking Time?
Excessive JavaScript is one of the most common causes of high Total Blocking Time. The browser may need to download, parse, compile, and execute large script bundles before the interface becomes dependable. Even code that is not immediately needed can consume processing time if it is included in the initial bundle and executed during page loading.
Long-running JavaScript functions can create another major bottleneck. Complex calculations, large loops, inefficient event handlers, heavy data processing, and repeated DOM operations may monopolize the main thread. Because JavaScript tasks normally run to completion, the browser cannot simply pause a lengthy function whenever a user attempts to interact with the page.
Third-party scripts may also increase TBT. Advertising platforms, analytics tags, social widgets, chat tools, consent managers, testing software, video players, and personalization services can all add processing work. Scripts operating inside third-party frames may still generate long tasks and block the main thread, even when the website’s own application code is well optimized.
Large or complicated page structures can make JavaScript work more expensive. Broad DOM queries, repeated layout calculations, excessive component hydration, and unnecessary rendering updates may increase processing time. Chrome’s Lighthouse guidance notes that inefficient JavaScript statements can worsen TBT, although unnecessary JavaScript loading and execution usually present the larger optimization opportunity.
How to Measure Total Blocking Time Correctly
PageSpeed Insights is often the easiest place to begin. Enter a page URL, run the report, and review the laboratory metrics in both mobile and desktop mode. PageSpeed Insights uses Lighthouse for lab testing and separately displays real-user information from the Chrome User Experience Report when enough field data is available.
TBT appears in the laboratory section because it is primarily a lab metric. It will not appear as part of the Core Web Vitals field assessment, which currently evaluates LCP, INP, and CLS. This distinction prevents a common misunderstanding: the TBT result describes a simulated load, while the field section summarizes real-user experiences collected over a rolling 28-day period.
Chrome DevTools provides deeper diagnostic information. Record a page load in the Performance panel and inspect the main-thread timeline for long tasks, typically marked with visual warnings. Developers can then examine call stacks, script activity, rendering work, and task durations to locate the functions or third-party resources consuming the most main-thread time.
WebPageTest can add further context by testing from different devices and locations. For repeatable monitoring, teams can also use Lighthouse in development workflows or automated performance checks. Whatever tool is chosen, tests should be repeated under comparable conditions, because one isolated run may be affected by temporary network, server, or testing-environment variation.
How to Reduce TBT by Optimizing JavaScript
Begin by reducing the amount of JavaScript delivered during the initial page load. Remove unused libraries, eliminate obsolete plugins, review package dependencies, and avoid shipping features that are not required on the current page. A smaller JavaScript payload requires less downloading, parsing, compilation, and execution, creating more opportunities for the browser to remain responsive.
Code splitting allows developers to divide a large bundle into smaller files that can be loaded when needed. Route-level splitting, component-level splitting, and dynamic imports help prevent users from downloading and executing code for features they may never use. This approach can reduce initial JavaScript execution time without requiring valuable functionality to be removed from the website.
Scripts should also be loaded according to their importance. The defer and async attributes can prevent suitable scripts from blocking HTML parsing, while nonessential functionality can be delayed until after critical content is available. Developers must still test execution order carefully because delaying a dependent script without understanding its relationships may create errors or inconsistent interface behavior.
Tree shaking, minification, modern browser builds, and efficient imports can further reduce processing overhead. However, compression alone does not solve every TBT problem. A minified script may download quickly while still requiring substantial execution time. Teams should examine both network transfer size and CPU activity instead of assuming that a small file automatically produces a responsive page.
Break Up Long Tasks and Free the Main Thread
Long tasks should be divided into smaller units whenever the work does not need to run as one uninterrupted operation. Breaking a large function into several shorter tasks gives the browser opportunities to process pending interactions, update the screen, and complete higher-priority work. This can improve both Total Blocking Time and general input responsiveness.
The scheduler.yield() API provides a modern method for deliberately yielding control to the main thread. When execution reaches await scheduler.yield(), the current function pauses and its remaining work continues in a new task. This gives the browser an opportunity to respond to urgent activity without abandoning the continuation of the original operation.
Browser support should be considered before relying on scheduler.yield() alone. Current web.dev guidance recommends feature detection and a fallback, such as a promise wrapped around setTimeout, for browsers where the API is unavailable. The fallback does not provide the same prioritized continuation, but it can still prevent one large task from monopolizing the main thread.
Computationally expensive operations may be suitable for a Web Worker. Workers run JavaScript away from the browser’s main thread and can handle tasks such as data transformation, complex calculations, or large-scale processing. Communication overhead and implementation complexity must be considered, but moving appropriate work off the main thread can preserve interface responsiveness.
Reduce the Impact of Third-Party Code
Every third-party script should have a clear business purpose. Teams should audit analytics tools, advertising tags, social integrations, customer-support widgets, personalization services, and testing platforms to determine whether each one is actively used. Removing an unnecessary script can improve performance, reduce security exposure, simplify maintenance, and limit the amount of customer data shared externally.
Noncritical third-party tools should not automatically compete with essential page functionality. A chat widget, heatmap, or marketing tag may be delayed until the primary content becomes usable or until the visitor performs a relevant action. Conditional loading allows the website to preserve business functionality without forcing every user to process every integration immediately.
Tag managers also require careful governance. They simplify deployment, but they can allow multiple teams to add scripts without evaluating their combined performance cost. A documented approval process, regular tag audit, ownership record, and performance budget can prevent a lightweight container from gradually becoming a major source of JavaScript execution and main-thread blocking.
Lighthouse can identify third-party resources that consume significant main-thread time, but removal should not be the only response. Some integrations are commercially necessary. In those cases, teams can test lighter configurations, remove unused modules, reduce event frequency, load scripts conditionally, or work with the provider to identify a more efficient implementation.
Improve TBT Without Damaging Website Functionality
Performance optimization should begin with measurement rather than guesswork. Removing code or delaying scripts without understanding their purpose can break checkout processes, analytics attribution, consent management, accessibility features, or account functionality. The safest approach is to identify the largest long tasks, understand their business role, and test each change against realistic user journeys.
Teams should prioritize pages according to traffic, revenue, and customer importance. A moderate TBT problem on a high-volume product page may deserve attention before a severe issue on a rarely visited archive. Login, search, checkout, lead-generation forms, booking flows, and account dashboards are useful starting points because responsiveness directly affects task completion.
Testing should include more than the latest flagship smartphone. Slower processors reveal blocking problems that powerful development machines can hide. Mobile throttling, real-device testing, browser coverage, keyboard navigation, and slower network conditions help teams understand how the website behaves for users outside an ideal office environment.
Performance improvements should also be reviewed for visual and functional regressions. After changing JavaScript loading or task scheduling, confirm that menus open correctly, forms validate, tracking events fire, consent settings work, and dynamic content appears as expected. A lower TBT is valuable only when the website continues to serve its users accurately and dependably.
Make TBT Optimization Part of Ongoing Website Maintenance
Total Blocking Time can increase again after an initial optimization project. New marketing tools, design components, personalization features, plugins, and application updates may gradually add more JavaScript. Performance should therefore be treated as an ongoing product requirement rather than a one-time technical cleanup performed shortly before a redesign or launch.
A performance budget can establish practical limits for JavaScript size, main-thread work, long-task duration, and key Lighthouse metrics. Automated checks can warn a development team when a change exceeds agreed thresholds. These safeguards make performance visible during development, when resolving a problem is usually easier than after the code has reached production.
Lab tests should be combined with field data. TBT helps developers diagnose loading problems under controlled conditions, while INP indicates how real users experience responsiveness throughout their visits. PageSpeed Insights, CrUX, Search Console, real-user monitoring, and application analytics can provide complementary perspectives rather than competing versions of the truth.
Teams should track trends instead of reacting to every small fluctuation. A single report may change because of environmental variation, but a steady increase across repeated tests is more meaningful. Monitoring representative page templates and critical journeys makes it easier to detect performance regressions before they affect a large proportion of visitors.
Improve TBT for People, Not Just Performance Scores
Total Blocking Time turns an invisible technical problem into a measurable signal. It helps explain why a page can look ready while still failing to respond promptly. By locating long tasks and excessive JavaScript execution, teams can reduce the period in which users are left clicking, tapping, or typing without visible feedback.
A good TBT result is useful, but it should remain part of a broader performance strategy. Loading speed, visual stability, interaction responsiveness, accessibility, content usefulness, mobile usability, and reliable functionality all contribute to the quality of a digital experience. Improving one metric while ignoring the wider journey rarely delivers the strongest result.
The most effective TBT improvements usually come from disciplined decisions: ship less JavaScript, load code only when it is needed, control third-party tools, divide lengthy work, and move appropriate processing away from the main thread. These improvements create a browser that has more time to respond to the person using it.
Ultimately, website performance is not simply a technical score displayed inside Lighthouse. It is the visitor’s experience of whether a page feels clear, immediate, and dependable. When TBT optimization is guided by real user needs, it supports a faster website, smoother interactions, stronger engagement, and a digital experience people are more likely to trust.
Is Total Blocking Time a Core Web Vital?
No. TBT is a Lighthouse lab metric used to diagnose main-thread blocking during page loading. INP is the current Core Web Vital that measures real-user interaction responsiveness.
What is a good Total Blocking Time?
For mobile Lighthouse tests, a TBT of 200 milliseconds or less is considered fast. Desktop testing uses a stricter fast threshold of 150 milliseconds or less.
Does JavaScript increase Total Blocking Time?
JavaScript can increase TBT when loading, parsing, or execution creates tasks longer than 50 milliseconds. Large bundles, inefficient functions, and unnecessary third-party scripts are common causes.
How can I check my website’s TBT?
Run the page through PageSpeed Insights or a Lighthouse performance audit. Use Chrome DevTools’ Performance panel when you need to identify the scripts and functions responsible for long tasks.
Will reducing TBT improve SEO rankings?
TBT is not a direct Core Web Vital, so improving it does not guarantee higher rankings. However, lower main-thread blocking may support better responsiveness and contribute to a stronger overall page experience.
