Third-Party Script Cost

## Why attribution has to be per origin Third-party cost is invisible to the tools that measure your own code. The script was never in your build, so a bundle report cannot see it; it is fetched at runtime from hosts you do not control. The unit that does work is the origin (scheme plus host plus port), because that is what every measurement surface can group by and what you can switch off in an experiment. ## Step 1: inventory the bytes and requests Resource Timing gives you every subresource the page fetched, with its URL, duration and transfer size, so you can total them per origin from the page itself: ```js const byOrigin = {}; for (const e of performance.getEntriesByType('resource')) { const key = new URL(e.name).origin; const s = (byOrigin[key] ??= { count: 0, bytes: 0, ms: 0 }); s.count += 1; s.bytes += e.transferSize; s.ms += e.duration; } console.table(byOrigin); ``` One trap matters here: for a cross-origin response, size and detailed timing fields are zeroed unless the server sends a `Timing-Allow-Origin` header, and vendors frequently do not. So `transferSize` for exactly the origins you care about is often 0. When that happens, take the byte figures from the browser's network log (or a synthetic run) instead, and use Resource Timing for the request count and the origin list. Also record how many distinct origins the vendor drags in. One approved tag pulling from four hosts means four connection setups and four vendors you never reviewed. ## Step 2: attribute main-thread time Bytes are the easy half; the expensive half is execution. Record a performance profile of the page load plus a representative interaction, then group the flame data by script URL rather than by function, so all the time under the vendor's scripts collapses into one number. A Lighthouse run produces the same view for you as a third-party summary listing each entity with its transfer size and main-thread blocking time, which is usually the single most quotable artefact for a non-engineer. In the field, Chromium's Long Animation Frames API reports long frames together with the scripts that ran in them, including a source URL, so you can attribute real users' slow frames to a vendor rather than guessing. Support is Chromium-only, so treat it as a strong signal from part of your traffic, not a census. ## Step 3: the removal experiment Everything above tells you what the vendor consumes. Only removal tells you what the page gains, because costs interact: a script that occupies the main thread while nothing else needs it may cost far less than its raw milliseconds suggest, and a script that lands exactly during hydration may cost far more. In the lab, block the vendor's domains in the browser's network panel or your synthetic tool, then run the identical scripted journey with and without, several times, and compare medians. In the field, run a holdback: for a small percentage of sessions, do not load the vendor, and compare Core Web Vitals at the 75th percentile between the two groups. A holdback is also the only honest way to measure the other side of the ledger, which is whether the vendor's business value survives its absence. ## Reporting it so a decision can happen The output should fit in one table and one sentence. Something like: this vendor loads 11 requests from 3 origins, 210 KB transferred, 480 ms of main-thread time on a mid-tier phone, and blocking it improves p75 LCP by 0.4 s and p75 INP by 90 ms. That is a number a product manager can weigh against the vendor's contribution. Two honesty rules keep the exercise credible. Measure on hardware and networks like your users', not a developer laptop on office wifi, because third-party execution cost scales with CPU. And separate the cost of loading from the cost of running: a widget with modest load cost but a document-level listener on every interaction shows up in interaction latency, not in load metrics, and you must look there to find it.