More than 90% of pages load at least one third party, and the top 1,000 sites now carry a median of 106 third-party requests on mobile — 15 more than the year before — according to the HTTP Archive's 2025 Web Almanac. Scripts are the largest single slice of those requests at 24.8%.
Almost none of it arrived by decision. It arrived one tag at a time, and nobody owns the total. The cost is measurable: Google's case study library records Vodafone Italy improving LCP by 31% and taking 8% more sales.
This guide is for the person asked to fix Core Web Vitals who cannot unilaterally delete a marketing tag. By the end you will have a five-criterion score for every third party on your site, a routing rule that turns each score into one specific action, and a defensible number for the meeting where someone defends the tag that costs 380ms.
Build the inventory before you score anything
You need two lists; neither is complete alone.
The container list. Export your Google Tag Manager container: tags, triggers and variables with their owners and firing conditions. This is the intent.
The network list. Load the page in Chrome DevTools with cache disabled, then run Lighthouse and read the "Reduce the impact of third-party code" audit. This is what actually executes, including tags injected by other tags, which never appear in a container export.
For every third party on either list, record seven fields:
- Vendor and what it claims to do
- Named business owner (a person, not a department)
- Script transfer size
- Main-thread blocking time attributable to it
- Whether it sits on the critical path to the LCP element
- Which page templates it fires on
- The last time anyone made a decision using its data
That last field is the one people skip, and the one that closes the most arguments. Score against field data: Core Web Vitals are assessed at the 75th percentile of real page loads, and a lab run on a fast connection flatters your stack.
The five scoring criteria
Score each third party 0–3 on all five. Higher totals mean stronger grounds for removal.
| Criterion | 0 points | 1 point | 2 points | 3 points |
|---|---|---|---|---|
| Main-thread cost | Under 50ms | 50–150ms | 150–350ms | Over 350ms |
| Critical-path position | Fires after load, off the path | Async, no effect on LCP | Delays the LCP element | Render-blocking in <head> |
| Demonstrated use | Drives a decision weekly | Monthly reporting only | Someone opens it quarterly | No named use in 90 days |
| Replaceability | No substitute exists | Vendor SDK is the only option | Facade or lazy-load is possible | Native, server-side or first-party equivalent exists |
| Consent dependency | Strictly necessary, no consent | Consent needed, loads after grant | Consent needed, loads default-denied | Consent needed and gates other tags |
Two overrides sit on top of the total:
- A 3 on Demonstrated use routes to Kill regardless of total. No cost is worth paying for a tag nobody uses.
- A 3 on Critical-path position routes to at least band 3. A render-blocking script in the head is structural, however valuable the vendor.
Routing table
| Total | Action | Sign-off needed |
|---|---|---|
| 0–3 | Keep. Re-score in six months | None |
| 4–6 | Defer or lazy-load | Engineering |
| 7–9 | Replace with a facade, or load conditionally by route, geo or consent state | Engineering plus tag owner |
| 10–12 | Move server-side, or replace with a first-party equivalent | Analytics owner |
| 13–15 | Kill. Present the score, not an opinion | Tag owner's manager |
Within a band, the Replaceability score picks the tactic: a 3 there means a first-party or server-side equivalent exists, so take that route rather than the band's default.
The sign-off column matters because each band names one person. "The site is slow because of tags" is a complaint. "This tag scored 11, here is who signs it off" is a ticket.
A worked example
A composite mid-market e-commerce checkout. Not client data; the numbers are illustrative.
| Tag | Cost | Position | Use | Replace | Consent | Total | Route |
|---|---|---|---|---|---|---|---|
| Live-chat widget | 3 | 2 | 0 | 2 | 1 | 8 | Facade: load on click |
| Legacy heatmap tool | 2 | 1 | 3 | 3 | 2 | 11 | Kill (Use override) |
| Ad conversion tag | 1 | 1 | 0 | 3 | 2 | 7 | Move server-side (Replaceability 3) |
| Consent management platform | 1 | 3 | 0 | 1 | 0 | 5 | Band 3 (Position override): audit its blocking behaviour |
| Font provider | 1 | 2 | 0 | 3 | 0 | 6 | Self-host and subset (Replaceability 3) |
The chat widget is the instructive row. It is genuinely used and not replaceable, and it still routes to a facade, because the rubric separates "do we need this" from "do we need it in the first 2.5 seconds".
[INTERNAL DATA NEEDED: replace this composite table with a real anonymised inventory from a Switas engagement — vendor category, measured blocking time, post-change field metric.]
The three fixes, ranked by how often they actually work
Facades. Replace an embed with a static placeholder that loads the real widget on interaction. Chat, video, maps and review widgets are the usual wins. It is the highest-yield fix in most audits because it removes the cost without removing the feature, which is why it survives the meeting.
Deferring. Useful, with caveats. Chrome lowers the network priority of async and defer resources, so they load later than you expect — fine for a pixel, not for anything that renders. web.dev also notes embeds "can block window.onload if their servers respond slowly, even if the embed is using async or defer." Deferring moves the cost; it does not always remove it.
Server-side tagging. This needs a correction, because it is sold as a page-speed product and is not one. Google's own introduction to server-side tagging describes data ownership, shaping and routing — "only you have access to the data in the server until you choose to send it elsewhere" — and makes no performance claim. The browser still runs measurement code and still transmits events, via image pixel, fetch, XHR or a service worker served from your server container domain.
What it buys is first-party context and control over what leaves your infrastructure. Any speed gain is a side effect of the vendor scripts you remove while migrating. If a vendor promises an INP improvement from server-side tagging alone, ask which script stops loading in the browser; if the answer is none, there is no improvement. INP is composed of input delay, processing duration and presentation delay, and scripts inflate the first two by occupying the main thread. Changing where a request is sent affects neither.
Where the consent layer changes the arithmetic
Your consent management platform is usually the highest-scoring item in the inventory: it sits in the head, it is render-blocking by design, and every other tag waits on it. Score it like anything else.
Then decide which consent mode you run, because the two have different performance profiles. In Google's terms, basic consent mode means tags are "blocked until user interaction with a consent banner", while advanced mode "loads with defaults set to denied" and sends cookieless measurements before consent. Basic is faster on the initial load. It also costs you data: Google's EEA guidance warns that if you prevent tags from loading until banner interaction, "Google won't be able to verify user consent choices and this may lead to loss in data."
Here a regional detail earns its place. Turkey is not in the EEA, so Google's EEA consent-signal requirement does not reach Turkish traffic — but Turkish law does. The KVKK's guide on cookie practices treats analytics cookies as requiring explicit consent rather than strictly necessary, requires consent categories unchecked by default and "Reject All" as prominent as "Accept All", and prohibits cookie walls.
The practical consequence for a Turkish or multi-market retailer: run basic consent mode on Turkish traffic and advanced on EEA traffic, and you lose nothing you were entitled to in either market. Most CMPs will not do this out of the box. It is a geo-scoped configuration decision, not a plugin.
What this rubric does not cover
- It scores tags, not pages. A tag that is harmless on the homepage can be ruinous on a listing page loading forty of them.
- Main-thread cost is not additive. Removing five 100ms tags rarely returns 500ms. Measure after every change.
- It ignores your own code. Long tasks from framework hydration are often the larger share of a bad INP, and no third-party audit will find them.
- It only gives you the cost side. A 380ms tag driving real attributable revenue may be worth keeping.
- It has no opinion on security or data residency, sometimes the actual reason a vendor should go.
- Piggybacked tags hide from container exports. Where the two lists disagree, trust the network list.
FAQ
How do I measure main-thread cost for one specific third party? Use the Chrome DevTools Performance panel to attribute long tasks to script origins, and cross-check with the Lighthouse "Reduce the impact of third-party code" audit. Confirm against field data, because a lab run understates the real cost.
Does server-side tagging improve Core Web Vitals? Not on its own. Google's documentation for server-side tagging describes data control and routing, not page speed, and the browser still loads measurement code and transmits events. Any improvement comes from vendor scripts you remove from the page as part of the migration.
Which Core Web Vital do third parties damage most? Usually INP, because scripts occupy the main thread and inflate input delay and processing duration. Render-blocking tags in the head hit LCP instead, and late-injected banners or widgets hit CLS.
Should I self-host third-party scripts? Sometimes, but it is a trade. Self-hosted copies stop receiving vendor API changes and security fixes until you update them manually, which web.dev flags as a revenue and security risk.
What should I be aiming for? At the 75th percentile of real page loads: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1.
Do I need Google consent mode if my traffic is mostly Turkish? Google's EEA consent-signal requirement does not apply to Turkish traffic, but KVKK's cookie rules do, so you still need a working consent mechanism. What changes is that you are freer to choose the faster basic implementation for that segment.
How often should this be re-scored? Quarterly for the full inventory, and at any release that adds a vendor. Tag stacks regrow: the Web Almanac's year-on-year figures show third-party request counts rising.
What do I do when the tag owner refuses? Send the score and the band, not the argument. The rubric exists so the conversation is about a number and a named action rather than whose priority wins.
If your checkout or listing pages are failing Core Web Vitals and you cannot say which vendor is responsible, run this rubric on your own stack — or have us run it, with field data and a prioritised backlog, through Switas web performance services.
Sources
- Third Parties — 2025 Web Almanac, HTTP Archive
- Web Vitals — web.dev
- Interaction to Next Paint (INP) — web.dev
- Loading third-party JavaScript — web.dev
- The business impact of Core Web Vitals — web.dev case studies
- Server-side tagging introduction — Google Tag Platform
- Send data to a server container — Google Tag Platform
- Consent mode concepts — Google Tag Platform
- Updates to consent mode for EEA traffic — Google Ads Help
- KVKK Çerez Rehberi compliance roadmap — Mondaq (analysis of the Authority's 61-page guide; kvkk.gov.tr was unreachable at the time of writing)
