The strategy has two distinct phases that get conflated too often: proving the vendor script is actually the cause of INP failure (a technical diagnosis problem), and then getting the vendor to change behavior (an organizational/contractual problem). Skipping the first phase is why most vendor negotiations go nowhere: without per-script attribution data, the vendor’s account team has every incentive to say “it’s not us,” and they’re frequently right, because ad tech stacks routinely include five or six scripts loading simultaneously, plus the publisher’s own code, plus other vendors. You need attribution evidence specific enough that it can’t be waved away, and you need a negotiation ask specific enough that the vendor’s engineering team can actually act on it. Generic pressure (“your script is slow, fix it”) rarely produces a result; a specific, evidenced ask backed by a proposed technical remedy often does.
Technical diagnosis: proving the vendor is the cause
Start in the Chrome DevTools Performance panel, not in field dashboards. Field data (CrUX, or a RUM vendor) can tell you INP is failing, but it can’t by itself tell you which script caused a given slow interaction. Record a session that reproduces the slow interaction (click a nav item, open a menu, type in a search box) with the Performance panel running, and look at the flame chart for the interaction. Chrome’s Performance panel attributes long tasks to their source with a “third-party” grouping/badging in recent versions, and each long task in the flame chart can be expanded to see the call stack, which will show the originating script URL. This is the single most useful artifact in a vendor negotiation: a screenshot or exported trace showing a specific vendor script executing a long task that overlaps with, or directly precedes, the input event’s processing.
Break the INP timeline into its three sub-parts, since the fix differs depending on which one the vendor script affects:
- Input delay: time between the user’s interaction and the browser being able to start handling it. Usually caused by a long task already running when the input occurs (a script executing unrelated work that blocks the main thread).
- Processing time: time actually spent running the event handler(s) triggered by the interaction. Ad scripts that attach global event listeners (for viewability tracking, click tracking) can add processing time directly.
- Presentation delay: time between the handler finishing and the next frame being painted. Layout-triggering DOM writes from a script (resizing an ad slot, injecting content) show up here.
Chrome’s Performance panel, and the Lighthouse/PageSpeed Insights “reduce the impact of third-party code” audit and “third-party summary” table, both attribute main-thread blocking time to individual script origins. Use PageSpeed Insights (lab data, Lighthouse-based) to get a reproducible, shareable report you can hand to a vendor’s technical contact: it lists each third-party origin with total blocking time and transfer size, which is a more portable artifact for a vendor conversation than a raw DevTools trace, even though the DevTools trace is more precise for your own diagnosis.
Do this across multiple real interactions and page states, not one trace. Ad scripts are frequently in one of three states at any moment: idle (script loaded, doing nothing), executing scheduled work (a viewability check on an interval, a bid refresh), or handling a page event, and each state has a different blocking profile. Capture whichever state coincides with your worst INP interactions in the field, since that’s the case you actually need the vendor to fix.
Practical implication: the vendor-negotiation playbook
Once you have per-script attribution evidence, the negotiation itself follows a fairly standard practitioner pattern in ad-ops and web performance circles, though it isn’t a Google-documented process, this half of the answer is operational consensus, not a spec:
Lead with the artifact, not the metric. “Our INP is failing” is not actionable for a vendor’s engineering team. “Your tag executes a 180ms task on the main thread during the first user interaction after load, here’s the trace” is actionable, because it points at a specific piece of their code.
Ask for specific technical remedies, not general improvement. The concrete asks that vendors can typically act on:
- Async or deferred script loading (loading the tag without blocking parse/execution of the rest of the page, and deferring non-critical initialization until after first input or after a browser idle callback).
- Breaking the vendor’s own initialization work into smaller chunks that yield to the main thread, rather than one long synchronous block, mirroring the same task-chunking guidance Google gives publishers directly for their own code.
- An iframe-sandboxed delivery option, if the vendor doesn’t already offer one, so the ad’s script execution and layout thrashing are contained within a separate rendering context rather than sharing the publisher’s main-thread work directly with the rest of the page. Not all ad formats can move to iframe delivery without functional tradeoffs (some rich-media or native-format ads rely on same-document DOM access), so this is a request to evaluate feasibility for the specific product being used, not a universal fix.
- A lighter-weight tag variant if the vendor offers tiered implementations (some ad tech vendors maintain a “lite” SDK with reduced feature sets specifically for performance-sensitive publishers).
Put performance into the commercial relationship, not just the technical one. If the vendor relationship is being renewed or renegotiated, script performance can be written into the agreement as a measurable requirement, similar to how uptime SLAs work: a maximum acceptable main-thread blocking time or long-task duration, measured via an agreed tool (Lighthouse/PageSpeed Insights numbers are the most defensible shared reference since both sides can reproduce them independently), with a remediation timeline if the vendor exceeds it. This is leverage-dependent. A publisher representing meaningful revenue to the vendor has more standing to insist on a contractual performance clause than a small site using a self-serve tag with no account manager; the strategy needs to be calibrated to actual negotiating leverage rather than assumed.
Verify independently after any change. Vendors sometimes ship a change that reduces file size or “improves load time” without actually reducing main-thread blocking time or long-task duration, since those aren’t the same thing. Re-run the same DevTools trace methodology after any vendor-side change before considering the issue resolved, and confirm the improvement shows up in field data (CrUX or your RUM tool) over a full reporting period, not just in a single lab test, since field INP reflects a distribution of real devices and interactions that a single lab trace can’t fully represent.
The overall sequence, then, is: attribute precisely, present evidence specifically, ask for a named technical remedy, formalize the requirement contractually where leverage allows, and verify with the same measurement method used to raise the issue in the first place.
A worked example of turning a trace into a negotiation ask
Picture a mid-size publisher running a header-bidding setup with four demand partners plus a viewability-tracking tag. Field data shows INP failing on article pages, but the account team for each vendor insists their own tag is lightweight. A DevTools trace of a reader tapping “read more” on a related-articles widget shows a 210ms long task overlapping the input event, and expanding the call stack attributes 160ms of it to the viewability tag’s periodic visibility check, not to any of the four bidding scripts. Instead of going back to all five vendors with “your ads are slow,” the publisher takes that trace, plus a PageSpeed Insights third-party summary showing the same viewability tag at the top of the blocking-time table across ten sample URLs, to that one vendor’s technical contact and asks specifically for the visibility check to be deferred until after first input. The vendor ships an update that moves the check to an idle callback; a follow-up trace on the same interaction shows the long task drop to 30ms, and field INP on article pages improves over the next full reporting period. The other four vendors were never the bottleneck, and generic pressure on all five would have wasted the leverage the publisher actually had with the one that mattered.
