By Mehdi HassanWhat are third-party scripts and why do they slow a site down?
Third-party scripts are any JavaScript your site loads from another company's servers: analytics, tag managers, chat widgets, heatmaps, A/B testing tools, ad pixels, consent banners and embedded video players. They slow a site down because they compete with your own code for the browser's main thread, and you don't control how big they are or when the vendor changes them.
The damage shows up mostly in Interaction to Next Paint (INP), the responsiveness metric in Google's Core Web Vitals. A chat widget running a long task while a visitor taps your pricing toggle makes the tap feel broken. Scripts that inject banners above the fold can also delay the largest image and push content around.
Modern frameworks don't save you from what you add on top. Field data for Q2 2026 from corewebvitals.io shows only about two-thirds of Next.js sites pass INP, with a median around 236ms. The problem is rarely one script. It's twenty, each added by a different person for a good reason, and none of them ever removed.
How do you audit third party scripts performance on your site?
You audit third party scripts performance by listing every script, measuring what each one costs, and asking who owns it and what it earns. The six steps below take a growth team from "we don't know what's on the site" to a ranked list of what to cut, delay or keep.
Pull the full list
Record a page load in Chrome DevTools and group requests by domain, or use the third-party summary in the Performance panel. Then export every tag from your tag manager, because many tags fire only after consent or on certain pages. Check templates and CMS embed fields for hard-coded snippets too.
Measure the cost of each script
For each script, note transfer size, request count and main-thread time from a Performance trace with mobile CPU throttling on. Lighthouse's third-party audits group this by vendor, which saves a lot of manual sorting.
Name an owner
Put a person's name next to every script. If nobody claims one within a week, it moves to the removal list.
Write down what it earns
A pixel feeding a paid campaign with live spend earns its place. A heatmap tool nobody has opened since the last redesign doesn't. Be specific: name the report, metric or decision the script feeds.
Decide: remove, delay, replace or keep
Work through the list in that order. Removal is free speed; delaying is nearly free; replacing takes a project; keeping is the default only for scripts with a named owner and purpose.
Re-measure in the field
Lab tests show direction. Real-user data in Search Console's Core Web Vitals report or your own monitoring shows whether INP actually moved, usually a few weeks after the change ships.
What should a script inventory template include?
A script inventory is a one-row-per-script sheet that puts performance cost next to business value, so the decision becomes obvious. Keep it in a shared spreadsheet the whole growth team can see, and treat it as the source of truth for what's allowed on the site.
Column | What to record | Example entry |
|---|---|---|
Script and vendor | Product name and the domain it loads from | Live chat widget |
Loaded via | Tag manager, hard-coded, CMS embed or app integration | Tag manager |
Pages | Where it fires | Every page |
Transfer size | Kilobytes from the Network tab | Measured in DevTools |
Main-thread time | Milliseconds from a throttled trace | Measured in DevTools |
Loading strategy | Blocking, async, defer, after consent or on interaction | Async on page load |
Owner | The person accountable for it | Head of sales |
What it earns | The metric or decision it feeds | Demo conversations started |
Decision and review date | Keep, delay, replace or remove, and when to check again | Load on click, review next quarter |
The cost columns come from measurement. The "what it earns" column comes from a conversation, and that's where most scripts fall. In our experience scripts get cut far more often because nobody can fill in that column than because they're the heaviest on the list.
How do you reduce third-party scripts without losing data?
You reduce third-party scripts by removing what nobody uses, delaying what isn't needed at load, and merging tools that do the same job. Many marketing sites can cut a meaningful share of their script cost without losing any data a team actually reads.
- Remove duplicates. Two analytics tools, a GA4 tag hard-coded in the template and again in the tag manager, or two session-recording tools left over from trials. Duplicate GA4 and Ads tags are also a common cause of broken Consent Mode v2 data.
- Load on interaction. Chat widgets, scheduling embeds and video players can render as a light placeholder (a button or a poster image) and load the real script when someone clicks.
- Delay non-critical tags. Heatmaps and retargeting pixels rarely need to run before the page is usable. Fire them after the page settles or after consent.
- Scope tags to pages. A scheduling widget belongs on the demo page, not on every blog post.
- Replace heavy tools when the feature you use is a small part of what the script ships.
- Use your framework's loading controls. Next.js's Script component lets you choose when each script loads. Our guide to next/image, fonts and scripts in Next.js covers the options.
Once the scripts are trimmed, the remaining work is in your own code. Our guide on how to fix INP covers long tasks and event handlers, and the platform-specific fixes for Framer, Webflow and Next.js cover what each builder lets you control.
Which scripts should you keep, delay or remove?
Keep a script when the decision it informs is worth more than the speed it costs; when nobody can say what it informs, remove it. The table shows the decisions we usually reach for common script types on a startup marketing site. Your inventory may say otherwise, and it should win.
Script type | Usual cost profile | Our usual decision |
|---|---|---|
Web analytics | Moderate, runs on every page | Keep one tool, load it once |
Tag manager container | Grows with every tag added | Keep, review quarterly |
Live chat widget | Often heavy, runs on every page | Load on click, only on key pages |
Session recording and heatmaps | Heavy, listens to every interaction | Run as time-boxed studies |
Client-side A/B testing | Can delay what visitors see first | Only during a live test |
Ad and retargeting pixels | Many small scripts | Keep those tied to active spend |
Embedded video player | Heavy player code | Poster image, load on click |
Consent banner | Required where you need consent | Keep, choose a light one |
Hypothetical example: scoring a chat widget
For example, suppose a SaaS site loads a chat widget on every page, and the Performance trace shows it as the largest block of third-party main-thread time on mobile. The inventory shows the sales lead owns it and that it earns demo conversations, so removal is off the table.
The chat transcripts show almost every conversation starts on the pricing or demo page. The decision: show a static "Chat with us" button on those two pages that loads the widget on click, and drop it from the blog and docs. Sales keeps every conversation that matters, and the pages that don't need chat stop paying for it.
Why does a tag manager make performance worse over time?
A tag manager doesn't slow a site by itself; it slows a site by making it easy for anyone to add scripts without review. Google Tag Manager is a delivery system, and every tag it fires still runs on your visitor's phone. Without rules, a container becomes a record of every campaign and trial the team has ever run.
The fix is process, not a different tool. Use a naming convention, an owner for each tag, a quarterly cleanup and a rule that new tags get an inventory row before they go live. Our guide to Google Tag Manager setup for startups covers the container structure. If you also check PageSpeed scores, read our explainer on PageSpeed Insights scores versus real-user data first, since lab scores swing with script timing.
How do you stop scripts from creeping back?
Scripts creep back because adding a tag takes two minutes and removing one takes a meeting. Stop it with three habits: an inventory that's the single source of truth, a third-party line in your performance targets, and a scheduled review.
- Gate new tags. No tag ships without an inventory row, an owner and an end date for trials.
- Set a third-party allowance. Agree how much main-thread time third parties may use on key templates, and treat going over it like a failing test.
- Review every quarter. Re-measure, re-ask the "what it earns" question and remove anything expired.
- Watch field data monthly. A sudden INP drop with no code change is often a vendor shipping a heavier script.
If you'd rather hand the whole job over, our guide to website speed optimization services explains what a good engagement includes and what to ask for.
