Consent hosting where the banner survives the page cache.
A consent banner has to appear before anything loads and remember a choice per visitor. Full-page caching is designed to do the opposite of both.
Two systems with opposite jobs.
The cache wants one identical response for everyone. Consent wants a different behaviour per visitor. Making both work is the entire exercise.
Nothing fires before somebody agrees
Analytics and marketing tags have to be held until consent is given, not loaded and then apologised for. Blocking happens ahead of the script rather than after it has already reported.
A cached page that still asks
The banner cannot be baked into a cached response as either shown or dismissed. Consent state is resolved per visitor on top of a page everyone shares.
Proof that consent was given
A regulator asks when somebody agreed and to what. Consent records are stored and backed up rather than living only in the visitor's own browser.
A banner that does not wreck the layout
Consent scripts are famous for shifting content as they load. Loading order is set so the banner appears without pushing the page around underneath it.
Rules that differ by region
Opt-in, opt-out and do-nothing are all correct depending on where the visitor is. Region detection happens without turning every page into an uncacheable one.
The banner is not the compliance.
Most sites show a banner and load the tags anyway. That is worse than no banner, because it documents an intention the site does not honour.
- Tags held until consent is recorded
- Consent resolved on top of cached pages
- Records stored server-side as evidence
- Regional rules applied without breaking cacheability
Compliant and still fast.
The usual trade is a consent layer that adds half a second and a layout shift. Neither is necessary if the blocking happens in the right place.
What we change for consent plugins
Every row exists because consent is per visitor and caching is per page, and those two facts have to be reconciled somewhere.
| Setting | What we do | Why |
|---|---|---|
| Tag blocking | Applied before the script is requested | A tag that loads and is later disabled has already reported the visit, which is the failure mode most banners actually ship with. |
| Consent state | Resolved per visitor on top of a shared cached page | Baking the banner into the cached response fixes it as either shown or dismissed for everybody, so one of those groups gets the wrong behaviour. |
| Consent records | Stored server-side and included in backups | Proof of when consent was given and for what is the thing a regulator asks for, and a record kept only in the visitor's browser is not evidence. |
| Banner load order | Sequenced to avoid shifting content | Consent layers are a common cause of layout shift, and a compliance requirement should not cost a visible page jump. |
| Regional rules | Detected without making pages uncacheable | Opt-in and opt-out regimes need different behaviour, and the naive implementation turns every page into a per-visitor render. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Does a cookie banner break my page cache?
Do my analytics tags load before consent?
Where is consent stored?
Will the banner cause layout shift?
Comply without slowing down.
Move the site across. Migration is free, consent setup reviewed.