Why cookie banners break behind caching plugins, and how to tell
If your banner worked when you set it up and trackers now load anyway, a caching or speed plugin is the first place to look. Here is what goes wrong, in plain terms, and how to check.
Two things called "caching"
Page caching saves the finished page and hands the same copy to every visitor, so WordPress does not rebuild it each time. JavaScript optimisation rewrites the scripts in that page: combining them into one file, delaying them, or moving them to the bottom. Speed plugins usually offer both, and each breaks consent banners in its own way.
How page caching breaks a banner
Some consent tools decide on the server which scripts to include, by reading the visitor's saved choice. That works until a page cache is switched on. Then the page built for one visitor is served to the next:
- A page built for someone who accepted is cached, and everyone after them gets the trackers, whatever they chose.
- Or a page built for someone who rejected is cached, and your analytics quietly stop for everybody.
Either way the banner still appears and still looks fine, which is why this goes unnoticed for months.
How JavaScript optimisation breaks a banner
A consent tool holds a script back by recognising it: usually by the address it loads from. When an optimiser merges your scripts into one combined file, or rewrites them to load later through its own loader, that address is gone. The tracker is now inside a file the consent tool has no reason to stop.
How to tell which one you have
- Run the two-minute network test in a private window. Note whether trackers load before you choose.
- Log in to WordPress and clear the cache. Run the test again straight away, in a new private window.
- If it passes right after clearing and fails later, it is page caching: the result depends on who visited first.
- If it fails even right after clearing, switch off the "combine", "minify", "delay" or "defer JavaScript" options, clear the cache, and test again. If it now passes, it is JavaScript optimisation.
What to do about it
For page caching
Use a consent tool that does not vary the page by visitor. The safe design sends every visitor the same page with the trackers switched off, and switches the allowed ones on in the visitor's own browser. Nothing about one person's choice is ever stored in the cached copy, so there is nothing to leak to the next person. The alternative, excluding every page from the cache for visitors who have a consent cookie, works but gives up most of what the cache was for.
For JavaScript optimisation
Exclude tracker scripts from combining, delaying and deferring. Every speed plugin has an exclusion list. Add the addresses of the tools you use, for example:
googletagmanager.com,google-analytics.comconnect.facebook.netclarity.ms,hotjar.comsnap.licdn.com,analytics.tiktok.com
Also exclude your consent plugin's own script, so it runs before anything it is supposed to control. Then clear the cache and test again.
For a CDN
A CDN that caches whole pages behaves like page caching above. One that only serves images and files does not affect consent. Features that "optimise" or rewrite scripts at the CDN behave like JavaScript optimisation: exclude the same addresses there.
How TidyConsent handles it
TidyConsent never reads the visitor's choice on the server. Every visitor is sent the same page with the known tools switched off, and each visitor's choice is applied in their own browser on every page. That is safe behind any page cache or CDN with no exclusions. A JavaScript optimiser can still hide a tracker from it by merging files, so the exclusion list above applies to TidyConsent as it does to any consent tool.
Want it handled for you?
TidyConsent is a free WordPress plugin that holds eleven common tools back until each visitor agrees, works behind page caches, and sets Consent Mode v2. Or let us look at your site first.
Get the free plugin Scan my site