GTM Container Size and Tag Count
GTM has documented workspace size limits and operational thresholds that this container is approaching or exceeding. A container near the size limit cannot be published once it crosses the threshold, and a container with hundreds of tags becomes slow to audit and increases page-load weight for every site visitor.
Why It Matters
Google publishes two operational ceilings for GTM containers. The first is a hard workspace size limit (currently around 200 KB of compressed container JSON for web containers). Once a container exceeds this, GTM refuses to publish the workspace and the team has to delete or archive assets before any new change can ship. The second is a soft tag-count threshold (200+ tags) where every page load executes the full GTM container script and runtime, so each additional tag adds milliseconds to Time-to-Interactive on every page. Sites that score in the 90s on Lighthouse can drop into the 70s purely from container weight. AdLint scores the container against both thresholds and flags accumulation early enough to act. The practical risk is two-fold: an emergency where a critical change cannot be deployed because the workspace is full, and a slow, invisible CWV regression that compounds with every new pixel or third-party tag.
How To Fix It
- In GTM, open Admin → Container Settings to see current container size relative to the limit.
- In Workspace → Tags, sort by Last Edited and identify tags that have not changed in 12+ months and have no recent Tag Assistant evidence. These are candidates for archive.
- Use the AdLint `stale-tags` and `unused-triggers` findings to identify safe-to-archive assets. Both ship hints about what is no longer load-bearing.
- Archive (do not delete) the candidates in a dedicated cleanup workspace, then publish. Container size drops immediately.
- For ongoing health, add a quarterly governance review where any tag untouched for 12 months is reviewed for archival.
- If the tag count is high but everything is active, consider migrating high-traffic pixels (Meta, TikTok, LinkedIn) to server-side GTM to reduce client-side weight without losing functionality.
Example
Container size: 168 KB of 200 KB (84% of limit)
Tag count: 187
Stale tags (last edited > 12 months ago): 41
Recommended action: archive stale-tags candidates in a dedicated cleanup workspace.This GTM container is approaching the documented workspace size limit and/or has accumulated a tag count above operational best practice. Google's Tag Manager limits documentation, web containers have a published workspace size limit and exceeding it blocks all new publishes. High tag counts also contribute to client-side page-load weight that compounds across every visitor. Fix: audit the container for stale and unused assets, archive candidates in a dedicated cleanup workspace, and consider migrating high-traffic pixels to server-side GTM. Source: support.google.com/tagmanager/answer/2649961.
Drop this paragraph into your client deliverable. Sources back to the canonical platform documentation linked below.
References
Audit your own files for this check
AdLint runs this check (and 177 others) against your GTM, Google Ads, Meta, TikTok, LinkedIn, Pinterest, Twitter/X, and Snapchat exports. Everything stays in your browser. No uploads, no accounts.
Run a free audit