Third-Party Scripts and Total Blocking Time: A Practical Before-and-After for SME Owners

Quick answer: what TBT tells you

Total Blocking Time (TBT) is a Lighthouse lab metric that adds up the blocking portion of long main-thread tasks between First Contentful Paint and Time to Interactive. A task becomes a “long task” once it runs for more than 50 milliseconds; only the time beyond that first 50 milliseconds contributes to TBT. Chrome’s Lighthouse TBT documentation currently colour-codes 0–200 ms as fast on mobile and 0–150 ms as fast on desktop. Treat those as Lighthouse scoring bands, not Google ranking thresholds.

Third-party JavaScript can raise TBT when analytics, chat, advertising, heatmaps, A/B testing, social widgets, consent tools or embedded media keep the browser’s main thread busy during page load. But a high TBT score does not prove that “third parties” are the problem. The expensive work may be first-party JavaScript, layout, rendering, or a vendor script that triggers additional work elsewhere.

TBT is not the same thing as Core Web Vitals or INP

The current Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). INP replaced First Input Delay (FID) as the responsiveness Core Web Vital in March 2024. INP measures how quickly a page responds to user interactions across the visit, while TBT is a controlled lab measurement focused on main-thread blocking during the load window. The two can be related, but they are not interchangeable. See web.dev’s current INP guidance.

This distinction matters when you verify a fix. PageSpeed Insights can show Lighthouse lab diagnostics alongside Chrome User Experience Report (CrUX) field data. A lower TBT in a repeatable lab test is useful evidence that you reduced load-time blocking. Real-user INP is the stronger check for whether responsiveness improved for actual visitors over time.

Google says its ranking systems use Core Web Vitals as part of page-experience signals, but good scores do not guarantee high rankings. There is no need to claim that TBT itself is a ranking factor or that third-party scripts directly reduce crawl efficiency. The safer SEO case is simpler: excessive main-thread work can make pages less responsive for users, and improving that experience is worthwhile. Google’s page-experience documentation explicitly warns against chasing perfect scores purely for SEO.

How to find which third-party script is actually blocking the page

Start with evidence, not with a blanket instruction to add defer to every script. Chrome’s current Performance tooling includes a Third parties insight, and the Performance panel can distinguish first- and third-party activity and show how much main-thread time each entity consumes.

1. Capture a repeatable baseline. Test the same URL, device mode and conditions more than once. Record TBT, the overall Lighthouse performance score, and any relevant LCP or INP data. One unusually fast or slow run is not enough to diagnose a cause.
2. Record a Performance trace. In Chrome DevTools, reload the page while recording. Look at the Main track for long tasks and use the first-party/third-party summary or Bottom-up view to see which domains and functions consume the most main-thread time.
3. Map each expensive script to a business purpose. Write down what it does, who owns it, where it loads, and whether it is needed before the page becomes usable. A tag manager may only be the delivery mechanism; the expensive work can come from individual tags inside it.
4. Test the suspected cause safely. In staging or a controlled test, temporarily block or disable one suspected vendor at a time and rerun the trace. If TBT falls materially and the long task disappears, you have stronger evidence that the script is part of the problem.
5. Check more than the homepage. Chat, forms, ecommerce widgets, review tools and advertising often load differently by template. Test representative page types rather than assuming one result describes the whole site.

A small file can still create expensive execution, and a large file is not automatically the biggest TBT problem. Network transfer size and CPU time are related but different costs. That is why the main-thread trace is more useful than judging scripts by kilobytes alone.

A before-and-after SME example: reduce work before you rearrange it

Consider a hypothetical small-business lead-generation site. Its homepage loads an analytics tag twice, starts a heatmap on every visit, boots a live-chat application immediately, and loads a video player before the visitor asks to play it. Lighthouse reports high TBT and the Performance trace attributes several long tasks to the chat and heatmap vendors.

The useful “after” version is not “add defer everywhere.” It changes the amount and timing of work according to business value:

This example deliberately avoids invented performance gains. A real site must measure its own before-and-after result because vendor code, device speed, network conditions, page templates and tag configuration all change the outcome.

Choose the fix in this order

1. Remove it. If a tool is duplicated, abandoned or no longer creates enough value, removing it is usually the cleanest performance fix.
2. Restrict where it runs. A widget needed on checkout or contact pages may not need to execute across the entire site.
3. Load it on demand. Embeds, chat and other optional features are often good candidates when the visitor can explicitly request them. web.dev documents this pattern as a facade for third-party embeds.
4. Change loading order. Use defer, async, delayed tag triggers or framework-specific strategies when they are compatible with the script.
5. Replace the vendor. If a necessary feature remains disproportionately expensive and cannot be configured more efficiently, compare alternatives on both business functionality and performance cost.

If third-party tooling has accumulated over time, a broader third-party script management workflow can help you assign ownership and stop unused tags from quietly returning.

Why defer and async need care

For a classic external script, defer lets the browser download the file while HTML parsing continues, then executes it after the document has been parsed. Deferred classic scripts preserve document order. async also allows downloading during parsing, but the script executes as soon as it is ready and execution order is not guaranteed. MDN’s script element reference documents these differences.

Parser-blocking classic script:

<script src="https://example-vendor.com/widget.js"></script>

Deferred classic script, where the vendor supports deferred execution:

<script src="https://example-vendor.com/widget.js" defer></script>

Adding defer changes when the script executes; it does not make expensive JavaScript cheap. A deferred script can still create long tasks later. Similarly, async can still pause other browser work while it executes. Module scripts are deferred by default, and defer has no effect on inline classic scripts, so copying the attribute blindly is not a universal fix.

Fixes that are easy to overestimate

• Preconnect: can reduce connection setup time to an important third-party origin, but it does not reduce that script’s JavaScript execution cost.
• Self-hosting: can improve control in some cases, but it does not remove CPU cost and may interfere with vendor updates, support or licence requirements. Check the vendor’s documentation before doing it.
• Code splitting: is highly useful for code you control. For third-party code you do not own, the practical options are often a lighter vendor build, conditional loading, a facade, a different integration or a different vendor.
• Lazy-loading images: can be valuable for loading performance, but it is not a direct TBT remedy unless the image or embed was indirectly causing JavaScript work. Keep the diagnosis tied to the bottleneck you actually measured.

Verify the fix in the lab, in the field, and in the product

A lower TBT is only one part of a successful change. Re-run the same Lighthouse test and Performance trace under comparable conditions, then check that the long task you targeted is genuinely reduced or gone. Chrome’s documentation recommends using the Performance panel to investigate main-thread work rather than relying on the aggregate score alone.

Then check real-user responsiveness. PageSpeed Insights and CrUX expose field Core Web Vitals over a rolling collection window, so INP will not necessarily change immediately after deployment. If TBT improves but INP does not, that is useful evidence too: the remaining responsiveness problem may happen later in the visit, inside interaction handlers, rendering work or code outside Lighthouse’s load-time TBT window.

Finally, test the feature you changed. Performance work is not a win if it breaks consent, analytics events, lead forms, chat availability, payments, experiments or accessibility. Use this release checklist:

• Confirm the third-party feature still works in the situations where it is needed.
• Confirm analytics and conversion events have not been duplicated or lost.
• Check mobile as well as desktop; weaker CPUs often make long JavaScript tasks more obvious.
• Compare representative page templates, not just one URL.
• Review TBT and long-task attribution again after major marketing, analytics or widget changes.
• Track INP in field data separately from Lighthouse TBT.

If you use ScanMySEO, an audit can help you surface broader page-performance and site-health issues across your site. Use Chrome’s runtime tooling for the script-level attribution needed to prove which third-party resource is causing main-thread blocking.