Performance-Heavy Triggers
One or more triggers in this container fire so frequently that they add measurable CPU and main-thread work to every page. The most common offenders are Timer triggers with intervals under 5 seconds and History Change triggers that fire on every browser-state push, regardless of whether the change is meaningful.
Why It Matters
GTM triggers run JavaScript on the main thread. A Timer trigger with a 1000ms interval evaluates its conditions and potentially fires tags 60 times per minute, every minute the page is open. on a content-heavy page that is already busy, this can push Cumulative Layout Shift and Interaction-to-Next-Paint into yellow or red ranges. History Change triggers in single-page applications fire on every `pushState` and `replaceState` call, which modern SPA frameworks call constantly during normal user interaction. The accumulation is invisible until the marketing team complains that Core Web Vitals scores are tanking and nobody can pinpoint why. The check fires conservatively on configurations Google has documented as performance risks; every match should be reviewed against the actual use case to decide whether the frequency is justified.
How To Fix It
- AdLint's details list each performance-heavy trigger and the specific reason it was flagged.
- For Timer triggers: ask whether the use case really requires sub-5-second polling. Most measurement use cases fire fine on 30-second or 60-second intervals; if you genuinely need real-time, consider a different architecture (server-side GTM or a custom event).
- For History Change triggers: add filter conditions so the trigger only matches genuinely meaningful URL changes (e.g. `Page Path matches RegEx ^/(checkout|signup|confirmation)`), not every minor pushState.
- Republish and re-run a Lighthouse or PageSpeed test on a representative page to confirm CWV scores improve.
Example
Timer trigger: "Engagement ping"
Interval: 1000ms (fires every 1 second)
Fix: raise interval to 30000ms (30s), or remove the trigger if the measurement is not load-bearing.GTM triggers configured in ways documented as performance risks. Timer triggers with sub-5-second intervals or History Change triggers without filter restrictions. Google's Tag Manager performance best practices, these patterns add main-thread work that compounds across every page view and can measurably degrade Core Web Vitals scores. Fix: raise Timer intervals to a frequency the use case actually requires, and add filter conditions to History Change triggers so they fire only on meaningful URL changes. Source: support.google.com/tagmanager/answer/7679319.
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