Are Third-Party Scripts Really Hurting Your Core Web Vitals?

Why is Google specifically highlighting third-party scripts?

Third-party scripts (analytics, advertising tracking, chatbots, social widgets) often account for 50% to 70% of the total JavaScript weight of a page. They run in the main browser thread, blocking rendering and delaying interactivity. This is exactly what Time to Interactive (TTI) measures, a metric that directly influences First Input Delay and now Interaction to Next Paint.

Martin Splitt doesn't mince words: he asserts that placing these scripts at the bottom of the HTML and deferring them reduces TTI interruptions. Specifically, a script loaded at the top of the page halts DOM parsing until it is fully executed. By pushing it to the end of the file with defer, the browser can parse the HTML, build the DOM, and then execute the script — in the order it was declared.

What does the 'defer' attribute actually mean?

The defer attribute instructs the browser to download the script in parallel with HTML parsing, but to execute it only after the document has been completely parsed. This differs from async, which executes the script as soon as it is downloaded, without ensuring order or waiting for the end of the DOM.

For an SEO practitioner, this nuance is critical. A Google Tag Manager script loaded with async may execute before your dataLayer pushes are ready, resulting in missing events. With defer, the execution order remains predictable — but the execution delay increases, which can pose issues for real-time tools.

Does this recommendation apply to all third-party scripts?

No, and that's where the issue lies. Google does not differentiate between a critical script (e.g., an A/B testing system that needs to run before rendering to avoid content flicker) and an optional advertising tracker. Deferring a personalization script or a chat widget could break the user experience if it appears with a 2-second delay.

Splitt's statement remains generic. It assumes all third-party scripts are non-critical, which is rarely true for e-commerce or SaaS sites. An SEO expert must therefore audit each script individually, identify dependencies, and decide on a loading strategy on a case-by-case basis.

• defer guarantees the execution order and executes after complete HTML parsing
• async executes as soon as the script is downloaded, without guaranteeing order or waiting for the DOM
• Placing scripts at the bottom of the HTML reduces rendering blocks, but is not sufficient without defer/async
• Not all third-party scripts can be deferred without risking breaking critical functionalities
• The impact on TTI and INP depends on the number, weight, and execution time of third-party scripts

Is this directive consistent with real-world observations?

Yes, but with a significant caveat. On sites analyzed with WebPageTest and Lighthouse, deferring third-party scripts does improve TTI by 20 to 40% on average — provided these scripts are not critical for initial rendering. The benefit is particularly visible on pages overloaded with advertising trackers (Criteo, Taboola, Facebook pixels).

But here’s the catch: Google says nothing about self-hosted vs. external scripts. A script loaded from a third-party CDN (maps.googleapis.com, connect.facebook.net) incurs additional DNS and TLS latency. Placing it at the bottom of the HTML with defer helps, but the network cost remains unavoidable. In some cases, hosting the script on your own domain with aggressive caching can yield more benefits than mere deferring. [To be verified] on your own PageSpeed Insights data.

What nuances are missing from this statement?

Splitt fails to mention resource hints (preconnect, dns-prefetch, preload). If you defer a third-party script, you lose the benefit of early loading — but nothing stops you from using <link rel="preconnect" href="https://www.googletagmanager.com"> to prepare the DNS and TLS connection while the DOM is being built. Combined with defer, this can reduce execution latency.

He also does not mention the script type="module" with implicit defer. ES6 modules are automatically deferred, making them ideal for modern third-party code. If your stack allows, migrating to modules instead of legacy scripts can simplify load management. But be careful: IE11 does not support them, so this should be evaluated according to your audience.

In what cases does this rule not apply?

Three critical scenarios. First case: anti-flicker scripts for A/B testing. Google Optimize, VWO, AB Tasty need to execute before rendering to hide the original content. Deferring them causes an unoptimized content flash, ruining the experience. Here, we load them blocking, at the top of the head, with a maximum timeout of 500 ms.

Second case: real-time personalization scripts (product recommendations, dynamic price widgets). If the user first sees generic content and then personalized content 2 seconds later, Cumulative Layout Shift will spike. Again, deferring is counterproductive. Third case: scripts that modify the DOM before initial rendering (critical polyfills, CSS-in-JS). Running them after parsing generates reflow and degrades performance instead of improving it.

What should you do to implement this directive in practice?

The first step: audit all your third-party scripts on your site. Open Chrome DevTools, Coverage tab, and reload the page. You will see the exact weight of each script and the percentage of code that is actually executed. Any script with less than 50% coverage is a prime candidate for defer or delayed loading.

Next, categorize your scripts into three groups: critical (must run before rendering), important (necessary but can wait for DOM), and secondary (analytics, advertising). The critical ones stay blocking in the head. The important ones switch to defer at the bottom of the body. The secondary ones are loaded via JavaScript after the window.load event or on scroll, depending on the context.

What mistakes should be avoided during implementation?

A classic mistake: adding defer to an inline script. The defer attribute only works on external scripts with a src attribute. An inline script always executes immediately, regardless of where you place it. If you need to initialize global variables, do it in a deferred external script or use a module.

Another trap: mixing defer and async on scripts that depend on each other. If script B requires a function declared in script A, and A is async while B is defer, you risk a race condition. Keep all interdependent scripts in defer, in the order of declaration, or bundle them into a single bundle.

How can you check that the optimization is really working?

Use WebPageTest with a simulated 3G mobile profile. Compare TTI before and after adding defer. If the gain is less than 10%, your third-party scripts are probably not the bottleneck — look elsewhere (unoptimized images, render-blocking CSS, long JavaScript tasks).

Also monitor Interaction to Next Paint (INP) in Search Console and in Google Analytics 4 via web-vitals events. A declining INP after deferring scripts often signals that a critical script for interactivity has been pushed too late. In this case, roll back or load it conditionally.

• Audit all third-party scripts with Chrome DevTools Coverage
• Add defer to non-critical scripts loaded from an external src
• Place deferred scripts at the bottom of the body, just before the closing </body>
• Use preconnect for third-party domains to reduce DNS/TLS latency
• Test in staging with WebPageTest and RUM before production deployment
• Monitor INP and TTI in Search Console after going live