One efficient solution, assuming there is a caching layer in front of the next.js instance (which makes sense with a large amount of dynamic pages which might rely on slow data sources) would be to rely on a cloud edge worker (naming depends on vendor, but generally a script that intercepts requests before the caching layer) to determine which experiments the requesting user participates in, and assign them to buckets. Given this information, rewrite request URI or add headers containing info about the chosen variants, and pass the request on to the next.js instance - which can render the page in the required state. This is best done combined with some sort of feature flag implementation, because that way the next.js application doesn't need to be aware of any A/B testing related logic or values. Details are specific to infrastructure and implementation, but from a bird's-eye view this is one good way to do this, which avoids client-side jumps in content and allows for efficient caching, while only adding one extra request (to the API used to serve experiment info) per user, on their first request (I did not go into how this eventually expires like we all do, because there's a lot more complexity to this).