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

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

Third-party scripts are pieces of JavaScript supplied by another service: analytics, consent tools, chat widgets, heatmaps, advertising technology, A/B testing platforms, review widgets, booking tools and video embeds are common examples. They can be useful or essential, but every script can add network requests, parsing and execution work.

Total Blocking Time measures how much time the browser's main thread is blocked by long tasks during a lab page-load test. A long task lasts more than 50 milliseconds; TBT adds up only the portion of each long task beyond that first 50 milliseconds. Lighthouse reports TBT between First Contentful Paint and Time to Interactive. Google's current TBT guidance describes it as a lab metric and notes that a low TBT often correlates with a low Interaction to Next Paint (INP), but the two metrics are not interchangeable.

That distinction matters. The current Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). TBT is useful because it can expose main-thread congestion before launch or during debugging, while INP measures responsiveness experienced by real users throughout a visit. Google recommends an INP of 200 milliseconds or less at the 75th percentile for a good user experience. See Google's Core Web Vitals documentation.

Why third-party scripts can raise TBT

The browser usually runs JavaScript on its main thread. While a long JavaScript task is running, the browser cannot immediately process another main-thread task. If that work happens during page load, Lighthouse can record blocking time.

Third-party code can create this pressure in several ways:

• Too much JavaScript executes early. A chat client, tag bundle or experimentation platform may parse and run before the visitor needs it.
• One tool loads more tools. A tag manager or embed can trigger additional libraries, trackers and network requests that are not obvious from the page template.
• Multiple vendors duplicate work. Two analytics systems, overlapping heatmaps or repeated libraries can consume CPU without adding equivalent business value.
• Widgets initialise on every page. A scheduler or support tool may run on pages where very few visitors use it.
• The third party changes independently. A vendor can ship more JavaScript without a change to your own deployment.

Chrome's performance documentation recommends reducing or deferring third-party code so that a page's own content is prioritised, and the current DevTools Performance panel includes a 3rd parties insight that groups third-party resources and CPU activity.

What TBT does—and does not—mean for SEO

A high TBT is evidence of blocking work in a controlled lab test. It is not evidence that Google has applied a ranking penalty, and TBT itself is not a Core Web Vital. The practical concern is user experience: heavy main-thread work can make a page feel unresponsive, especially on slower phones.

Google says its ranking systems use Core Web Vitals and look at broader page experience, but it also states that good scores do not guarantee top rankings and that relevance remains important. Treat performance work as a user-experience and technical-quality task first, not as a promise of an organic-traffic increase. Google's page-experience guidance explains that nuance.

Diagnose the expensive script before changing how it loads

A Lighthouse TBT number tells you that blocking work occurred; it does not, by itself, prove which vendor caused it. The useful workflow is to combine a repeatable lab test with a trace that attributes CPU time and network activity.

1. Choose a representative page. Test the homepage if it carries the full marketing stack, but also test a high-value landing page, product/service page or contact page if their scripts differ.
2. Create a repeatable baseline. Use the same URL, device profile and test method. Performance results vary, so ScanMySEO recommends comparing several runs rather than treating one run as absolute truth.
3. Record TBT and the Lighthouse diagnostics. Note the lab TBT, long tasks and JavaScript execution findings. Do not compare a desktop test before a change with a mobile test afterwards.
4. Open Chrome DevTools Performance and inspect third-party activity. Use the 3rd parties insight and Main track to see which entities occupy CPU time around long tasks. A script with a large download is not necessarily the script with the largest execution cost.
5. Map each service to a business purpose and owner. Ask what it does, where it needs to run, what would break if it were delayed, and whether anyone still uses its output.
6. Check field responsiveness separately. TBT is lab data. Use INP from PageSpeed Insights, Search Console, CrUX or your own real-user monitoring where available. Lab and field results can differ because they measure different conditions and behaviour; web.dev's lab-versus-field explainer describes why.

One common mistake is to assume every millisecond of TBT belongs to third parties. First-party bundles can create long tasks too. Conversely, a vendor library proxied through your own domain may no longer look “third-party” by origin while still doing the same CPU work. Diagnose the work, not just the hostname label.

A before-and-after example for an SME website

The example below is hypothetical. The timings are illustrative rather than ScanMySEO customer data, and they are not a promised outcome.

Imagine a B2B services website with a tag manager, analytics, a chat widget, an old heatmap, a booking embed and a video player. A repeatable mobile Lighthouse test produces a median TBT of roughly 1,100 ms across the chosen test runs.

After those changes, imagine the same repeatable lab method reports a median TBT of about 260 ms. That is a substantial diagnostic improvement, but it should not be described as “SEO fixed”. The remaining work might be first-party JavaScript, another vendor, or simply the next-largest long task. Current web.dev guidance suggests striving for TBT below 200 ms on average mobile hardware, but that is a lab-performance target rather than a Google ranking cut-off.

Fix scripts in this order: remove, restrict, delay, then optimise

For a small business, the lowest-risk improvement is often not a clever loading attribute. It is reducing work that should not run in the first place.

1. Remove scripts with no current business value. Retired heatmaps, duplicated analytics, old campaign pixels and abandoned widgets are good candidates.
2. Restrict where each script runs. A booking tool may belong only on booking pages. A review widget may not need to initialise site-wide.
3. Delay non-critical functionality. Consider loading chat, video players or heavy embeds after initial content, when they enter the viewport, or after a deliberate user action—provided the integration remains functional and accessible.
4. Use async and defer deliberately for supported external scripts. These attributes change when classic external scripts are fetched and executed, but they do not erase the CPU cost of executing the script.
5. Reduce long tasks in code you control. If first-party JavaScript remains the bottleneck, split large tasks, remove unused code or move non-urgent work later.

For classic external scripts, async downloads while HTML parsing continues and executes as soon as the file is ready; execution order is not guaranteed. defer also downloads while parsing continues, but executes after the document has been parsed and preserves document order for deferred classic scripts. MDN's script element reference documents the behaviour.

<!-- Independent script that may run as soon as it is available -->
<script async src="https://vendor.example/analytics.js"></script>

<!-- Script that should wait until parsing is complete and keep order -->
<script defer src="https://vendor.example/widget.js"></script>

Do not copy these attributes onto every vendor tag blindly. Some scripts have dependencies, some integrations already inject code asynchronously, and some business-critical tools need specific loading instructions. Follow the vendor's supported implementation and test the complete user journey.

Also remember that async can still create a long task when the script executes. If a vendor spends 400 ms on the main thread, changing only the download behaviour may improve parsing while leaving a sizeable blocking task. Removal, less code, fewer triggers or later execution may be more effective.

A simple decision rule for each third-party tool

For every script, ask these questions in order:

1. Do we still need it? If no, remove it.
2. Does it need to run on this page? If no, narrow the trigger or template.
3. Does it need to run before the main content is usable? If no, delay it.
4. Does it need to run before a visitor asks for its feature? If no, consider interaction- or visibility-based loading.
5. Could changing it break consent, payment, fraud prevention, forms, attribution or another critical workflow? If yes, involve the relevant owner and verify functionality before release.
6. After the change, is the browser still spending significant time in this vendor? If yes, consider a lighter configuration or alternative, based on business value as well as performance.

If your site has a large marketing stack, the broader third-party script management guide can help you turn this into an ongoing governance process rather than a one-off cleanup.

Verify the fix without overclaiming the result

A valid before-and-after comparison uses the same page and broadly the same lab conditions. Re-run Lighthouse several times, compare the distribution or median rather than one unusually good run, and keep notes about what changed.

Then check four different kinds of success:

• Lab performance: Did TBT and the relevant long tasks fall under the same test conditions?
• Real-user responsiveness: Does INP improve in field data after enough real-user data is available? Do not expect CrUX-derived reports to react instantly to a deployment.
• Functional behaviour: Do forms, chat, booking, media, consent controls, analytics events and conversion tracking still work?
• Business impact: Did you remove or delay anything that a sales, support or marketing workflow genuinely relies on?

If TBT barely moves after changing a script, do not assume the test “failed”. It may show that the script was not the dominant source of blocking time. Return to the trace and inspect the next-largest tasks. If TBT improves substantially but field INP remains poor, investigate interaction-time work as well as page-load work.

Prevent the problem from returning

Third-party performance problems often reappear because scripts are easy to add and rarely given an end date. Keep a lightweight register containing the tool, owner, purpose, pages or triggers, vendor documentation, and a review date. Re-audit after major marketing-tool changes, redesigns or tag-manager releases.

A useful performance budget does not need a universal magic number. For an SME, it can be a simple rule: every new third-party script must have an owner, a measurable purpose and a loading strategy, and it should not run on pages where it adds no value. If a new vendor noticeably increases main-thread work, that cost should be weighed against the business benefit before it becomes permanent.

The key point is straightforward: TBT is a diagnostic clue, not a search-ranking verdict. Find the scripts creating blocking work, remove what is unnecessary, load the rest at the right time, and verify both lab performance and real-user responsiveness before calling the job complete.