You know third-party scripts are hurting your Core Web Vitals. You have 18 of them loading on every page. Your executive team wants to know which ones to remove. Removing all 18 and measuring the improvement does not help — you need to know the individual contribution of each tag so you can make a data-driven business case for removing or replacing specific vendors. The diagnostic challenge is that third-party scripts interact with each other and with first-party code in ways that make simple A/B removal testing unreliable. A systematic isolation methodology is required.
The Attribution Approach: Long Animation Frames API for Per-Script Measurement
The Long Animation Frames API (LoAF) reports every frame that exceeds 50ms duration and attributes the execution time to specific script URLs through the scripts property of each PerformanceScriptTiming entry. Each entry includes the sourceURL identifying which script file contributed to the long frame, the duration measuring how long that script’s contribution lasted, and the invokerType indicating what triggered the script execution (user-interaction, classic-script, module-script, or event-listener). By collecting LoAF data in RUM across real user sessions, you can aggregate main-thread time per third-party script domain without removing any scripts or modifying any code.
The implementation collects LoAF entries using a PerformanceObserver, groups script entries by their source domain (extracting the eTLD+1 from each sourceURL), and sums the execution durations per domain across the page session. The script domain with the highest cumulative main-thread time is the largest INP contributor. DebugBear’s LoAF analysis tools break down the longest LoAF script for the INP interaction by script domain and by individual script URL, providing both high-level domain attribution and granular file-level detail (debugbear.com, 2025).
const scriptImpact = {};
new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
for (const script of entry.scripts) {
const domain = new URL(script.sourceURL).hostname;
scriptImpact[domain] = (scriptImpact[domain] || 0) + script.duration;
}
}
}).observe({ type: 'long-animation-frame', buffered: true });The attribution approach has a critical advantage: it operates passively and produces results from real user sessions without any experimental intervention. It measures each script’s actual main-thread cost during real interactions on real devices, capturing conditions that lab testing cannot reproduce. The web-vitals library (version 4+) includes intersecting LoAF entries in the INP attribution interface, making it straightforward to correlate specific scripts with specific INP values.
Limitation: LoAF script attribution is subject to same-origin restrictions. Cross-origin scripts loaded without the crossorigin="anonymous" attribute may report only a sourceURL without function-level detail. Adding crossorigin="anonymous" to third-party script tags enables more detailed attribution, though some vendors’ scripts may not support CORS headers on their CDN. Position confidence: Confirmed through Chrome developer documentation and the LoAF API specification.
The Removal Testing Approach: Sequential Tag Disabling
For causal impact measurement rather than correlational attribution, systematically disable one third-party tag at a time using the tag manager and measure CWV changes in the field over a 7-14 day testing period per tag. This approach directly measures the CWV improvement from removing a specific tag, providing the strongest evidence for removal decisions.
The implementation requires:
- Establish a baseline: measure CWV metrics for the target pages over a 14-day period with all tags active. Record LCP, CLS, and INP at the 75th percentile from RUM data.
- Disable one tag: using the tag management platform (Google Tag Manager, Tealium, Adobe Launch), pause or remove a single tag while keeping all other tags active.
- Measure the delta: collect CWV data for 7-14 days with the tag disabled. Compare 75th percentile values against the baseline period.
- Re-enable and repeat: restore the disabled tag and move to the next tag in the testing sequence.
The sequential approach requires sufficient traffic volume for RUM to produce statistically significant results within each testing period. Pages with fewer than 10,000 monthly page views may need longer testing periods to achieve reliable measurement.
The critical limitation is interaction effects between tags. Removing Tag A may not improve INP because Tag B fills the freed main-thread time. Multiple tags competing for the same main-thread windows create a shared bottleneck where removing one tag redistributes the available time to remaining tags rather than freeing it for user interactions. Sequential removal testing tends to underestimate individual tag impact when multiple tags compete for overlapping main-thread windows. Conversely, if two tags interact adversely (one tag triggering expensive behavior in another), removing one may produce larger improvements than its standalone attribution suggests.
The Request Blocking Approach: Lab-Based Impact Profiling
Chrome DevTools’ Network request blocking feature allows blocking individual third-party domains during a Lighthouse or WebPageTest run. Block one domain at a time and compare lab CWV metrics against the all-scripts-enabled baseline. This approach provides rapid, per-tag impact estimates without requiring production changes or waiting for field data accumulation.
The workflow:
- Open Chrome DevTools, navigate to the Network panel, right-click and select “Block request domain.”
- Enter the third-party domain to block (e.g.,
*.google-analytics.com). - Run a Lighthouse performance audit or a manual performance recording of a user interaction.
- Record the LCP, TBT (as INP proxy), and CLS values.
- Unblock the domain, block the next third-party domain, and repeat.
WebPageTest offers a more automated version through its block parameter, which accepts a list of domains to block during the test. Running parallel tests — one baseline and multiple variants each blocking a different domain — produces a complete per-tag impact matrix in a single testing session.
The lab approach provides directional guidance but has significant limitations. Third-party scripts behave differently in lab environments: ad scripts serve test creatives or empty containers instead of production ad campaigns, A/B testing scripts may not evaluate variants for non-cookied lab requests, analytics scripts may detect bot traffic and reduce their execution, and consent-dependent scripts do not load because lab tests do not accept cookie consent. Lab results systematically underestimate the field impact of third-party scripts because the lab does not reproduce the full production execution behavior.
The Tag Manager Timing Approach: Measuring Tag Execution Duration
Google Tag Manager’s custom event triggers and the Performance API’s performance.mark() and performance.measure() methods can wrap each tag’s firing in precise timing measurements. For each tag in the container, add a firing trigger that creates a performance mark before the tag fires and another after it completes, then measure the interval.
// Custom HTML tag wrapper in GTM
performance.mark('tag_analytics_start');
// ... original tag code ...
performance.mark('tag_analytics_end');
performance.measure('tag_analytics', 'tag_analytics_start', 'tag_analytics_end');Aggregating these measurements across user sessions produces a per-tag execution time distribution. Combined with the tag’s firing frequency (how many times it executes per page view — once for initialization tags, repeatedly for polling tags), this produces an estimated total main-thread time per tag per session.
The caveat is that performance.measure() captures only synchronous execution time within the measured interval. Asynchronous callbacks triggered by the tag — fetch responses, setTimeout handlers, requestAnimationFrame callbacks — execute outside the measurement window and are not captured. Tags that do minimal synchronous initialization but spawn heavy asynchronous work will appear lightweight in this measurement while contributing significantly to main-thread contention. LoAF attribution captures this asynchronous work because it measures frame-level execution regardless of how the work was triggered.
Building the Business Case: Cost-per-Millisecond-of-Main-Thread-Time
Once per-tag impact is quantified through one or more of the approaches above, the business decision requires comparing each tag’s business value against its performance cost. The comparison framework:
Quantify each tag’s business contribution: analytics tags provide data for business decisions (value: high, but difficult to dollarize). Ad tags generate measurable revenue per page view. A/B testing tags produce conversion lift data. Chat widgets generate leads or support deflections. Assign a dollar value or business-criticality rating to each tag.
Quantify each tag’s performance cost: express the cost as main-thread milliseconds per page session (from LoAF attribution) and as the estimated INP contribution at the 75th percentile (from removal testing or attribution modeling). Convert to business impact by estimating the organic traffic and revenue at risk from INP failure caused by the tag’s main-thread cost.
Present as a scatter plot: plot business value on the Y-axis and main-thread cost on the X-axis. Tags in the high-cost/low-value quadrant are immediate removal candidates. Tags in the high-cost/high-value quadrant are vendor negotiation candidates for lighter implementations. Tags in the low-cost/high-value quadrant are keepers. Tags in the low-cost/low-value quadrant are low-priority removal candidates.
SpeedCurve’s LoAF monitoring features enable this analysis by providing per-script domain breakdowns that map directly to vendor identities, making the business case construction straightforward for teams using their platform (speedcurve.com, 2025).
Limitations: Interaction Effects and Non-Additive Impact
Third-party tag impact is not additive. Removing three tags that each consume 50ms does not guarantee 150ms of INP improvement, because the tags may not have been executing concurrently during interactions. Their main-thread work may have been distributed across different time windows, with only some windows overlapping with user interactions. The tags’ execution timing relative to user interactions determines their INP contribution, not their absolute main-thread consumption.
Additionally, some tags have dependency relationships: removing a tag manager may also remove all tags it loads, and removing a consent management platform may change which other tags fire. These dependencies mean that individual tag impact measurements do not compose linearly into aggregate predictions.
The only way to confirm the actual INP improvement from removing specific tags is measuring field INP before and after removal. Per-tag attribution provides the prioritization framework for deciding which tags to investigate and potentially remove. Field validation after removal provides the definitive impact measurement. The attribution data guides the decision; the field data confirms the outcome.
Can Chrome DevTools’ request blocking feature accurately simulate removing a third-party script?
Partially. Request blocking in DevTools prevents the script from downloading, which eliminates its parse, compile, and execution costs. However, it does not account for error handling paths that execute when the script fails to load (try/catch blocks, fallback logic), and it does not simulate the behavioral changes that result from missing functionality (broken analytics, non-functional ad slots). The CWV measurement after blocking reflects the performance ceiling, not the exact real-world improvement.
Does the Long Animation Frames API attribute main-thread time to the correct third-party script when scripts load through a tag manager?
Yes, with one important nuance. LoAF attributes execution time to the actual script source URL, not the tag manager container. A Google Analytics script loaded through GTM is attributed to the Google Analytics source file, not to the GTM container. However, the GTM container’s own evaluation logic (trigger processing, variable resolution) is attributed to the GTM source, making it possible to distinguish between the tag manager’s overhead and individual tag execution costs.
Should third-party tag impact be measured in lab or field conditions?
Both, for different purposes. Lab measurement (using request blocking and Performance Panel profiling) provides controlled, reproducible attribution data for individual tags. Field measurement (using LoAF and RUM) captures the real-world interaction between all tags running simultaneously, including timing collisions that lab tests cannot reproduce. Lab data guides which tags to investigate; field data validates whether removing or optimizing a tag produces a measurable CWV improvement.
Sources
- https://developer.chrome.com/docs/web-platform/long-animation-frames
- https://www.debugbear.com/blog/long-animation-frames
- https://www.speedcurve.com/blog/long-animation-frames-support/
- https://www.debugbear.com/blog/inp-attribution-data-missing
- https://requestmetrics.com/web-performance/long-animation-frame-loaf/
