Too many third-party scripts

A new origin means a full connection setup: DNS resolution, TCP handshake, TLS negotiation. On a slow mobile connection that is frequently several hundred milliseconds before the first byte.

The download itself, which for a chat widget or a heat-mapping library is often larger than the page's own JavaScript.

Execution on the main thread, competing with the page's own work and with responses to user input.

Further requests. A tag manager is a loader: it fetches other scripts from other origins, each repeating the connection cost, and the total is invisible until you look at the waterfall.

And an availability dependency. A third-party host that is slow today makes your page slow today, and a blocking third-party script that fails to load can stop the page rendering at all.

A tag manager exists so that marketing can add tags without a deployment. That is a real organisational benefit and it has a direct technical consequence: nobody reviews what gets added.

Tags accumulate. A pixel for a campaign that ended, a survey tool used once, two analytics platforms because a migration was never finished.

Because they are added through an interface rather than a repository, they are outside code review, outside the bundle-size budget, and outside most performance monitoring.

The practical consequence is that the largest performance regression on many sites arrives without a commit, and nobody can say when it started.

The remedy is periodic review with a simple question per tag: who looked at this output in the last six months? A tag nobody reads is pure cost.

In the Network panel, group requests by domain. Everything not on your own origin is third party, and the total transferred is the first number.

In the performance panel, look at main-thread activity attributed by origin. Download size and CPU time are not proportional — a small script that runs a lot can cost more than a large one that runs once.

Block them and compare. The browser's request-blocking feature lets you block an origin and reload; the difference in the load timeline is that script's real cost.

Check what each one loads in turn. A single tag-manager request that expands into fifteen is the measurement people are most often surprised by.

Defer everything that is not needed before the page appears, which is almost all of it. Analytics that runs after the first paint loses nothing.

Preconnect to the origins that do have to load early, so the connection cost overlaps with other work instead of following it.

Self-host where the licence and the script allow it. A file on your own origin reuses an open connection and can be cached on your terms.

Load on interaction. A chat widget that initialises when someone clicks the chat button costs nothing to the visitors who never do.

Use the consent platform as a gate rather than a bypass: scripts that need consent should not load before it, which reduces the default load for everyone.

List every tag with its owner and its purpose. Tags with no owner are the first candidates, and there are always some.

Ask when each one's data was last used in a decision. Collected-and-never-read is the most common state.

Consolidate duplicates. Two analytics platforms measuring the same thing is twice the cost for one answer.

Weigh the ones that remain against their measured cost rather than their perceived importance — a heat-mapping tool consulted quarterly is not worth a permanent second of load time.

Removing tags is also a privacy improvement, since each one is a third party receiving your visitors' data, and the consent and disclosure obligations follow accordingly.

`performance.third_party_resources` lists the external origins each crawled page loads from, with the resources fetched from each and their sizes.

`performance.request_count` and `performance.page_weight` give the totals, which is how the third-party share becomes a proportion rather than a list.

`privacy.tracker_inventory` identifies the ones that are trackers specifically, which is the same list read for a different obligation.

`performance.preconnect` reports the connection hints already in place, which decides whether the cheapest improvement is available without removing anything.