Open the Network panel on almost any commercial website and you will see requests flying out to analytics vendors, ad networks, chat widgets, heatmap tools, review platforms and video hosts. Each one was added for a good business reason. Together, they are often the single biggest drag on page speed.
Third-party scripts are hard to manage precisely because nobody owns them as a whole. Marketing adds a pixel, sales adds a chat tool, product adds an A/B testing snippet, and none of them is responsible for the combined cost on Core Web Vitals.
This guide explains how third-party scripts slow pages down, how to audit them, and a practical process for keeping the ones you need while removing or deferring the rest.
Key Takeaways
- Third-party scripts are code you do not author, served from other companies' servers: analytics, ads, chat, embeds, A/B testing and more.
- According to the 2024 Web Almanac, about 92% of pages use at least one third party.
- They cost performance through extra connections, main-thread JavaScript and, in some cases, render blocking.
- Audit regularly, remove duplicates, load the rest asynchronously, and use lazy loading or facades for heavy embeds.
- Give one person ownership of the tag inventory and set a performance budget for third parties.
What Counts as a Third-Party Script?
web.dev defines third-party JavaScript as scripts embedded in your site that are not authored by you and are served from third-party servers. Typical examples include:
- Analytics and measurement tags (including pixels loaded through a tag manager).
- Advertising scripts and ad iframes.
- Live chat and customer support widgets.
- Video players and social media embeds.
- A/B testing and personalisation tools.
- Helper libraries such as date formatting or animation loaded from a public CDN.
The 2024 Web Almanac third-parties chapter found that third-party usage "remains high at 92%" of pages. It also reported a median of 66 third parties on the top thousand websites and 27 across the top million, with several Google-owned domains, such as Google Tag Manager and Google Analytics, among the most common.
How Third-Party Scripts Slow Your Site
“Setting up connections takes time, and sending too many requests to multiple servers causes slowdowns.”
— web.dev, Third-party JavaScript performance
Each new origin needs a DNS lookup, a TCP connection and a TLS handshake before any bytes arrive. Beyond networking, scripts compete for the browser's main thread, which is the same thread that responds to taps and clicks. That is why heavy tags often hurt Interaction to Next Paint even when the page looks loaded.
| Problem | Typical cause | Metric most affected |
|---|---|---|
| Extra connection setup | Many different vendor domains | LCP, overall load time |
| Render blocking | Synchronous <script> in the <head> | FCP, LCP |
| Long main-thread tasks | Large analytics, chat or testing bundles | INP |
| Layout shifts | Ads, banners and embeds injected without reserved space | CLS |
| Content hiding | A/B testing snippets that hide the page until processed | LCP |
| Single point of failure | A vendor outage on a blocking script | Everything; web.dev notes timeouts of 10 to 80 seconds |
The last row is easy to overlook. web.dev explains that if a blocking third-party resource fails, rendering is blocked until the request times out, which can be anywhere from 10 to 80 seconds.
How to Audit Your Third-Party Scripts
- Build an inventory. Export every tag from your tag manager and list hard-coded scripts from your templates. Record vendor, purpose, owner and pages loaded on.
- Measure the cost. Run PageSpeed Insights or Lighthouse; since Lighthouse 13, the third-party summary appears as a "third parties" insight. Use the DevTools Performance panel to see main-thread time by domain.
- Test removal. In DevTools, block a domain via request blocking and reload to see how much faster the page becomes.
- Ask "who still uses this?" Remove tags for tools whose contracts ended, duplicate analytics, and old pixels from past campaigns.
- Decide a loading strategy for each tag you keep (see the table below).
- Set a budget. Agree a limit, such as a maximum script weight or number of vendors per template, and check it before any new tag goes live.
- Repeat quarterly. Third-party bloat returns quickly without a regular review.
Loading Strategies That Work
web.dev's guidance on efficiently loading third-party JavaScript is clear on the default:
“you should always load third-party scripts asynchronously unless the script has to run before the page can be rendered.”
— web.dev, Efficiently load third-party JavaScript
| Technique | What it does | Good for |
|---|---|---|
async / defer | Downloads without blocking HTML parsing | Analytics, most tags |
preconnect / dns-prefetch | Starts connections early | The one or two most critical third-party origins |
| Lazy loading | Loads the embed only when near the viewport | Videos, maps, social embeds below the fold |
| Facades | Shows a static placeholder until the user interacts | Video players and chat widgets |
| Self-hosting | Serves the script from your own domain | Stable libraries you can update yourself |
| Server-side tagging | Moves vendor logic off the browser | Analytics and ad conversion tags |
Facades deserve a note. A facade is a lightweight static element that looks like the embed and loads the real thing on click; libraries like lite-youtube-embed are popular examples. Lighthouse 13 removed its dedicated facades audit, but the technique still saves a lot of JavaScript. For lazy loading patterns more broadly, see our guide to lazy loading and SEO, and for moving tags off the page see server-side tagging.
Third-Party Scripts and SEO
Search engines do not penalise you for using analytics or chat tools. The SEO impact comes through user experience and Core Web Vitals, and through rendering: if important content or links depend on a third-party script, Google must render JavaScript to see them. Keep critical content in the HTML, as covered in our JavaScript SEO guide. For behaviour analytics, lighter tools exist; our Microsoft Clarity guide covers one free option, but every tool still has a cost, so measure it.
Common Mistakes
- Two tools doing one job, such as two tag managers or two analytics suites; web.dev specifically advises against this.
- Loading everything on every page. A checkout pixel does not need to fire on blog posts.
- Anti-flicker snippets left at long timeouts, hiding the page for seconds when the testing tool is slow.
- Ads and banners without reserved space, causing layout shifts.
- No owner. Without a named person approving new tags, the inventory only grows.
- Preconnecting to every vendor, which wastes early connections; web.dev says preconnect is best for only the most critical connections.
- Forgetting fonts and widgets are third parties too. Hosted fonts add connections (see web font optimization), and chat or review widgets often inject hundreds of nodes, adding to excessive DOM size.
- Ignoring caching. Self-hosted copies of vendor libraries should be versioned and cached properly; see our guide to browser caching.
Related Guides
- Browser Caching: How to Set It Up for Faster Repeat Visits
- Index Bloat: How to Find and Remove Low-Value Indexed Pages
- How to Keep Staging Sites Out of Google
Frequently Asked Questions
Do third-party scripts hurt SEO?
Not directly, but they can slow pages and hurt Core Web Vitals and user experience. If important content depends on them, they can also make rendering harder for search engines.
Is Google Tag Manager bad for page speed?
The container itself is reasonably light. The problem is usually what is loaded through it. Audit the tags inside, fire them only where needed, and consider server-side tagging for heavy analytics.
What is the difference between async and defer?
Both download without blocking parsing. Async scripts run as soon as they arrive, in any order; deferred scripts run in order after the HTML is parsed. Defer is usually safer for scripts that depend on each other.
How many third-party scripts is too many?
There is no universal number. Set a budget based on your own Core Web Vitals and test the impact of each tag. The 2024 Web Almanac median of 27 third parties across the top million sites is a reference point, not a target.
Should I self-host third-party scripts?
Self-hosting gives you control over caching and loading, but you become responsible for keeping the script updated. It suits stable libraries more than fast-changing vendor tags.
Conclusion
Third-party scripts will never be zero, but they should be deliberate. An up-to-date inventory, a named owner, async loading by default and facades for heavy embeds will recover much of the speed you have lost to tag creep.
Need a hand untangling your tags? Our page speed optimization and Core Web Vitals specialists can audit every script and recommend what to keep. Request a free quote to get started.
References
- Third-party JavaScript performance – web.dev
- Efficiently load third-party JavaScript – web.dev
- Lazy load third-party resources with facades – Chrome for Developers
- Third Parties chapter, 2024 Web Almanac – HTTP Archive
- Lighthouse 13.0 release notes – Chrome for Developers
- What Is Page Speed & How to Improve It – Semrush Blog
