Supercharging Your A/B Tests with SolidJS

Running reliable experiments requires a framework that’s fast, reactive and easy to integrate with analytics. Solid checks all those boxes and that is why it’s our framework of choice here at Eclipse. Here are five ways Solid is well-suited for building experiments. 

1. Targeted Reactivity: Only update what changes 

One of Solid’s biggest strengths is its fine-grained reactivity. Instead of re-rendering entire components when state changes, Solid updates only the exact DOM nodes that depend on that state.

For example, we recently ran a test that redesigned our client’s search filters. As users select or deselect options, the filters update results in real time and dynamically enable or disable other filters based on their selections. Each interaction triggers multiple state changes across the UI, and Solid’s fine-grained reactivity ensures that only the affected parts update. With a heavier framework, re-rendering the entire component tree each time could introduce noticeable lag. 

Why it helps A/B testing: This level of precision keeps interactions fast and responsive, even under frequent UI changes. It prevents users from dropping off due to performance issues and allows you to confidently attribute user behaviour differences between variants to the changes you’re intending to test.  

2. Efficient Data Fetching 

Solid’s resource system (via createResource) and Suspense component make handling asynchronous data simple and reactive. You can display fallback placeholders while waiting for multiple asynchronous events to resolve and only update the dependent parts of the UI when the data comes back. 

For instance, in a recent experiment, we fetched data from an API to populate a carousel of results. Suspense waits until all data dependencies are ready before rendering everything at once. This ensured that users never saw empty or partially rendered cards, they only saw the fully populated carousel with all text, images, pricing, etc loaded.

const [products] = createResource(fetchProducts)

return (
  <Suspense fallback={<Loading />}>
    <For each={products()}>
      {(product) => <ProductCard data={product} />}
    </For>
  </Suspense>
)

‍‍

Why it helps A/B testing: Experiments often rely on dynamic data. Solid has the tools to ensure that you can safely test features that rely on multiple asynchronous data sources without worrying that staggered loads will skew your experiment results.  

3. Seamless Analytics Integration 

Solid gives you fine-grained control over experiment tracking. You can trigger events on exposures, clicks or reactive state changes with precise timing, without duplicates or delays.

For example, in a recent test, we wanted to track how many users landed on a ‘no results’ state to compare with the control version. Using Solid, we fired a data layer push when the signal representing an empty search results state returned true.  Because Solid tracks dependencies at the signal level, this event only triggered when the condition actually changed, preventing inflated or misleading metrics. 

Why it helps A/B testing: Experiments are only as good as the data you collect. When you’re pushing events to a data layer that feeds third-party analytics, it’s important to avoid spamming with hundreds of redundant events. Solid’s reactivity ensures you capture clean and meaningful data that genuinely reflect how users interact with each variant.  

4. Lean Runtime, Lightweight Delivery 

Solid has a smaller bundle size and minimal runtime overhead compared with heavier frameworks. When running tests client-side, experiment code runs on top of your existing codebase, so having a lean, lightweight framework is crucial to prevent experiments from massively slowing down your site. 

Why it helps A/B testing: A faster, smoother overall page experience means that experiment results are less likely to be influenced by framework performance. This way, you can be more confident that differences in behaviour are due to the intended changes of the experiment, not underlying performance quirks. ‍

5. Clean Conditional Rendering  

With Solid’s control flow components, Show, Switch and Match, conditional rendering is clean and intuitive. Instead of cluttering your codebase with if/else statements, these built-in components take care of what content shows when. 

For instance, our client wanted to test introducing a comparison tool on their search results page to help users evaluate multiple products side by side. Each product card included a compare button that changed state depending on user interaction - add to compare, remove from compare, or compare list full. Using Switch and Match, we dynamically rendered the correct button state in real time, keeping the UI responsive without complicated logic. 

<Switch fallback={<CompareButtonAdd />}>
  <Match when={props.compareListLength() >= content.MAX_COMPARE_ITEMS}>
    <CompareButtonFull />
  </Match>
  <Match when={props.compareStatus[props.productCode]}>
    <CompareButtonRemove />
  </Match>
</Switch>

‍

‍Why it helps A/B testing: Clear, maintainable logic inside your codebase makes it easier to scale experiments over time. Also, for client-side testing, when a winning variant is identified, the experiment code can be handed over as clean, easy-to-understand code, reducing friction when it comes to integrating it into the main codebase.

Running a successful testing program requires both technical precision and seamless user experiences. Solid delivers on both fronts, giving us at Eclipse the efficiency and reliability needed to run ambitious experiments with confidence. 

‍