Loading a script with async or defer only changes when the browser downloads and parses it relative to page construction; it does nothing to change what happens once that script actually executes. Once a third-party script runs, its code competes for the same single main thread that handles your own JavaScript, style recalculation, layout, and paint, and critically, the thread that has to respond to user input. This is the core “async doesn’t mean free” misconception: async/defer solve a loading-order problem, not an execution-cost problem, so a third-party script can load asynchronously and still directly cause INP failures by occupying the main thread exactly when a user clicks, taps, or types.
Why async/defer don’t stop main-thread contention
The browser’s main thread is a single, shared resource. It runs your application’s JavaScript, executes any third-party tags (analytics, ad tech, chat widgets, tag managers, A/B testing tools), computes style and layout, and paints frames, all on that one thread, one task at a time. async tells the browser it can download the script without blocking HTML parsing and execute it as soon as it’s ready; defer tells the browser to execute it after HTML parsing completes but before DOMContentLoaded. Both attributes are about download/parse scheduling relative to the rest of page construction. Neither attribute puts the script’s actual execution on a separate thread, throttles how much main-thread time it’s allowed to consume, or defers its execution away from moments when the user is trying to interact.
This matters specifically for INP because INP is measured from the moment of user interaction (a click, tap, or keypress) through input delay, processing, and presentation delay until the next paint. If a third-party script happens to be mid-execution, or a timer/callback it registered fires, at the exact moment the user interacts, the browser cannot start processing that input until the current main-thread task finishes. A long task from a third-party script, whether it loaded synchronously or asynchronously, blocks input processing identically once it’s actually running. Many third-party tags also register their own event listeners, timers, and periodic work (tracking pixels re-firing, ad auctions re-running, chat widgets polling) that create ongoing background main-thread work throughout the page’s lifecycle, well after the initial async load completed, and any of that work can collide with a real user interaction at any point in the session.
The browser’s task scheduling model makes this worse than intuition suggests. JavaScript on the main thread runs to completion once started; the browser cannot forcibly pause a running task partway through to service a higher-priority input event. If a third-party script structures its work as one large synchronous function rather than breaking it into smaller chunks yielded back to the browser (for example, via setTimeout, requestIdleCallback, or the newer scheduler APIs), the entire block counts as a single long task from the browser’s scheduling perspective, and any interaction that occurs during it experiences the full remaining duration as input delay. This is why two third-party scripts with similar total execution time can produce very different INP impact: the one that self-interrupts into smaller yielded chunks lets queued input get processed between chunks, while the one that runs as one monolithic task blocks input for its entire duration regardless of when in that window the user happened to click.
It also helps to distinguish first-load execution cost from ongoing cost, since teams frequently audit only the former. A tag manager or analytics suite typically does the bulk of its setup work once, shortly after it loads, which shows up clearly in a Lighthouse run or a page-load trace. But many of these same scripts continue running after that initial burst: mutation observers watching the DOM for changes, periodic beacons, session-replay tooling capturing every interaction and DOM mutation, and rotating ad creative all execute at arbitrary points later in the session. A synthetic Lighthouse audit, which typically simulates a single page load and a scripted set of interactions, can substantially understate this ongoing cost, because the real-world INP impact of a chat widget’s background polling might only become visible after several minutes of actual browsing, well past when a typical lab test stops measuring.
Diagnosing and reducing third-party INP impact
Diagnose before optimizing: use Chrome DevTools’ Performance panel with its “third-party” grouping, or Lighthouse’s “reduce impact of third-party code” and “third-party summary” audits, both of which attribute main-thread blocking time to specific scripts/domains rather than lumping all script cost together. This tells you which specific vendors are actually the problem, since not all third-party scripts are equally expensive, and guessing wastes effort on the wrong target.
For scripts confirmed to cause main-thread contention, consider: sandboxing them in an iframe where feasible (isolates their execution and layout from the main document, though this isn’t possible for every integration type), requesting or configuring lazy/on-interaction loading for non-critical widgets (chat widgets, non-essential trackers) so they don’t compete for main-thread time until actually needed, and auditing whether every currently-loaded third-party script is still delivering enough value to justify its ongoing execution cost, since tag sprawl accumulates over time and rarely gets pruned.
If you control the loading logic and a tag manager sits in front of most of your third-party scripts, look at the order and grouping in which tags fire. Firing a dozen tags in immediate succession on page load, even asynchronously, tends to produce a cluster of long tasks close together, which raises the odds that a user’s first interaction lands inside one of them. Deliberately staggering non-essential tags, or gating them behind a first-interaction or idle-time trigger using requestIdleCallback, spreads that execution cost into moments when the user isn’t actively trying to interact, which doesn’t reduce total script cost but does reduce how often it collides with a real click or tap.
Distinguish one-time setup cost from ongoing cost when you diagnose, since the fix differs for each. If the problem is a heavy initialization routine, deferring or chunking that one routine solves most of it. If the problem is ongoing background work (polling, periodic beacons, mutation observers), the fix has to target that recurring behavior specifically, for example, reducing polling frequency or asking the vendor whether it’s configurable, since removing the initial load delay does nothing for cost that recurs throughout the session. Field data over a longer session window, not just an initial-load Lighthouse trace, is usually necessary to catch this distinction.
Where you have contractual or vendor-relationship leverage, push for async/deferred and lightweight implementations from the vendor itself (some ad-tech and analytics vendors offer lighter-weight tag variants), since the underlying fix for execution-time cost has to happen in the vendor’s code, not in how your page requests it. When evaluating new third-party additions going forward, it’s worth treating main-thread cost as a first-class criterion alongside whatever functional value the tag provides, rather than only discovering the cost after it’s already been added to every template site-wide.
