Third-Party Scripts and Tag Bloat

Why third-party code costs so much

A third-party script runs on the same main thread as your own code. While it downloads, parses and executes, the browser cannot respond to taps or paint new frames. Many tools also load further scripts of their own, so one tag can mean several requests to several domains. The cost shows up in Interaction to Next Paint and in lab measures such as Total Blocking Time, which carries the largest weight, 30%, in the Lighthouse performance score ^[1].

web.dev's guidance on tag managers states that its authors "have seen a correlation between the size of tag managers and poorer INP scores" ^[2]. That does not mean a tag manager is bad in itself. It means whatever is inside it needs regular attention.

Step 1: make an inventory

Open a key page in a browser's developer tools and list every request to a domain other than your own. Then open your tag manager and list every tag, trigger and the pages it fires on. For each script, record:

• what it does and who asked for it;
• which pages actually need it;
• whether it is still used, for example whether anyone reads the heatmaps;
• whether a contract or consent requirement depends on it.

web.dev recommends labeling each tag with an owner and reviewing triggers and variables during audits, because tags tend to accumulate ^[2].

Step 2: remove what nobody uses

Old campaign pixels, trial tools that were never canceled and duplicate analytics are typical candidates. web.dev is specific about how to remove them: "Unused tags should be paused or removed rather than blocked through use of a trigger exception" ^[2]. A blocked tag still sits in the container and still adds to its size. Pausing first gives you a quick way back if someone turns out to depend on it.

Step 3: delay what is not essential

Most tags do not need to run before the visitor sees the page. web.dev advises that "to avoid impacting page load, fire non-essential tags after Window Loaded" ^[2]. Chat widgets can often wait until the visitor scrolls or shows interest. Review widgets can load when their section comes into view. Each delay frees the main thread during the moments that decide LCP and the first interactions.

Step 4: keep critical features out of the tag manager

It is tempting to add everything through a tag manager because it is convenient. web.dev warns against putting user-experience-critical resources there, such as cookie notices, hero images and core site features, because they load later, can hurt LCP and CLS, and break for visitors who block tag managers ^[2]. Those belong in the site's own code.

Step 5: prefer lighter options

Where a vendor offers a choice, the lighter option is usually better. web.dev describes image tags, or pixels, as "the most performant and secure type of tag because there is no JavaScript execution after it's fired" ^[2]. It also cautions that Custom HTML tags are easy to misuse in ways that hurt performance, and recommends custom templates and the injectScript API instead ^[2].

Step 6: keep containers small and single

Each container adds overhead and duplicates core tag code, so web.dev recommends avoiding multiple containers on one page ^[2]. It also notes that Google Tag Manager warns at 70% of its 300 KB container limit, and that most sites should stay well below it ^[2].

Platform apps behave the same way

On hosted store platforms, apps play the role of tags. Shopify's theme documentation recommends auditing every script, including apps and tracking pixels, and removing any that are not earning their performance cost ^[3]. It also makes a fair point in the other direction: "Badly written first-party code is just as damaging as a poorly implemented third-party script" ^[3]. An audit should look at both.

Measuring the difference

Test a key template with all tags, then with non-essential tags delayed, under the same lab settings and with CPU throttling on. Compare Total Blocking Time and the main-thread activity in a performance trace. Then watch field INP over the following weeks, since PageSpeed Insights reports a 28-day window ^[4].

Working with your marketing team

Tag audits fail when they are done without the people who rely on the data. Agree up front which events must keep firing, such as purchases, form submissions and key page views. Test them after each change. Share the inventory so new tags are added with an owner and an end date. A short quarterly review keeps the list from growing back.

A worked example: a tag manager audit

Consider a fictional services company whose tag manager container has grown to 46 tags over four years. The inventory finds three analytics tags doing the same job, pixels for two advertising platforms the company stopped using, a heatmap tool from a trial nobody renewed, a custom HTML tag that loads a large chat script on every page, and a cookie banner loaded through the container.

Following web.dev's guidance ^[2], the team pauses the duplicate analytics tags and the old pixels, waits two weeks to confirm nobody missed them, then deletes them. The chat script moves out of the custom HTML tag into a delayed load that starts after the window has loaded. The cookie banner moves into the site's own code so it appears promptly and does not shift the layout. The container shrinks to fewer than twenty tags, each with a named owner. Lab Total Blocking Time drops, and field INP improves over the following month.

Consent tools and performance

Consent management platforms sit in an awkward spot. They need to appear early, so they cannot simply be delayed, and when a visitor accepts, they often release every waiting tag at once. That moment can create one of the slowest interactions on the page. Load the consent tool from your own site rather than through the tag manager, as web.dev suggests for user-experience-critical resources ^[2], reserve its space so it does not shift content ^[5], and stagger the tags it releases where your tools allow it.

Embeds: video, maps and social posts

Embedded videos, maps and social posts load third-party code even if the visitor never plays or scrolls to them. A common pattern is a lightweight facade: show a static preview image with a play button or a "load map" button, and load the real embed only when the visitor asks for it. Give the placeholder a fixed aspect ratio so nothing shifts when the embed replaces it. This keeps the cost of the embed off the critical path while leaving the feature fully available.

Deciding what to keep

Some third-party tools earn their cost. Analytics that someone reads, a booking widget that takes reservations, a payment provider at checkout: these stay, and the work is about loading them efficiently. A simple question helps with the rest: if this tool vanished tomorrow, who would notice, and what would they lose? If the honest answer is "nobody" or "a report nobody opens", the tool is a candidate for removal. Writing that answer next to each tag in the inventory makes future audits much quicker.