When Google Tag Manager became the performance bottleneck

A healthcare marketing site on WordPress, lead-gen forms, condition-specific landing pages, strict compliance requirements, reported rising bounce on mobile despite acceptable LCP in lab tests. Real-user INP had degraded to 480ms (p75), correlating with campaigns that added more tracking pixels through Google Tag Manager without engineering review.

GTM container export revealed 47 tags, 31 triggers, and 18 variables, accumulated over three years by performance, SEO, and company teams. We found three Meta Pixel implementations (hardcoded in theme, via GTM, and a leftover plugin), two Hotjar snippets, and a LinkedIn Insight tag firing on DOM ready across every page including logged-in admin (blocked later).

WordPress-specific fixes: removed hardcoded pixels from footer.php; disabled a plugin that injected GTM a second time; lazy-loaded iframe embeds on resource pages; documented dataLayer contract in repo README for future campaigns.

Problems: marketing insisted all tags stay "active" for attribution; legal required Consent Mode v2 before analytics fired in EU traffic; removing a tag broke a Looker Studio dashboard that depended on a custom dataLayer event nobody had documented.

Approach: tag inventory workshop with owners and kill dates; consolidated Meta to single server-side CAPI path + one browser pixel with consent gate; moved non-essential tags to interaction triggers (scroll 25%, form focus) instead of DOM ready; excluded /wp-admin and preview URLs globally.

We evaluated server-side GTM on Cloud Run, piloted for Meta and GA4 streams to reduce main-thread work. Browser container slimmed from 47 to 19 tags.

Outcome: INP p75 480ms → 188ms on landing templates; no material loss in attributed leads over 30-day parallel tracking; compliance sign-off on Consent Mode v2 implementation. Identity withheld, healthcare marketing operator.