Third-Party Scripts and Performance: Measure and Tame Them

Open the source of almost any business website and you will find code that is not yours: an analytics tag, an advertising pixel, a live chat bubble, a cookie banner, a video player, a review widget, a font service. Each one is a third-party script, loaded from another company's server. Each was added for a reason, and each costs something. Third-party scripts are among the most common reasons a fast site becomes a slow one, and because they live on someone else's server, you cannot fix them by editing your own code.

This guide is for site owners, marketers and developers who want to know what those scripts are costing and what to do about it. You will build an inventory, measure the effect of each script with free tools, and apply the options that fit: remove, delay, load more cheaply, or isolate. It will not tell you to delete everything. Some of these tools earn their keep, and the right answer is often "keep it, but load it later". There is no promise of a particular speed-up or search result.

Before you begin

You need a list of who can add scripts to your site: developers, marketers using a tag manager, plugins, and the platform itself. You need Chrome with Developer Tools, and ideally access to your tag manager and CMS. Reading and measuring are safe. Changing tags can break tracking, ad revenue or conversions, so tell the people who rely on them, test on a staging site or in the tag manager's preview mode, and record the current setup first.

Plan an hour for the inventory and measurement. Changes take longer, especially when a business owner has to approve removing a tool.

Why third-party scripts slow pages

web.dev's guidance on third-party code lists the main costs:

They add requests to other servers, each needing its own connection.
Heavy JavaScript keeps the browser's main thread busy, which can delay rendering and responses to taps and clicks.
Large unoptimized images or videos use visitors' data.
Some scripts block content from displaying until they finish.
Older techniques such as document.write() hurt the user experience.
Slow third-party servers can delay the window load event even when the script is loaded with async or defer.

The main-thread point matters for Interaction to Next Paint. The article on script evaluation explains that a browser must parse and compile a script before running it, and a long task blocks the main thread so interactions wait. web.dev also notes that Total Blocking Time correlates well with INP, so a high TBT in a lab test often points to script-related delays.

Step-by-step instructions

Step 1: Build an inventory of third-party code

Open DevTools, go to the Network panel, tick "Disable cache" and reload. Look at the Domain column and note every host that is not your own. In Lighthouse (run from DevTools in a mobile mode), the "Reduce JavaScript execution time" audit has a "Show 3rd-party resources" option, and web.dev points out that this helps find CPU-heavy third-party scripts. Also open your tag manager and list each tag, its trigger and who requested it.

For each item write down: what it does, who owns it, which pages it runs on, and whether it is still used. Many sites find tags for campaigns that ended years ago.

What success looks like: You have a table of third-party hosts and tags with an owner and a purpose for each.

Step 2: Measure the cost with a baseline

Lighthouse reports the impact of third-party code on the main thread. Its "Reduce the impact of third-party code" audit measures how long third-party scripts block the main thread during load. According to the Chrome documentation, it flags pages where that blocking time is 250 ms or longer. Note that this documentation says the audit has moved into other insights in Lighthouse 13, so look for third-party information in the current report.

For your own baseline, use the setup web.dev recommends: Lighthouse in DevTools in mobile mode with network and CPU throttling (simulated Fast 3G with 4x CPU slowdown in its example), with "Clear Storage" ticked. Run it at least three times and take the median, because third-party content can load different things each time.

What success looks like: You have median lab numbers for load, blocking time and total transfer size, and the date.

Step 3: Test each script by blocking it

DevTools lets you block a request and see what changes. In the Network panel, right-click a third-party request and choose "Block request URL". Reload with throttling on, and measure again. Repeat, one script or domain at a time. If blocking something makes no clear difference, it is not your problem; narrow the list until you find what is. web.dev describes this method for isolating slow third-party code.

Block one at a time and note the change in a table: script, owner, change in load time, change in blocking time, change in transfer size.

What success looks like: You can rank scripts by cost, and know which ones are worth acting on.

Step 4: Remove what you do not need

Every request you remove is a request you never have to optimize. web.dev's advice is to remove scripts that add little value. Ask the owner of each: is anyone still using this report or this feature? Remove old pixels, duplicate analytics, unused social widgets and A/B testing tools for finished tests. Remove them from the page, from the tag manager and from any plugin settings. Check that analytics and conversion tracking still work.

Be aware that a tag manager can load tags asynchronously, but many tags and many listeners still add requests and slow the page.

What success looks like: The inventory shrinks, and the remaining items each have a clear purpose.

Step 5: Load the rest later and less often

For scripts you keep, change when they load.

Use async or defer on the script element. web.dev explains that async downloads in parallel and runs when ready, while defer runs after the document is parsed. Use defer for less critical scripts, and async for scripts that should run early, such as some analytics. Do not use async for essential libraries that other code depends on. In Chromium browsers, both can lower the request priority, so scripts may start loading later.
Lazy load widgets until they are needed. Chat bubbles, video players, maps and review widgets can wait until the visitor scrolls near them or clicks a placeholder. web.dev mentions lazy loading for ads and videos, with IntersectionObserver as an efficient way to detect visibility. A common pattern is a "facade": a lightweight image that looks like the widget and loads the real one on click. Lazy loading relies on JavaScript, so flaky connections can affect it.
Delay low-value tags until after the page is interactive. Most tag managers allow triggers such as "page fully loaded" or user interaction. Be careful with analytics: web.dev warns that deferring too long can lose early page-load data.

See render-blocking CSS and JavaScript for the loading attributes in more depth, and lazy loading embeds for videos and maps.

What success looks like: Third-party scripts no longer block the first render, and heavy widgets load only on demand.

Step 6: Warm up connections you cannot avoid

If a third-party host is needed early, such as a font or critical API, web.dev recommends resource hints. dns-prefetch does the DNS lookup ahead of time, while preconnect also sets up the connection and TLS handshake, which helps HTTPS hosts. Use them only for the few hosts that matter, since each hint uses resources.

<link rel="preconnect" href="https://fonts.example.net" crossorigin>
<link rel="dns-prefetch" href="https://fonts.example.net">

What success looks like: The connection to key third-party hosts starts earlier in the Network waterfall.

Step 7: Consider isolating or self-hosting

Two more options carry trade-offs. Iframes keep third-party code from blocking the main page's own execution, though the load event still waits for them. Self-hosting a script gives you control over DNS and caching, but you must update it by hand, and you lose the vendor's automatic updates and security fixes. web.dev lists both caveats. Check the vendor's terms before copying their script to your server.

Where a vendor offers a lighter version of its tag, or a server-side option, ask about it. Your options depend on the vendor.

What success looks like: You have chosen isolation or self-hosting only where the benefit justifies the maintenance.

Step 8: Set a rule so it stays fixed

Third-party creep returns. Agree on a process: every new tag needs an owner, a purpose and a test of its impact before launch. Review the inventory every quarter. Save a Lighthouse run as a baseline and compare it when marketing adds something new. Consider Lighthouse CI for catching regressions before release.

What success looks like: A written policy exists, and someone owns the quarterly review.

Final verification checklist

You have a list of every third-party host and tag, with an owner and purpose.
You measured at least three throttled lab runs and recorded the median.
You tested the effect of each major script by blocking it.
Unused tags are removed from the page, the tag manager and plugins.
Non-essential scripts load with defer, async or a delayed trigger.
Chat, video and map widgets load on demand.
Analytics and conversion tracking still record correctly.
Field data (real visitors) is checked over the following weeks.

Common mistakes to avoid

Treating a tag manager as free. Tags can load asynchronously, but each one still adds requests and work. Review what it loads.

Using async on a script others depend on. Scripts can then run in an unexpected order. Use defer or keep the order.

Deferring analytics too long. You can lose early page-load data. Test that the numbers still add up.

Judging by one test run. Third-party content varies. Use several runs and the median.

Removing a script without telling its owner. Marketing or sales may depend on it. Agree on removal first.

Self-hosting and forgetting updates. A copied script does not receive vendor fixes. Set a reminder to refresh it.

Preconnecting to everything. Hints compete for resources. Use them for the few hosts that matter.

Frequently asked questions

Which third-party scripts are the worst?

It varies by site, so check your own measurements. The costly ones are generally those that run a lot of JavaScript on the main thread or pull in many other resources.

Does Google Tag Manager slow my site?

web.dev notes that tag managers can load tags asynchronously, but excessive tags and listeners add requests and slow pages. The cost depends on what you put in the container, so audit and trim tags regularly.

Should I self-host analytics scripts?

It can reduce extra connections and give you control over caching, but you take on updates and compatibility checks. web.dev lists this trade-off. Check your analytics vendor's terms first.

Do third-party scripts affect SEO?

They can slow pages and hurt responsiveness metrics, and Google says Core Web Vitals align with what its ranking systems aim to reward. This guide makes no claim about rankings for any tag. See Core Web Vitals explained.

How do I measure real-visitor impact?

Use field data from the Chrome User Experience Report through PageSpeed Insights or Search Console, or your own real-user monitoring. Lab tests are good for finding causes; field data shows what visitors experienced.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.