PerformanceJuly 3, 20264 min read

Core Web Vitals: Taming Third-Party Scripts for Performance

Core Web Vitals often tank due to third-party scripts. Learn how we built a performance-first tag management system to keep the main thread responsive.

Core Web VitalsWeb PerformanceJavaScriptThird-Party ScriptsFrontend EngineeringPerformanceWeb VitalsFrontend

When the marketing team added their fifth tracking pixel of the month, our Interaction to Next Paint (INP) score plummeted. We were fighting a losing battle against scripts that assumed they owned the entire main thread, and our users were paying the price with janky, unresponsive interfaces.

It turns out that trying to load everything at once is the fastest way to kill your Core Web Vitals. We had to stop treating tags as "set it and forget it" assets and start managing them like high-risk code deployments.

The Problem with Traditional Tag Management

Our initial approach was standard: dump a container snippet in the <head> and let the tag manager handle the rest. We ignored the reality of third-party scripts executing heavy synchronous tasks during the critical initial load phase.

We saw our main thread blocked for over 800ms during the first few seconds of page load. The browser was so busy parsing tracking pixels and A/B testing frameworks that it couldn't handle user clicks or scrolls. We initially tried simple defer and async attributes, but those only fixed the parsing order; they didn't stop the execution cost once the scripts hit the main thread.

Architecting Execution Guardrails

To fix this, we moved away from hard-coded tags. We built a custom wrapper that acts as a gatekeeper for any third-party library.

Instead of letting scripts fire whenever they pleased, we implemented a system that uses requestIdleCallback to defer non-essential execution. If a tag is non-critical—like a legacy marketing pixel—it waits until the browser is truly idle.

Implementing Dynamic Script Injection

We now dynamically inject scripts only when they are needed. For example, we don't load our chat widget until the user interacts with the "Help" button or scrolls past a certain threshold.


JAVASCRIPT
function loadThirdPartyScript(src, priority = CE9178">'low') {
  if (priority === CE9178">'high') {
    const script = document.createElement(CE9178">'script');
    script.src = src;
    document.head.appendChild(script);
  } else {
    requestIdleCallback(() => {
      const script = document.createElement(CE9178">'script');
      script.src = src;
      document.body.appendChild(script);
    });
  }
}

This simple change allowed us to reclaim roughly 300ms of main-thread performance during the critical load window. It’s not magic, but it creates enough breathing room for the browser to process user interactions immediately.

Performance Budgets and Offloading

You can't manage what you don't measure. We set a strict performance budget for third-party assets, capping them at 150KB of execution time per page. If a new vendor wants to add a script, they have to prove it won't push us over that limit.

When we need to run heavier scripts, we look toward offloading. We've experimented heavily with Partytown to move script execution into Web Workers. This keeps the main thread clear, though it comes with the trade-off of more complex debugging.

Strategy	Performance Impact	Implementation Difficulty
`async` / `defer`	Low	Very Easy
`requestIdleCallback`	Medium	Easy
Sandboxed Iframes	High	Moderate
Web Workers (Partytown)	Very High	Hard

For scripts that absolutely must run but are causing stability issues, we use sandboxed iframes to isolate their DOM access. It stops them from measuring layout shifts unnecessarily, which keeps our Cumulative Layout Shift (CLS) in check.

Why We Still Struggle

Even with these guardrails, we aren't perfect. We still deal with "mystery" spikes where a third-party vendor pushes an update that suddenly consumes more CPU. We’ve started using custom RUM telemetry to alert us when a specific script’s execution time exceeds our defined thresholds.

I'm still not 100% satisfied with our handling of mobile-specific script execution. Some vendors don't provide lightweight versions for mobile devices, and we end up forcing a desktop-sized execution load on a throttled mobile CPU.

If I were to do this again, I’d push harder for server-side tagging earlier in the process. It's the only way to truly remove the execution cost from the client-side main thread. Until then, we keep our guardrails tight and our budgets strict.

FAQ

Does dynamic script injection affect SEO?

Generally, no. Googlebot is quite good at executing JavaScript, but you should ensure that critical content is server-side rendered (SSR) and not dependent on the injected scripts.

Is it worth offloading every script to a Web Worker?

No. The overhead of serializing data between the main thread and a worker can actually hurt performance for small, simple scripts. Use it only for heavy tracking or UI-blocking libraries.

How do I convince stakeholders to cut third-party scripts?

Show them the data. When we tied our bounce rate to our INP scores, the conversation shifted from "we need this feature" to "how can we implement this without hurting performance?"

Back to Blog