Server-side testing means your server (or app backend) decides which variant a visitor gets and sends back a page that already contains it, so nothing changes in the browser after load.
Client-side testing does the opposite: the original page loads, then a JavaScript snippet rewrites it in the visitor's browser.
Use client-side for fast visual tests on marketing pages.
Use server-side for prices, shipping rules, checkout logic, onboarding flows, apps and anything where flicker or speed matters.
Both are real A/B tests with the same statistics.
The difference is where the variant is built, and that decides what you can test, who has to build it, and how much the test itself can skew your results.
Client-side testing: how it works and where it fits
In a client-side test, you add a script tag to your site.
When a visitor arrives, the script assigns them to a variant, stores that in a cookie, and applies changes to the page with JavaScript: new headline, moved button, hidden section.
Most visual editors in tools like VWO, Convert and Optimizely Web work this way.
The big advantage is speed of setup. A marketer can change copy or layout in a visual editor without a code deploy, which is why most of the 1,724 results in our test database are page-level changes that were almost certainly run this way.
The flicker problem
Because the browser can paint the original page before the script finishes, visitors may briefly see the control and then watch it change.
Optimizely's own docs define this "flashing" as a page showing the original content for a short time before loading different content, and say that loading the snippet asynchronously "increases the risk of flashing."
Their fix is a synchronous snippet high in the <head>, which blocks rendering until it runs.
So client-side tools make you choose: block the page (slower first paint for everyone) or let it render (risk of flicker, which can tip people off and bias results).
We cover the fixes in detail on the flicker effect page.
Timeouts quietly drop visitors
Asynchronous snippets have a timeout so a slow tool never breaks your site.
VWO (now under the Wingify brand) documents default timeouts of 2,000 ms for settings and 2,500 ms for the library.
When the code times out, the visitor sees the original page and is not enrolled, so their visit and conversions are not tracked.
That is a safe failure, but it means your test sample leans toward visitors on fast devices and connections.
If your buyers skew mobile on weak networks, a client-side test can under-sample exactly the people you care about.
Cookie lifetime limits
Client-side tools usually remember the assignment in a cookie set by JavaScript.
Since Intelligent Tracking Prevention 2.1, Safari caps persistent cookies created through document.cookie at seven days.
A returning Safari visitor after that window can be reassigned and see the other variant, which matters for long tests and slow purchase cycles.
Cookies set by the server in an HTTP response are not covered by that rule.
Script weight is a real cost
Every extra script competes with your own page for load time, and our database has clear examples of the build itself moving revenue.
Oliver Kenyon rebuilt a landing page natively in Shopify and tested it against the identical page in a page builder: same copy, images and offer, +9.9% conversion rate and +20.9% revenue per visitor.
Vasta replaced an app-powered header with the native theme header on Canada Welding Supply and saw +17.02% conversion rate.
Neither was a client-side vs server-side test, but both show that front-end weight is not free.
The scale is backed by large controlled experiments too: Bing ran a slowdown test and found that every 100 msec of speed improved revenue by 0.6% (Kohavi et al., KDD 2013).
Full stack experimentation: testing in the code
"Full stack experimentation" is the vendor term for server-side testing that reaches every layer: backend logic, APIs, mobile apps, email, search ranking and pricing.
Instead of a script that rewrites a page, your developers call an SDK in the code that returns a variant, then build both branches.
It usually sits on top of feature flags, so the same switch that rolls out a feature can split traffic.
How assignment works
Good SDKs assign users deterministically. Optimizely's docs explain that its Feature Experimentation SDKs hash the user ID with the experiment ID using MurmurHash3, so the same user always lands in the same bucket.
Bucketing happens in memory with no network call, which means the same user gets the same variant on web, app and email as long as you pass the same ID.
That cross-device consistency is something cookie-based client-side tools can't promise.
The catch: you need a stable ID. For logged-out visitors you still need a first-party ID, ideally set by the server.
Some tools let you choose where flags are evaluated.
GrowthBook, for example, supports local evaluation in the SDK or remote evaluation on your own server, which keeps targeting rules private but adds a network round trip.
What full stack testing unlocks
The tests that move revenue most often change rules, not pixels. In our database:
- Dave Diederen tested shipping price levels and a $9.49 fee beat the control: +23.40% conversion rate, +43.81% revenue per visitor and +16.54% AOV. Shipping rates live in checkout logic, not in page HTML.
- Convertibles ran an A/B/n price test with five variations for an adult wellness brand, moving two $99 products to $125 and $90. Profit per visitor went from $0.44 to $0.68 (+54.7%).
- Server Density swapped per-server pricing for packaged tiers: revenue rose 114% ($394 to $833), while free sign-ups fell from 6.92% to 5.19%.
- AURUM (Astrea) added a floating onboarding checklist inside the trial product and reported +187% activation, though it was a controlled rollout rather than a strict A/B split.
You can fake a price change client-side by rewriting the displayed number, but the cart, checkout, tax and order emails will still show the real price.
That mismatch breaks trust and can create legal problems.
Real price tests belong in the backend; our price testing guide covers the setup.
@DaveDiederen
ConvertiblesServer-side tests in the database
Several case studies in our archive state outright that they ran server-side.
Whitepages tested side-by-side plans with a billing toggle as a one-week server-side test and got +23% conversion rate and +31% monthly memberships (several changes bundled).
EnergySage tested a real team member's name in a verification email server-side for two weeks: +3.98% approved properties.
Plymouth Rock Assurance ran a server-side test that explained its app at checkout in three steps and saw about +10% progression.
Notice the pattern: pricing, email and a post-purchase checkout step.
None of these are easy to test with a script that only sees the rendered page.
Server-side vs client-side testing: how to choose
| Client-side | Server-side / full stack | |
|---|---|---|
| Where the variant is built | In the browser, after the page loads | On the server or in the app, before the response |
| Who sets up a test | Marketers via a visual editor, or light JavaScript | Developers in the codebase |
| Flicker | Possible; reduced by blocking snippets or anti-flicker code | None; the page arrives finished |
| Speed cost | Extra script on every page | Small assignment cost on the server |
| What you can test | Copy, layout, images, page-level UX | Prices, shipping, checkout, algorithms, onboarding, apps, email |
| Assignment memory | JavaScript cookie (7-day cap in Safari) | User ID or server-set cookie |
| Cost to ship a winner | Still needs a developer to hard-code it | Winner is already in the code; flip the flag |
When client-side is the right choice
Pick client-side when you are testing copy and layout on marketing pages, you have little developer time, and you want to run many quick tests.
Most of the page-level wins in our A/B testing hub fit this profile.
It is the wrong choice for anything that touches money (price, shipping, discounts that must carry into checkout), for single-page apps that re-render after the script runs, and for long tests where Safari reassignment can contaminate groups.
When server-side is the right choice
Pick server-side when the change lives in business logic, when the same user must see one variant across web, app and email, or when your site is already heavy and you can't afford another blocking script.
It is the wrong choice when you have no developer capacity: a test queue that needs a sprint per idea will run far fewer tests, and test volume drives most program results.
A worked example: why server-side tests still need careful reading
Server-side removes flicker, not noise. Take Server Density's test: 20 paid conversions from 1,950 visitors in one arm (1.03%) against 15 from 1,925 in the other (0.78%).
A difference of five sales on a few thousand visitors is very fragile, and the revenue lift came mostly from a higher order value.
The build method can't fix a small sample; check statistical significance and sample ratio mismatch the same way you would for any test.
Server-side tests also have their own bugs. If one branch errors more often, or caches are keyed wrongly so some users see the wrong variant, your split goes off.
QA each variant before launch and add guardrail metrics such as error rate and load time.
The hybrid most teams end up with
Many teams run both: client-side for fast marketing-page tests, server-side for pricing, checkout and product.
Most major platforms now sell both modes; compare them in our experimentation platforms guide, including code-first options like GrowthBook and Optimizely Feature Experimentation.
Shopify stores can also use apps that change prices and shipping rates natively.