Third-Party Scripts and Total Blocking Time: A Before-and-After Guide for SMEs

The short answer: use TBT to diagnose blocking, not as an SEO score

Third-party scripts are pieces of JavaScript supplied by another service, such as analytics, advertising, consent management, chat, reviews, maps, video embeds, A/B testing or payment tools. They can be valuable, but they can also add downloads and browser work that competes with your own page.

Total Blocking Time (TBT) is a lab metric. It estimates how much time the browser's main thread is tied up by long tasks during page load. A high TBT is a useful clue that the page may feel slow to respond, but it does not tell you which script is responsible and it is not one of Google's current Core Web Vitals. Google's responsiveness Core Web Vital is Interaction to Next Paint (INP), which is based on real user interactions. web.dev describes TBT as a lab proxy that can help reveal potential INP problems, not a substitute for field INP data. See the current web.dev TBT guidance and Google Search Central's Core Web Vitals documentation.

For an SME, the practical question is not “How do I make every third-party request disappear?” It is: Which script is creating enough user cost to justify changing how or where it runs, and can I make that change without damaging a useful business function?

What TBT actually measures — and how it differs from INP

The browser's main thread handles much of the work required to parse and execute JavaScript, update the page and respond to input. A task that runs for more than 50 milliseconds is treated as a long task for TBT calculation. Only the portion above 50 milliseconds counts as blocking time. A 120 ms task therefore contributes 70 ms of blocking time.

In Lighthouse's standard page-load measurement, TBT adds those blocking portions across the measurement window after First Contentful Paint. web.dev currently recommends treating a TBT below 200 ms on average mobile hardware as a useful lab target, but that threshold is a diagnostic benchmark rather than a Google Search requirement.

A page can have a poor TBT in one synthetic run while real-user INP remains acceptable. The reverse is also possible: a load test can look fine while a later interaction triggers an expensive widget. That is why TBT should start an investigation rather than end it.

Why this matters for SME owners

Main-thread blocking matters first because it can make a site harder to use. A navigation tap, menu, form field or button may appear ready while JavaScript is still occupying the browser. Third-party tools can also change outside your release process, so a page can become slower even when you have not deployed new code.

For search visibility, keep the claim precise. Google says Core Web Vitals are used by its ranking systems, but it also says there is no single page-experience signal and that strong scores do not guarantee top rankings. TBT itself is not a Core Web Vital. Treat TBT reduction as performance and user-experience work that can support healthier responsiveness; do not promise a ranking lift from lowering one lab number. Google's current page experience guidance makes that distinction explicit.

Third-party scripts should therefore be judged on both sides of the equation:

• User cost: main-thread work, network requests, visual instability or a delayed interaction.
• Business value: measurement, consent, revenue, support, booking, trust signals or another clear job.

A heavy script with no current owner or purpose is a strong removal candidate. A heavy payment or consent component may require optimisation rather than removal. A lightweight script that supports a critical workflow may not deserve attention at all.

Diagnostic framework: prove which script is responsible before changing it

Do not begin by adding defer to every external script. First establish whether third-party code is actually the bottleneck.

1. Start with field context. Check PageSpeed Insights for the page or origin if Chrome User Experience Report data is available. Its field section reflects real-user data over the previous 28-day collection period, while Lighthouse provides lab data for debugging. Google's PageSpeed Insights documentation explains the difference.
2. Reproduce the issue in a lab test. Run Lighthouse under consistent mobile conditions. If TBT is high, repeat the test rather than treating one run as definitive. Third-party services can vary between loads.
3. Record a Chrome Performance trace. Chrome's current Performance panel can distinguish first- and third-party activity, show a first-/third-party table with transfer size and main-thread time, and let you inspect the main-thread flame chart. Use the Chrome DevTools Performance reference if you need the exact controls.
4. Find the long tasks. Inspect the longest main-thread events and the script or entity responsible. A large download is not automatically the largest CPU cost; a small script can execute expensive work.
5. Check the third-party inventory. Chrome's current Third parties performance insight groups detected resources by provider. Use it to focus the investigation, not as a reason to delete every listed service.
6. Test the causal link safely. In a staging environment or controlled DevTools test, block or disable one suspected vendor and record the page again. If TBT falls materially, confirm what functionality also disappeared. This isolates cause without immediately altering production.
7. Assign a business owner before removal. Analytics, consent, fraud prevention, booking, payments and campaign measurement can be operationally important even when they are expensive.

For a broader vendor inventory and governance workflow, use ScanMySEO's guide to managing third-party scripts.

Prioritise by measured cost and business necessity

This order matters. Removing one abandoned experiment or duplicate tag can save more work than carefully tuning several small scripts that still need to exist.

Remediation blueprint: choose the lowest-risk fix

1. Remove or restrict before tuning

If a script has no current purpose, remove it. If it is useful on only one part of the site, stop loading it everywhere. A booking widget does not need to run on every blog post; a map may only be useful on a location page; an A/B testing tag should not live forever after the experiment ends.

2. Use async and defer according to behaviour

For classic external scripts, async lets the browser continue parsing the document while the file downloads, then executes the script as soon as it is ready. Execution order is not guaranteed. defer also allows download during parsing, but waits until the document has been parsed and preserves order between deferred classic scripts. Module scripts are deferred by default, so the defer attribute does not change their behaviour. See MDN's current script element reference.

<!-- Independent classic script: only if the vendor supports this pattern. -->
<script src="https://vendor.example/analytics.js" async></script>

<!-- DOM- or order-dependent classic script. -->
<script src="https://vendor.example/widget.js" defer></script>

Neither attribute makes JavaScript execution free. An asynchronous or deferred script can still create a long task when it eventually runs. The goal is to avoid unnecessary parser blocking and to schedule work at a time that does not damage the user's journey.

3. Delay optional execution carefully

Chat, heatmaps, review widgets, social embeds and other optional features may be candidates for delayed or interaction-based loading. But an arbitrary five-second timeout simply moves the work later. If the script starts just as the user tries to interact, the page can still feel slow. Prefer a trigger connected to genuine need, and test the first interaction after the change.

4. Audit tag-manager triggers

A tag manager centralises deployment; it does not make tags cheap. Check for duplicate analytics, old campaign pixels, tags firing on every page when they only need one template, and tags that launch more vendors. The visible container may be small while the code it injects creates most of the main-thread work.

5. Do not self-host just to make a script look first-party

Self-hosting can give you more control over delivery for some static libraries, but it does not remove the CPU cost of executing the JavaScript. It can also transfer responsibility for updates, security fixes and compatibility to you. Use it when the vendor and maintenance model make sense, not as a cosmetic way to move a resource out of the “third-party” column.

Worked before-and-after example: a service page with high TBT

This example is hypothetical. The numbers demonstrate the calculation and decision process; they are not ScanMySEO customer results and they do not promise a conversion or ranking outcome.

An SME service page produces a repeatable Lighthouse TBT of roughly 335 ms. A Performance trace shows four long tasks during the load window:

The important part is not the dramatic drop in the example. It is the decision sequence:

1. The trace shows which work is expensive.
2. The business decides which tools are still needed.
3. The lowest-value cost is removed first.
4. Useful tools are narrowed to the pages or moments that need them.
5. First-party work is not mislabelled as a vendor problem.
6. The page and user journeys are retested after every material change.

If the “after” trace still shows high TBT but third-party work is small, stop tuning vendors and inspect your own JavaScript, rendering work and long tasks.

Common mistakes that create false confidence

• Calling TBT a Core Web Vital. It is a lab metric. INP is the current responsiveness Core Web Vital.
• Assuming high TBT means Google is penalising the page. TBT is not a direct Google Search ranking metric. Use it to diagnose performance.
• Blaming every external request. Third-party presence is not the same as third-party harm. Measure execution cost and timing.
• Adding defer to every vendor tag. Some scripts require a specific execution order or vendor loader. Blind changes can break features.
• Only measuring download size. Transfer size and CPU cost are different. A small file can still execute expensive code.
• Delaying a script until the user's first click. That can shift the performance problem into the interaction you care about.
• Removing analytics, consent or payment code without an owner. A faster lab test is not a successful change if critical data or workflows stop working.
• Selecting the best of several Lighthouse runs. Compare repeated tests under the same conditions; third-party behaviour can vary.

Verification loop: prove the page improved without breaking the business

Performance work is complete only when the technical result and the user journey both survive the change.

1. Make the before/after comparison fair. Use the same URL, browser profile, mobile/desktop setup, network and CPU settings, consent state and cache state. ScanMySEO recommends several repeat runs and comparing the typical result rather than cherry-picking the fastest run.
2. Compare the trace, not just the headline score. Check TBT, the number and duration of long tasks, third-party main-thread time and whether the expected vendor work moved or disappeared.
3. Exercise the changed feature. Open the chat, submit the form, play the embed, load the map or complete the booking flow. A script that was moved later can still create a slow interaction.
4. Validate measurement and consent. Confirm required analytics events, conversion events, consent states and marketing tags still behave as intended.
5. Watch field INP. If PageSpeed Insights has CrUX data, remember that its field metrics use a rolling 28-day period, so a production change will not be reflected instantly.
6. Record the ownership decision. Note why the script exists, where it is allowed to load and when it should be reviewed again. Third-party performance can regress without a code release from your team.

For a broader post-fix testing workflow, see ScanMySEO's performance verification decision guide.

SME owner checklist: what to do first

• Confirm whether real-user INP is poor, or whether the concern exists only in a lab test.
• Run a repeatable Lighthouse test and note TBT.
• Use Chrome DevTools to identify which entities consume main-thread time.
• Remove duplicate, expired and ownerless tags before micro-optimising required ones.
• Restrict useful scripts to the pages and states that need them.
• Choose async, defer, delayed loading or lazy loading according to the script's actual behaviour and vendor guidance.
• Retest the important user journey, not just the homepage load.
• Verify analytics, consent, forms and other business-critical functions after deployment.
• Monitor field responsiveness over time rather than assuming an immediate SEO outcome.

A lower TBT is useful when it reflects less unnecessary main-thread work. The goal is not to remove every third-party service or chase a perfect Lighthouse score. It is to keep the scripts that earn their place, run them only where they are needed, and make the page responsive for the people trying to use it.