An ecommerce client came to me with a speed complaint. Their Lighthouse performance score had dropped to 38. What I found in the code review surprised me: the theme wasn’t the problem, but they were loading 14 different third-party scripts. GA, GTM, Facebook Pixel, Google Ads, Hotjar, Intercom, chat widget, review widget, stock plugin, recommendation engine. Each one had been added with a “this is fast” pitch. Combined, the page was downloading and running 38 MB of JS.
The performance hit from third-party scripts gets undersold constantly. Two reasons.
One: the vendor doc says “we add 2ms to your page”. That number is measured on fast networks, with an idle CPU, on an uncontested render. On real devices, mobile over slow 4G, with 15 scripts downloading in parallel, the real cost is more like 300ms.
Two: GTM looks tiny. “Just one GTM script, everything else loads async.” GTM is a loader. The real weight is the n sub-scripts it pulls in, and you can’t see what those are from the outside.
My measurement workflow:
- Open Chrome DevTools Performance tab, filter for Long Tasks.
- Separate scripts coming from third-party origins.
- See who’s blocking the main thread.
- Disable scripts one by one in WebPageTest and remeasure.
Worst three offenders on the client’s site:
- Chat widget: 1.2MB of JS, opens an iframe on every page, loads its own CSS.
- Recommendation engine: 6 API calls per page, each 400 to 800ms.
- Stock plugin: running an A/B test, rewriting the DOM for it, producing layout shift.
The plan we landed on:
1. Is it necessary?
For every script we asked “what do we lose if this goes away?”. Chat widget: they already had a contact email, fine. Intercom: removed, redirected users to email. Review widget: pulling in four reviews a month, not worth the cost, removed. Recommendation engine: 0.3% contribution to conversion rate, removed.
Google Ads pixel, Facebook pixel, GA stayed.
2. Load GTM intelligently
Instead of dropping GTM directly in the head, we wrote a wrapper that loads it on first user interaction (scroll, click, touchstart). Bots can already reach what they need, and users don’t feel the performance hit. Analytics took a small hit (users who bounced before interacting don’t get counted, but they weren’t converting anyway).
3. Consent-based loading
Any script gated behind GDPR consent doesn’t load at all if the user declines. That’s the legal requirement anyway, performance is a bonus.
4. Resource hints
We added <link rel="preconnect"> for the scripts that stayed. Connections to GA and Facebook open early.
5. Fetchpriority and defer
Late-stage scripts got fetchpriority="low". The non-critical ones don’t fight for CPU first.
6. Monitoring
We added real user monitoring. LCP and INP are tracked through Sentry. When a third party ships a version that breaks metrics, we know immediately.
Result: Lighthouse went from 38 to 72, mobile LCP from 5.2 to 2.4. With further theme-side work we got to 85.
One gotcha. With Consent Mode v2, the Google Ads pixel says “collect data even without consent, just anonymise it”. From a performance angle you’re still loading the script, no saving. If you actually want to cut the pixel completely for non-consenting users, you have to hand-roll it.
Third-party scripts are the biggest performance debt on most sites. Remove half of them and no metric changes.