_sbp cookie and cache conflict

Custom Loader
1

Hello,

The _sbp master cookie used by Cookie Keeper is created in PHP by the WordPress plugin when WordPress renders the page. Our host (Kinsta) uses full-page caching, on a cache HIT, PHP never runs, so _sbp is never set for the vast majority of real visits (our homepage is cached almost all the time).

We asked our host to add a cookie-based bypass rule (skip cache whenever _sbp is missing, so PHP can run and set it). They did, and _sbp now gets created correctly on first visit. But the tradeoff is significant: our Time To First Byte jumped from around 80ms baseline to an average of 1200ms, since every visitor without the cookie now forces a full uncached PHP render.

Is there a way to avoid this PHP dependency altogether ? For example having the master identifier set by Stape’s own infrastructure (has.) rather than requiring our WordPress to run PHP on every uncookied visit ? That would let us keep full-page caching untouched.

Also, we noticed the new “Same-origin proxy (BETA)” option in the WordPress plugin (“The GTM loader is served from Stape through your own WordPress server, so it loads first-party”). Does this still require PHP execution on every page (same conflict as above), or does it work differently ? Is it compatible with Cookie Keeper / Stape User ID ?

Testing things around gave us another solution. Switching to Platform “Other” with “Stape User ID” as the identifier (instead of the plugin’s default Cookie Keeper) avoids _sbp entirely. Our Cookie Lifetime score went to 100 after testing this on one domain. So we know this path works technically.

But since we share one container across many many domains, this means deploying a domain-specific script manually on every single site instead of managing it centrally, which isn’t ideal at our scale. Is there a more portable way to do this across a shared multi-domain container or does the bgb1n parameter in the generated snippet need to stay domain-specific regardless ?

Last thing I’ve read around here is that the _sbp Cookie is better than the Stape User ID, but the TTFB is insane now.

Thank you for your help

2

Thank you for your detailed description. The caching issue on the WP side is known, and we are currently working on a solution that will work well, but I cannot tell you when it will be released.

Same Origin solves the same problem as Cookie Keeper, so you can use Same Origin and not use Cookie Keeper, which requires the _sbp cookie.
Same Origin is designed to address the Safari ITP limitations, so your server-side cookies can persist for their full intended lifetime. This is because your request URL will share the same origin as your site URL, so the browser treats it as a true first-party request.
Here you can find a complete guide to setting up Same Origin in the WordPress plugin: Stape Conversion Tracking Plugin for WordPress Setup

3

Thank you for your help :slight_smile:

So if I understood it right it would be better to use Same Origin for now, and it will work well ?

And then when your solution for the WordPress caching issue is released we could (and should) go back to the _sbp cookie ?

4

That’s absolutely correct.

You do not need to revert to using Cookie Keeper, which sets and relies on the _sbp cookie.
Same origin would also allow you bypass Safari ITP limitations.

However, the decision as to which method to use is entirely up to you.

1 Like
5

Thank you for your help

1 Like