A common pattern emerges six to nine months after a Hyvä migration. The storefront ships fast, Core Web Vitals are green, conversion rates have improved, and the marketing team gets ambitious. They want to run A/B tests, on hero images, on PDP copy, on cart flow, on price presentation. The testing tools they reach for are the ones they used before the migration: client-side experimentation platforms that inject JavaScript and rewrite the DOM after the page loads. Within a month, the page speed gains from the Hyvä migration start eroding. Within three months, INP scores are back where they were on Luma.
This is not a Hyvä problem. It is a tag management problem, and it is the most common way that performance gains from a migration get squandered. The fix is straightforward once a team understands the underlying constraint: client-side A/B testing tools work by blocking page rendering until they decide what variant to show, and that blocking time competes directly with the LCP and INP budgets that Hyvä optimizes.
This piece is for engineering and growth teams running A/B tests on Hyvä-powered Adobe Commerce stores. It covers the patterns that let experimentation continue without giving back the Core Web Vitals gains. Bemeir’s Hyvä performance practice runs into this problem on most enterprise engagements, and the patterns below are the ones that have produced sustainable testing programs.
What Client-Side A/B Testing Actually Does
A typical client-side A/B testing tool, Optimizely, VWO, Convert, AB Tasty, injects a JavaScript snippet in the page head. That snippet does a few things: it identifies the user, decides which variants to expose, hides parts of the page until the decision is made, and then either shows the original or applies the variant. The hiding is done via an anti-flicker snippet that adds CSS to make the page invisible until the tool resolves.
On Luma, this pattern was tolerable because Luma’s LCP was already slow. The A/B testing tool’s blocking time was a small percentage of total page render time. On Hyvä, LCP is fast, which means the A/B testing tool’s blocking time becomes a much larger percentage of the user’s experience. A 200ms anti-flicker delay that was invisible on a 4.5-second Luma page becomes painfully visible on a 1.2-second Hyvä page.
The solution is not to abandon A/B testing. The solution is to change how A/B testing integrates with the storefront.
Server-Side Variant Resolution
The cleanest pattern is to move variant assignment to the server. Instead of the browser asking the A/B testing tool which variant to show, the Adobe Commerce backend decides at request time and renders the appropriate variant directly. The browser receives the final HTML, no anti-flicker needed, no client-side decision time.
This pattern works with several modern A/B testing platforms that support server-side APIs:
- LaunchDarkly with its feature flag and experimentation SDK
- Optimizely’s server-side SDK (alongside their client-side product)
- Statsig’s server-side SDK
- Eppo’s server-side experimentation platform
- GrowthBook’s open-source server-side framework
The server-side integration adds an Adobe Commerce module that calls the experimentation platform’s SDK during request handling, attaches the variant decisions to the user’s session or visitor identity, and exposes those decisions to the template layer. Templates conditionally render different markup based on which variant is active.
The cost of this pattern is engineering investment, server-side experimentation requires a real integration, not just a copy-pasted snippet. The benefit is that Core Web Vitals are not affected. The user receives the final variant in the first HTML response.
| Pattern | LCP impact | INP impact | Engineering cost |
|---|---|---|---|
| Client-side with anti-flicker | 150-400ms added | 50-150ms added | Low (snippet only) |
| Client-side without anti-flicker | Variable flicker | 50-150ms added | Low (snippet only) |
| Hybrid: client-side decision, server-rendered variant | 50-100ms added | Minimal | Medium |
| Server-side variant resolution | None | None | High |
| Edge-based variant resolution (CDN) | None | None | High |
Edge-Based Variant Resolution
For stores running behind a CDN that supports edge computing, Cloudflare Workers, Fastly Compute@Edge, AWS Lambda@Edge, the variant resolution can happen even closer to the user. The edge function inspects the user identity, decides the variant, and modifies the cached HTML response before it reaches the browser.
This pattern is particularly useful for stores that already use a CDN heavily for cache and that want experimentation without modifying every Adobe Commerce template. The edge function can handle the variant decision in 5-15ms, which is fast enough to be invisible.
The complication is cache strategy. Each variant becomes a different cache key, which can multiply the cache footprint. The team has to think about how variants interact with the cache layer. Cloudflare’s documentation on A/B testing at the edge covers the patterns, and Fastly’s documentation on personalization at the edge covers the equivalent on their platform.
Bemeir’s Adobe Commerce performance practice has implemented edge-based experimentation for clients running heavy testing programs, and the pattern scales well once the cache strategy is sorted.
The Hybrid Pattern: Client Decides, Server Renders
For teams that want server-side rendering but cannot invest in a full server-side experimentation integration, a hybrid pattern works well. The client-side SDK decides the variant on first visit and stores the decision in a cookie. Subsequent requests include that cookie, which the Adobe Commerce backend reads and uses to render the appropriate variant directly.
The first visit still has the anti-flicker problem, but only for new visitors. Returning visitors, who are the majority of traffic for most stores, receive the final variant in the first HTML response. This pattern is a reasonable middle ground when engineering investment is constrained.
Tag Management Discipline
A/B testing tools are only one category of tag that affects Core Web Vitals. The broader tag management discipline matters. Most Adobe Commerce stores run 15-40 tags simultaneously: analytics, A/B testing, chat, personalization, recommendations, retargeting pixels, consent management. Each tag is a JavaScript file that loads, executes, and competes for the main thread.
The patterns that hold up:
- Tag manager consolidation: load tags through a single tag manager (Google Tag Manager, Tealium) so that the team can see and control everything in one place.
- Server-side tag management: tools like Google Tag Manager Server-Side and Stape move tag execution from the browser to a server-side container, reducing the client-side JavaScript footprint dramatically.
- Tag prioritization: critical tags (consent, analytics) load first. Non-critical tags (chat, recommendations) defer to user interaction or idle time.
- Tag auditing: every quarter, audit which tags are still in use and remove the ones that are not. Tags accumulate over time, and unused tags continue to load and execute.
Google’s server-side Tag Manager documentation covers the patterns for moving tags off the client. Bemeir’s Hyvä performance work routinely includes tag audits, and the Hyvä practice page covers the integration patterns.
Consent Management and Performance
Consent management platforms (CMPs) are a particular tag management trap. Many CMPs render a consent banner that holds up the rest of the page until the user clicks accept or decline. The banner itself is fine, it has to render to function, but the implementations often block all other tags until consent is resolved, which creates a serial loading pattern that delays everything.
The fix is to load the CMP first, render the banner, and allow other tags to load conditionally based on consent. Modern CMPs (OneTrust, Cookiebot, TrustArc) support this pattern, but it requires explicit configuration. Default configurations often serialize tag loading more aggressively than they need to.
Measuring the Experimentation Stack’s Impact
Track the Core Web Vitals impact of your experimentation stack the same way you track any other performance regression. The web-vitals JavaScript library captures real-user metrics that can be segmented by tag presence. A change to the experimentation platform should produce a measurable change in CrUX data over the following 28 days.
Industry benchmarks for the impact of tag stacks on Core Web Vitals are published by HTTP Archive’s annual Web Almanac and by Akamai’s State of the Internet reports, both of which provide useful baselines for what’s normal at scale.
The Pattern That Lasts
The teams that maintain green Core Web Vitals while running an active A/B testing program have one thing in common: they treat experimentation as an engineering concern, not a marketing tool to be bolted on. The investment in server-side or edge-based variant resolution pays back across every test the team runs, year after year. The shortcut of client-side anti-flicker tags pays back exactly until the marketing team starts running more than a couple of tests in parallel. After that, the gains from the Hyvä migration that justified the project in the first place start to erode, and rebuilding them requires the same engineering investment that should have happened earlier. The choice of when to make that investment is the only real question. The choice of whether to make it has already been settled by the math.
