Isolating one script’s contribution among 15+ concurrent third-party tags requires combining three distinct methods, because none of them alone can attribute causation cleanly: per-script attribution tooling (Chrome DevTools Performance panel and Lighthouse’s third-party audits, which map blocking time to a script’s origin), and controlled removal testing (disabling one script at a time and re-measuring), since field/RUM data on its own is correlational and can’t isolate which of fifteen simultaneous scripts caused a specific slow interaction. The practical method is to use attribution tooling to generate a ranked hypothesis list of likely offenders, then confirm causation for the top candidates with controlled A/B removal, rather than trying to read causation directly out of aggregate field metrics.
Why field data alone can’t isolate individual scripts
CrUX and other field/RUM datasets report Core Web Vitals values (or pass/fail rates) for a page or origin, aggregated across real user sessions. That aggregate number reflects the combined effect of everything running on the page at the time of measurement, including all 15+ scripts, first-party code, and whatever else was happening on that specific device during that specific session. There is no way to decompose a single INP or LCP value after the fact into “X ms from script A, Y ms from script B,” because the metric was never computed per-script in the first place, it’s a single wall-clock measurement of the whole page’s behavior. Correlating a metric’s degradation with a particular script’s deployment date, or its presence/absence across sessions, can produce suggestive patterns, but with 15+ scripts running together, confounding is severe: any two scripts loaded around the same time, or any script whose behavior varies with page type or user segment, will produce confounded correlations that don’t reliably indicate which one is actually responsible.
This is precisely why isolating causation requires either per-script attribution within a single trace (seeing directly, in the call stack, which script executed which blocking task) or controlled variation (removing one variable at a time and observing the effect), rather than relying on aggregate correlational data.
Method 1: per-script attribution via DevTools and Lighthouse
Chrome DevTools’ Performance panel records a trace of everything happening on the main thread, and every long task and function call in that trace has an attributable source (a script URL and, where source maps are available, a specific function). Recent versions of the Performance panel group entries by “third-party” classification, making it faster to see which origins are contributing tasks without manually expanding every call stack. To use this for isolation across many scripts: record a trace covering the interactions and load period of interest, then look specifically at which origins appear repeatedly in long tasks, and for INP specifically, at which script’s code is on the call stack during the input delay, processing, or presentation delay windows of a slow interaction.
Lighthouse (whether run via PageSpeed Insights, the DevTools Lighthouse panel, or the CLI) provides two audits built exactly for this scenario: “Reduce the impact of third-party code”, which lists third-party origins ranked by main-thread blocking time and transfer size, and the third-party summary table, which breaks down total blocking time attributable to each third-party domain across the whole page load. With 15+ scripts, this ranked list is the fastest way to generate a prioritized hypothesis: whichever two or three origins show the highest blocking time are the strongest candidates for the actual INP/TBT contributors, and that ranking is generated directly from attributed trace data, not inference.
It’s worth being precise about what this method proves and doesn’t. It reliably shows how much main-thread blocking time is attributable to each script during the specific page load Lighthouse measured. It doesn’t by itself prove that removing that script would improve the field metric by a corresponding amount, because removing a script can change loading priority and timing for everything that loads after it, and because a single lab run doesn’t capture the variability of real user interaction patterns. That’s the gap the second method closes.
Method 2: controlled A/B removal testing
To confirm that a specific script identified by attribution tooling is actually causing the Core Web Vitals degradation, and to quantify the effect, remove that one script (and only that one) in a controlled environment and re-measure, comparing against a baseline that has all scripts present. This can be done in a few ways depending on available infrastructure:
- Synthetic/lab comparison: run Lighthouse or a scripted Performance-panel trace against two versions of the page, identical except the one script under test is blocked (via request blocking in DevTools, a proxy, or a feature flag), and compare the metrics directly. This isolates the variable cleanly because everything else about the test is held constant, which is the main advantage over field data.
- Field experiment: if the site has the ability to conditionally load a script for only a percentage of real traffic (a feature-flagging or tag-management capability most sites already have via their tag manager), running a genuine holdout comparison in the field, with the script present for one random cohort and absent for another, controls for the natural variability across devices and sessions that a single lab trace can’t represent, and produces a field-measured effect size for that one script’s removal.
- Sequential removal across scripts: with 15+ scripts, testing every single one individually may be more effort than warranted; prioritize the removal tests using the ranked list from Method 1, testing the top few attribution candidates first, and only expanding the test list if the top candidates don’t account for enough of the observed gap.
This combination, attribution tooling to rank candidates, controlled removal to confirm and quantify, is the practitioner-standard approach precisely because it respects what each method can and can’t show: attribution tooling is fast and precise about where main-thread time went in a given trace, but doesn’t run a controlled experiment; removal testing is a genuine controlled experiment, but testing all 15+ scripts exhaustively without first narrowing the field via attribution data is inefficient and often unnecessary.
Practical sequencing
- Capture a representative Performance panel trace and/or PageSpeed Insights report covering the page’s typical load and interaction pattern.
- Use the third-party grouping/summary and the “reduce impact of third-party code” audit to rank scripts by attributed main-thread blocking time.
- Select the top few candidates (rather than assuming the single top-ranked script is solely responsible, since blocking time can be distributed across several scripts without any one dominating).
- Run controlled removal tests, lab-based for speed, field-based (holdout cohort) for a result that reflects real-world variability, for each candidate.
- Quantify the measured effect of removing each script individually, and use that, not the attribution ranking alone, as the basis for prioritizing which vendor relationship or implementation to address first.
The core discipline this method enforces is not treating a ranked attribution list as proof of causation by itself, and not treating aggregate field metrics as capable of decomposing fifteen concurrent scripts’ individual contributions. Attribution narrows the hypothesis space; controlled removal, whether synthetic or field-based, is what actually confirms and sizes the effect.
A worked example of narrowing fifteen scripts down to one
Picture a mid-size SaaS marketing site running eighteen third-party scripts on its pricing page: a chat widget, six analytics/tag-manager-loaded tools, four ad-tech tags, a session-recording tool, and various others. Field data shows INP failing at the 75th percentile around 380ms. A Lighthouse “reduce the impact of third-party code” run ranks the eighteen origins by main-thread blocking time, and three stand out: the session-recording tool at 140ms, one analytics tag at 90ms, and the chat widget at 60ms, with the remaining fifteen scripts each contributing under 20ms. Rather than assuming the top-ranked script is solely responsible, the team runs controlled removal tests on all three: blocking the session-recording tool alone drops simulated INP by roughly 130ms, blocking the analytics tag alone drops it by about 40ms, and blocking the chat widget produces almost no measurable change, since its blocking time turns out to be concentrated during idle periods rather than overlapping real user interactions. The attribution ranking pointed at three candidates; only controlled removal revealed that two of those three actually mattered and the third’s blocking time, despite ranking third-highest, wasn’t landing where interactions happened. The remaining fifteen scripts were never worth testing individually, since even removing all of them together wouldn’t have closed as much of the gap as fixing the session-recording tool alone.
