Every testing platform will happily sell you both. What the pricing page does not say is that plenty of brands buy server-side capability they never use, while others spend quarters fighting flicker that server-side would have removed on day one. The right answer is a decision about your backlog, not a default inherited from a sales call.
The plain-terms difference: a client-side test sends the visitor your normal page, then rewrites it in the browser with JavaScript. A server-side test decides which experience the visitor gets before the page is sent, so the variation arrives already applied and nothing visibly changes in front of the visitor. Everything else, cost, reach, risk, follows from where that swap happens.
The vocabulary hides how asymmetric the two builds are. A client-side variation is a script: written against the existing page, deployed through the testing tool, gone when the test ends. A server-side variation is a feature: it lives in your codebase behind a flag, rides your release process, needs its own instrumentation, and somebody has to remember to remove the losing branch when the experiment ends, which in our audits somebody has remembered roughly half the time. Same word, test, two entirely different engineering artefacts with two entirely different lifetime costs.
What each method is actually for
Client-side is the workhorse for visual change: layouts, copy, imagery, element order, most of what an ecommerce backlog contains. It is quick to build, needs no deploy, and a competent developer can have a variation live in days. The honest cost is fragility: the swap runs in the browser, after your theme and after every app script, which is where flicker and conflicts are born, and where a strong build discipline earns its fee.
Server-side is for changes the browser cannot reach or should not touch: pricing logic, search ranking, cart and checkout behaviour, and anything so performance-critical that a visible swap would poison the measurement. The build is real engineering with real deploys. The payoffs are no flicker at all and a reach that goes as deep as your stack does.
- Flicker: client-side risks it, server-side cannot have it, by construction.
- Reach: client-side stops at what the browser renders; server-side reaches pricing, search, logic and features.
- Speed to launch: client-side wins by days; server-side rides your release process.
- Cost: client-side builds are cheaper; server-side builds are engineering projects.
- Team: client-side needs a strong front-end developer; server-side needs your engineers, feature flags and deployment discipline.
The performance and SEO question, settled
Client-side testing gets blamed for two crimes it commits only when badly built. On speed: a competent setup loads one lean script early and costs single-digit milliseconds; the horror stories involve tag managers stacking three testing snippets from two abandoned platforms, or an anti-flicker curtain configured to hold the page for a full second. The curtain deserves a word of its own, because it is a trade: it hides the swap by delaying first paint, which means a lazy build can convert a flicker problem into a speed problem and call itself fixed.
On SEO: search engines explicitly permit A/B testing, and a correctly built test of either kind does not hurt rankings. The rules are the same ones honest testing already follows: no showing crawlers different content from humans, canonical tags on split URLs, and experiments that actually end. Server-side tests are invisible to this entire conversation, which is one of their quieter advantages: there is no swap to see, so there is nothing to explain to the SEO team.
The measurement difference is subtler and matters more. A client-side variation depends on the visitor browser executing your JavaScript after everything else has loaded, which means old devices, slow connections and aggressive content blockers all quietly thin the variation arm. Server-side assignment happens before any of that can interfere. For most visual tests the effect is negligible; for tests where milliseconds are the subject, it is the difference between measuring your idea and measuring your delivery mechanism.
The decision, in three questions
Is the change visual only? Client-side, well built, is enough, and paying server-side engineering prices for a headline test is burning money. Does it touch price, search or checkout logic? Server-side is not optional there; on Shopify specifically the boundaries are drawn by the platform, as our Shopify testing guide maps in detail. Is flicker already contaminating your results? Then either your client-side builds need rescuing or the tests genuinely belong on the server; diagnose before you migrate, because moving badly built tests to a new method ports the team that built them badly.
The hybrid reality
On Shopify the boundary is drawn for you: client-side tools cover the theme, while pricing needs cohort tooling and checkout work needs Functions and extensibility on Plus. On custom and headless stacks the boundary is wherever your engineering team draws it, which is more freedom and more ways to draw it wrong. The commonest mistake in both worlds is the same: choosing the method by what the team already knows rather than by what the hypothesis touches, and then defending the choice for a year because the tooling is already set up.
Mature programmes run both, routed by hypothesis: visual work client-side for velocity, logic and pricing server-side for reach, one experimentation calendar over the top so the two never collide on the same audience. The mistake is treating the methods as a maturity ladder, as if graduating to server-side were the goal. The goal is answered questions per quarter, and the engineering discipline matters more than the transport: a flickering client-side build and an untracked server-side build are the same failure wearing different clothes.
A fair cost heuristic from our own quoting: a competent client-side build is measured in hundreds of pounds, a server-side experiment in thousands, and the gap is honest, because one is a script and the other is a feature. Buy the cheap one whenever it answers the question. If you are not sure which your next three tests need, our build practice scopes that question for a living, or get in touch with the backlog and we will sort it into lanes with you.
