Caching & CDN compatibility

1. Why caching does not break tests

Most testing tools break behind caching because they decide the variant on the server; the cache then freezes one variant for everyone. ImproveAB assigns variants in the visitor's browser instead, so the same cached HTML works for every visitor and no cache exclusions are needed.

2. Anti-flicker and the script

The anti-flicker rules are inlined: variant markup stays hidden until the runtime reveals the assigned version, with a failsafe that shows the original after two seconds if the script is blocked, never every version at once. The visitor script is about 14 KB gzipped and loads from the page head, with the defer attribute on WordPress 6.3 and later. By default it loads on every page, so a conversion handed back from a cross-domain split test is never missed; a filter (abtestwp_load_runtime_always) limits it to pages that actually run a test. With JavaScript off, the original is shown and nothing is recorded.

3. Cache purges on start and stop

Because the small head snippet changes when a test starts or stops, the plugin purges the popular caches at those moments: WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache, Cache Enabler, Hummingbird, Breeze, SiteGround Optimizer, Nginx Helper, WP Engine, Kinsta, Pantheon and the Cloudflare plugin. It also sends Autoptimize's cache-purged notice for hosts that listen for it, and offers a hook for anything else. Script optimisers are a separate matter: the plugin adds its own scripts to the exclusion lists of WP Rocket, LiteSpeed Cache, Perfmatters, Autoptimize and SiteGround Optimizer automatically, but a delay-JavaScript tool that only has a settings screen (Flying Scripts, WP Fastest Cache's delay, Asset CleanUp) needs runtime.js, abtestwp-pending and abtestwp-redirect excluded by hand. If your CDN or proxy rewrites HTML aggressively, test one page first.

Want the longer read? See the full testing guide on the blog, or browse all docs.

Common questions