Third-party code

Third-party code is everything a page loads from a domain the site owner does not control: tag managers, analytics, advertising, consent banners, chat widgets, A/B testing, session replay, embedded videos, social buttons, review carousels and payment components. Each one is added for a reason, usually by a different team, and each one costs network bytes and main-thread time on every page view. In our measurements nearly every home page loads third-party code, and the heaviest tags regularly outrank the site's own JavaScript in CPU time. This guide explains what third-party code does to the Core Web Vitals, how to audit it and how to load the tags you keep without letting them block the page.

From PerfDelta's measurements: 96% of the 4,108 home pages load third-party code, from a median of five providers. Only 74% of the websites with field data have a good INP. More in the data section below.

How third-party code affects Core Web Vitals

• INP. Tags run on the main thread. A tag manager that fires twenty triggers on load, a session-replay script that serializes the DOM, or an A/B testing tool that rewrites the page keep the thread busy exactly when the visitor starts tapping. This is the metric third parties hurt most, and the one most sites fail.
• LCP. Scripts loaded synchronously in the head delay rendering; A/B testing tools that hide the page until they have decided which variant to show add their whole load time to LCP; and third-party requests compete with the LCP image for bandwidth and connections.
• CLS. Ads, embeds and cookie banners that insert themselves without reserved space push content down. Late-loading fonts from a font service cause text to reflow.
• Page weight and TBT. Each provider brings its own bundle, often with its own copies of libraries the site already loads.

The Lighthouse finding Reduce the impact of third-party code lists each provider with its transfer size and main-thread blocking time. PerfDelta reports show the same breakdown per page and the share of pages per provider across all measured sites.

Auditing the tags you have

1. Inventory. Export the list from the Lighthouse finding or the Network panel grouped by domain. Add the tag manager's container contents, because one container entry in the audit can hide dozens of tags.
2. Owner and purpose. For every entry, name the team that uses it and the decision it informs. Tags without an owner or a current use are the first to go; in most audits that is a meaningful share of the list.
3. Cost. Note main-thread time and bytes from the audit. Session replay, A/B testing, chat and video embeds are usually the most expensive; a plain analytics pixel is cheap.
4. Timing. Decide for each remaining tag whether it is needed before the first paint (almost never), before the first interaction (consent, maybe analytics), or later (everything else).

Whether a tag is unusually expensive only shows in comparison. The third-party benchmark lists main-thread time and transfer size of the most common services across the home pages PerfDelta has measured, with a page per service: Google Tag Manager, Google Analytics, Google Ads, Meta Pixel, TikTok, LinkedIn Ads, Hotjar, Cookiebot, OneTrust, Usercentrics, Microsoft Clarity, Trustpilot, YouTube and Google Maps. A tag well above the typical value for its service is the first candidate for a closer look.

Loading third-party code without blocking the page

1. Never load tags synchronously in the head

A synchronous <script src="https://..."> in the head stops parsing until the file arrives from another origin. Every tag should be async or defer, and the few that must run early should be inlined and tiny.

2. Delay non-essential tags until interaction or idle

// Load the chat widget on first interaction or after the page is idle
const loadChat = () => {
  const s = document.createElement('script');
  s.src = 'https://chat.example.com/widget.js';
  s.async = true;
  document.head.append(s);
  ['scroll', 'pointerdown', 'keydown'].forEach(ev => removeEventListener(ev, loadChat));
};
['scroll', 'pointerdown', 'keydown'].forEach(ev => addEventListener(ev, loadChat, { once: true, passive: true }));
addEventListener('load', () => (window.requestIdleCallback || setTimeout)(loadChat, 3000));

Tag managers support the same idea through trigger timing: fire marketing tags on "window loaded" or on a scroll trigger rather than on "page view".

3. Use facades for heavy embeds

A YouTube embed loads hundreds of kilobytes of player code before anyone presses play. A facade shows the thumbnail and a play button and loads the real player on click. The same applies to maps, chat launchers and social feeds. Lighthouse's finding Lazy load third-party resources with facades lists candidates.

4. Move analytics server-side where it makes sense

Server-side tagging sends one small request from the browser to your own endpoint and distributes events to vendors from the server. The browser loads one script instead of ten, and vendor scripts no longer run on the visitor's main thread. It costs infrastructure and setup time, and it is the single biggest win for sites that run many marketing tags.

5. Reserve space for ads, embeds and banners

Set explicit dimensions or a min-height on every container that a third party fills later, including the cookie banner. This removes the layout shifts those elements cause; the CLS guide has the details.

6. Preconnect to the one or two origins that matter early

If a consent management script or a critical font service must load early, a preconnect hides part of its connection cost. Do not preconnect to every tag origin; that makes the page slower.

7. Re-audit regularly

Tags accumulate. A quarterly review of the tag manager container against the owner-and-purpose list keeps the count down, and monitoring the third-party share in PerfDelta shows when a new tag changes the page's profile.

Platform notes

• WordPress: plugins add tags without a tag manager: social sharing, related posts, forms and analytics plugins each inject scripts. Check the plugin list against the audit output.
• Shopify: apps are the main source; many inject scripts into every page even when the feature appears only on one. Remove unused apps and check that uninstalled apps left no snippets in the theme.
• Enterprise sites: tag managers plus A/B testing plus personalization are the usual trio. Timing rules in the tag manager and an "anti-flicker" setting with a short timeout limit the damage until server-side tagging is in place.

Frequently asked questions

Is Google Tag Manager itself slow?

The container script is small. The cost comes from the tags it fires and when it fires them. A container with few tags, fired after load, costs little; one with dozens of tags on page view can dominate main-thread time.

Which third-party tags hurt performance most?

In most audits: A/B testing and personalization tools that hide the page until they run, session replay, chat widgets, video embeds and ad scripts. Plain analytics pixels are usually cheap.

Can I lazy-load tags without losing data?

For marketing and chat tags, yes. For analytics, firing on first interaction or after load loses very few page views; firing after a long delay loses bounces, so measure the difference before deciding.

Does a consent banner count as third-party code?

Yes, and it is often one of the heavier items because it loads early and renders a large element. Choose a lightweight consent tool, reserve its space, and keep it from blocking the page.