HomeSearchSEO ServicesLocal SEOTechnical SEOAI Search (GEO)Paid MediaPPC ManagementPaid SocialContent & WebContent MarketingWeb DesignVideo MarketingLocal & ReputationGoogle Business ProfileListing ManagementReputation ManagementConvert & AutomateConversion OptimizationEmail MarketingMarketing AutomationAI ChatbotSocial MediaAnalytics & StrategyIndustriesDispensariesDentistsLawyersHVACAll IndustriesMoreResultsThe SignalFree ToolsAboutContactFree Audit

Which Third-Party Scripts Are Costing You Core Web Vitals

Chat widgets, tag managers, heatmaps and consent banners each look small on their own. The scores they produce together are the ones your team gets asked about.

A developer spends two weeks compressing images, deferring CSS and trimming the JavaScript bundle. The lab score improves. The field data barely moves, because the bundle was never the problem — the eleven scripts loaded by the tag manager were.

This is the ordinary shape of a Core Web Vitals failure on a commercial site. The code the team owns is the code the team optimizes, and the code doing the damage belongs to somebody else.

Why do third-party scripts hurt more than your own code?

Because they execute on the same single main thread as everything else, and you control neither when they run nor how long they take. Your own code can be split, deferred and budgeted. A vendor tag does what its vendor decided.

The compounding problem is that many third-party scripts load further scripts. One tag in your markup can become a dozen network requests, and the ones added at runtime never appear in any inventory built by reading the page source. That is why script counts done by hand almost always undercount.

Which script types damage which metric?

Each of the three web vitals fails for a different reason, so the script categories map cleanly onto them.

Script typeMetric usually hitMechanism
Consent bannerLCP and CLSRenders over the page, then moves content when dismissed
Tag manager containerINPLoads and runs every other tag on the main thread
Live chat widgetINPHeavy bundle, often loaded eagerly on every page
Ad or affiliate scriptsCLSInserts slots after layout, shifting everything below
Session recording or heatmapsINPListens to every interaction and serializes the DOM
Hosted web fontsLCPBlocks text paint while the font file downloads
A/B testing toolsLCPHides the page until a variant is chosen

The A/B testing row is the one that surprises teams. Anti-flicker snippets deliberately hide the page to prevent the original showing before the variant does, and hidden content cannot paint. The tool is working exactly as designed and destroying the metric while it does.

Key Insight

Lab tools run on a clean browser with no extensions, one geography and a fixed network profile. Field data comes from real visitors with real conditions. Third-party scripts are precisely where those two diverge, because their cost depends on the visitor's connection and the vendor's servers rather than on your code.

How do you find out which one is responsible?

By attributing time to origins rather than to files, then removing the largest offender in a staging environment and measuring the difference. Guessing from a waterfall chart alone reliably blames the wrong script.

  1. Record a performance trace of a real page load with the network throttled, then group main-thread time by the domain that served each script rather than by filename.
  2. List every distinct third-party origin, including the ones loaded by other scripts. The count is normally higher than anyone in the room expects.
  3. Name an owner for each origin. A script with no owner is a script nobody will defend when you propose removing it.
  4. Disable the largest one in staging, re-measure, and note the change against that origin.
  5. Repeat down the list until the remaining origins are individually too small to matter.

Attribution by origin is what makes the conversation possible. "The site is slow" invites debate; "this vendor's tag accounts for a third of main-thread time on mobile" does not.

Common Mistake

Adding async or defer to every third-party tag and considering the problem solved. Those attributes change when a script downloads and starts, not how long it occupies the main thread once it runs. A deferred heavy script still blocks interaction; it just blocks it slightly later.

What can you actually do about a script you need?

Four options, in descending order of how much they help: remove it, delay it until interaction, load it only where it is used, or move it off the main thread.

Removal is the only one that reliably works, and it is available more often than teams assume — most script inventories contain at least one tag from a tool nobody has logged into for a year. After that, delaying until first interaction suits anything that cannot possibly be needed before a visitor touches the page: chat widgets, session recorders, most remarketing pixels. Page-scoped loading is for tools that only matter on a few templates, such as a review widget on product pages and nowhere else. Moving work to a web worker is the most technical option and the least commonly available, because it requires the vendor to support it.

How do you stop the list growing back?

With a rule at the point of addition, since scripts are almost never added by the people who will be asked about the scores later.

The mechanism that works is a named owner and a review date on every tag, recorded wherever tags are managed. Marketing adds a pixel for one campaign, the campaign ends, the pixel stays for three years — that is the default outcome without a review date. A quarterly pass that removes any tag whose owner has left or whose campaign has finished keeps the inventory roughly flat, which is the realistic goal.

It also helps to check field data by template rather than sitewide. A single template carrying a heavy widget can drag the sitewide assessment down while every other page is fine, and Google Search Console groups URLs by similar performance for exactly this reason. Fixing one template is a smaller job than fixing a site, and it is frequently the whole job.

Open your tag manager and count the tags nobody has touched in a year. That number, not your JavaScript bundle size, is the honest measure of how much of your organic search performance is in someone else's hands.

Failing Core Web Vitals and cannot find the cause?

We will trace every third-party script on your site to the metric it damages and tell you which ones are safe to remove.

Get in Touch →
SM
Scott McGovern
Founder & SEO Strategist

Does this apply to your site?

Reading about it is one thing. Point the scan at your own site and see whether this applies to you, and what it is worth fixing.

Free and unlimited. No account, no card, and you get every finding rather than a teaser.