Caching plugins: Cookie Rocks documentation

Written for Cookie Rocks 2.9.14, checked on 5 November 2026. The current version is 2.11.2: some details may have changed.

A page cache keeps a ready copy of each page and serves it to the next visitors. An optimisation plugin delays, combines or shrinks scripts.

Both matter for a cookie banner. A cached page can show an old banner. A delayed script can run before or after the visitor chooses.

The Audit adds no script and no style to your visitors’ pages. It has nothing to exclude from optimisation, and no reason to clear your cache.

Set it up in 3 steps

After you change the settings of your banner, clear your page cache. Clear the cache of your host or of your CDN too, if you use one.
Open Cookie Rocks, Cookies, and click Scan my pages.
Open the Overview. If it says that your cookie plugin’s banner was not found on your home page, clear the cache again, then scan again.

If you see “No page of the site could be read”. The site may be protected by a password, in maintenance, blocked by a firewall, or served by a cache that ignores the scan. The previous scan is kept. Clear or pause the cache, then scan again.

What the Audit checks

Each page opened by the scan carries a scan token in its address. Cookie Rocks asks caches not to keep that page, so that the Audit reads it as it is built. A cache that ignores the token can still serve its stored copy.
The scan sees scripts that a performance plugin delays until the visitor’s first interaction (WP Rocket, Perfmatters, LiteSpeed Cache). It recognises a tracker delayed this way like any other script.
When your cookie plugin is active but its banner was not found on your home page during the last scan, the Overview says so. One possible cause is a page cache that still serves an old copy.
The Weight page measures what your banner adds to your home page, as it travels over the network.

With Cookie Rocks Pro: optimisation and delayed scripts

With Cookie Rocks Pro

The consent script at the top of the page must run first and unchanged. When an optimisation plugin is active, the Pro scripts carry the marks that tell it not to delay, defer, combine or minify them. They always carry the mark that keeps them out of Rocket Loader of Cloudflare.
They are added to the exclusion lists of WP Rocket, LiteSpeed Cache (Guest Mode included), SiteGround Optimizer, Autoptimize, Breeze, FlyingPress, Perfmatters and Hummingbird. W3 Total Cache does not minify them. Jetpack Boost does not combine a known tracker with your other scripts, so it can still wait for consent.
A tracker delayed by WP Rocket, Perfmatters or LiteSpeed Cache is held until consent, then given back to that plugin. For a visitor who has already accepted, it still starts at the first interaction, so the site keeps its speed.
A setting that changes nothing for visitors, such as an answer on the Obligations page, does not clear the cache.
For another optimisation tool, a developer can add marks with the cookie_rocks_no_optimize filter. See PHP filters, actions and REST API.

With Cookie Rocks Pro: when the banner does not show

How it is tested

The Compatibility table of the Developers page shows, for each plugin, the version tested and how.

Tested automatically with its latest version: LiteSpeed Cache, SiteGround Optimizer, W3 Total Cache, WP Super Cache and Autoptimize.
Reproduced in the tests: WP Rocket and Perfmatters. Their delayed scripts are imitated, not the plugins themselves.

For site owners: Cookie Rocks for caching plugins, with a page for WP Rocket, LiteSpeed Cache, SiteGround Optimizer, W3 Total Cache, WP Super Cache, Autoptimize and Perfmatters.

Next step: Divi.

Cookie Rocks helps you find your way through cookie and privacy rules. It does not replace a lawyer’s advice.