It is built for a cached site: the HTML is the same for everybody and the browser does the rest. It works alongside a page cache without configuration.

It does not hold your pages up. The banner's stylesheet is fetched while the page is drawn, not before, and the banner and the Cookie choices button appear only once it has arrived, already in place over the page, so nothing on the page moves. If a performance plugin combines stylesheets into a file the screen never uses, the banner asks for its own again. A held-back video or map is part of the page itself, so its look is written into the head of the pages that have one, and only those.

It empties your page cache at the moments that matter, because a stale page here is not a cosmetic problem. A page cached before you installed this still has the tracking tags live in it, and a cache will serve that page to everybody for as long as it holds it — the banner would appear and nothing would change. So the caches are emptied when the plugin is activated, when you change what is held back, when you change the settings that alter the page, when you import a settings file, when you press Ask everybody again, when you add what the monthly reading found, and once after each update: when you next open wp-admin, or at the next daily check if nobody does. On a network set up with sub-directories, every site the plugin runs on is emptied too, a few seconds at a time, as far as the caches switched on for the whole network go, and each site again with its own caches (see Multisite).

Network-activating it takes a few seconds too, however many sites the network has. LiteSpeed Cache and WP Super Cache are asked once, for the whole network, and NimbleCache, switched on for the network, empties every site by itself. The other caches are asked one site at a time for about three seconds, as each site is set up. After that, each site empties its own caches the first time WordPress runs on it, for a visitor or for you, and a site the activation did not reach is set up then. A page a cache hands out without running WordPress does not count, so on a large network a site the activation missed can go on serving pages cached before the plugin, with the tags live in them, until they expire: empty those caches yourself.

It also empties them when you deactivate it, for the mirror of the same reason: pages cached while it was running have the tags switched off, and with the plugin gone nothing would ever switch them back on. Network-deactivating it takes a few seconds, however many sites the network has. LiteSpeed Cache and WP Super Cache are asked once, for the whole network, and NimbleCache, switched on for the network, empties every site by itself. The other caches are asked one site at a time for about three seconds. On a large network that does not reach every site, and the sites it misses keep their cached pages, with the tags still held back, until they expire: empty those caches yourself. A site that has also switched the plugin on for itself keeps running it.

WP Rocket, W3 Total Cache, WP Super Cache, LiteSpeed, SiteGround, Breeze, WP-Optimize, Cloudflare's own plugin and NimbleCache are all asked. Anything else can listen for trcc_purge_caches. LiteSpeed Cache is asked for its pages only: its CSS and JS files, the object cache and Cloudflare stay as they are.

A performance plugin that combines scripts into one file, or renames them, hides their addresses, so this plugin cannot recognise them and they are not held back. That is true of every service here, WooCommerce's order attribution included: leave those scripts out of combining. A CDN or host cache that this plugin cannot empty may go on serving pages, or an old copy of the banner's script, from before an update until it expires.

If you run another consent plugin, switch one of them off. Two plugins both rewriting the same page is the one situation where the result depends on which loads last.

Caching, and other plugins