Skip to content

Reducing Third-Party Script Weight: The Audit Pattern That Saves Half Your JS Budget

Third-party scripts are where bundles really go to die. Here’s the audit and the policy.

John Cravey with EleviFounder4 min read

Every SMB site we audit has 5-15 third-party scripts running in the browser: analytics, chat widgets, ad pixels, tag managers, email-capture popups, social-proof widgets, A/B test platforms. Each one adds JavaScript to the page; collectively they often double the site’s total JS weight. The owner-team rarely knows what’s running. Here’s the audit pattern we run and the third-party-script policy we enforce on FH client sites.

Step 1: take inventory

Open Chrome DevTools → Network → JS filter. Reload the page. List every JS file from a domain other than your own. For a typical SMB site we audit, this list is 8-15 entries. Most aren’t justifiable when you actually look at each one.

The common offenders

  • Google Tag Manager loading 10 child tags, half of which are obsolete.
  • Chat widgets (Intercom, Drift, Tidio): 200-500KB each.
  • Analytics (GA4 + Facebook Pixel + LinkedIn Insight + Hotjar + ...): 30-80KB each.
  • A/B test platforms (Google Optimize legacy, VWO, Convert): 50-150KB each.
  • Social-proof popups (Proof, Fomo): 30-80KB.
  • Form-builder embeds (Typeform, JotForm): 100-300KB.
  • Calendar embeds (Calendly): 200KB.
  • Video embeds (YouTube): heavy on initial load.

Step 2: classify each script

For each script, three questions:

  1. What does this actually do for the business right now?
  2. Is it producing measurable value? (Tracked conversions, captured leads, etc.)
  3. Could we get the same value with less weight or with a server-side equivalent?

Step 3: remove the dead ones

Every audit finds at least one script that’s no longer used. A Facebook Pixel installed for a campaign that ended 18 months ago. An old A/B testing tool. A chat widget from a vendor the client doesn’t pay for anymore. These are pure cost. Remove them.

Step 4: defer the rest

Anything that doesn’t need to fire on initial page load should be deferred.

  • Chat widgets: lazy-load on first scroll past 50%, or after 5 seconds idle.
  • Email-capture popups: same.
  • Analytics: load with `strategy="afterInteractive"` in Next.js Script component.
  • Tag manager: the same.
  • Video embeds: load only when the user actively starts the video.
// Deferred chat widget
import Script from "next/script";

export function ChatWidget() {
  return (
    <Script
      src="https://widget.intercom.io/widget/APP_ID"
      strategy="lazyOnload"
    />
  );
}

Step 5: replace heavy with light

  • Calendly embed (200KB) → link to your Calendly URL (0KB).
  • Typeform embed (200KB) → native HTML form + server action (0KB extra).
  • YouTube embed → lite-youtube-embed (3KB) or static thumbnail link.
  • Hotjar / FullStory (heavy) → smaller alternative (Microsoft Clarity is free and 10x lighter).
  • GA4 + GTM + Pixel + LI Insight + ... → consolidate via server-side conversion firing (see SSTagging post).

Step 6: write a policy and enforce it

After the audit, document a third-party script policy. ‘New third-party scripts require a documented business justification and a measurement plan for value.’ Without this, the script count grows back to its original size within a year of every audit.

The hidden cost of third-party scripts

  • Initial JS weight (the obvious one).
  • Main-thread blocking on parse — even a deferred script blocks the main thread when it eventually runs.
  • Third-party domain DNS lookups + TCP handshakes — every new domain adds 30-100ms.
  • Failed scripts that retry forever in the background.
  • Privacy and consent overhead — every third-party script needs disclosure under GDPR/CCPA/AIA.
  • Failure modes: a third-party CDN being slow makes your site appear slow.

Server-side alternatives when they exist

Conversion tracking can move server-side (server actions firing to GA4 MP API and Meta CAPI). Email capture can use native HTML forms. A/B testing can run at the edge with Cloudflare Workers. Many third-party use cases have lower-weight server-side alternatives in 2026.

The before/after on a recent FH audit

One FH client site (pre-engagement): 14 third-party scripts, 1.8MB of total JS, LCP 3.4s. After audit + remediation: 4 third-party scripts (GA4, Cloudflare Turnstile, Cookiebot, Plausible), 380KB total JS, LCP 1.4s. The audit identified $0/month of value being produced by 10 of the 14 scripts. Removal saved 2 seconds of LCP and zero dollars of marketing performance.

How this lands across FH client work

Every FH client engagement starts with a third-party script audit. Median outcome: 40-60% reduction in third-party script weight. Conversion-tracking moves server-side; chat widgets get deferred or removed; analytics gets consolidated. The result is a site that loads faster, costs less to serve, and remains compliant with privacy regulation. If your site has more than 5 third-party scripts and you’re not sure they all earn their place, book a consultation — the audit is a half-day engagement with measurable performance lift.

Written by
John Cravey
Founder

Founder of Frontend Horizon. Writes most of the long-form work on the FH blog.

Newer post
Migrating from Firebase to Supabase: The Real Cost and the Step-by-Step Plan
Older post
Schema Markup for SMB Sites: The Three Types That Actually Help
Keep reading

More from the blog

Next.js·6 min

Next.js 16.1 in Production: The Migration Playbook We Run on Every FH Site

Next 16.1 is the lean target. Here’s the exact migration we run, what breaks, and what to delete after.

Professional Services·2 min

The Professional Services Growth Playbook, by Firm Size

Same fundamentals, different scale. The right move for a solo practice is the wrong move for an enterprise firm, and vice versa.

AI·4 min

Anthropic API Prompt Caching: The Pattern That Saves Thousands on Content Generation

Prompt caching cuts our content-gen costs by an order of magnitude. Here’s how and where it works.