In server-side testing, the experiment logic runs before the HTML reaches the user's browser. The server (or edge network) determines which variant to serve and delivers the complete, pre-modified page. The user's browser never sees the control version of the page — it only renders the assigned variant.
This is in contrast to client-side testing, where JavaScript loads after the page and modifies the DOM on the user's device.
How Server-Side Testing Works
- A request arrives at the server or edge
- The experimentation layer reads the user's assignment (from a cookie, user ID, or request headers)
- The server renders the assigned variant and returns complete HTML
- The browser renders the page — no modification needed
Server-Side vs. Client-Side Testing
| Server-Side | Client-Side | |
|---|---|---|
| Flicker | None | Possible (flash of original content) |
| Implementation effort | Higher (requires code deployment) | Lower (tag-based, marketer-accessible) |
| Test complexity | Unlimited | Limited to DOM/CSS changes |
| Performance impact | Minimal | Can delay page render |
| Deployment speed | Slower (requires engineering) | Faster (visual editors) |
| Use cases | Logic, pricing, algorithms | Copy, design, layout changes |
When to Use Server-Side Testing
Server-side is the right choice when:
- The change involves backend logic (pricing, recommendations, ranking algorithms)
- Flicker would be highly visible or damaging to user trust
- You need to test features that don't exist yet in the frontend (controlled via feature flags)
- Performance is critical and you can't accept JavaScript overhead
Implementation Approaches
Server-side tests are typically implemented through:
- Feature flags — A flag service assigns users to variants; application code branches accordingly
- Edge middleware — Variant assignment and content modification at the CDN edge (e.g., Vercel Edge Middleware, Cloudflare Workers)
- Backend A/B frameworks — Libraries that integrate with your application server to manage assignment and logging