A single-page application can change screens without loading a new document. That makes the product feel fast, but it also changes how your A/B tests must work.
Traditional page testing waits for a new URL and a fresh page load. SPA testing must also detect client-side route changes, dynamic components, and events that happen after the first load. Configure Mida.so around those behaviors, then verify every route before you trust the results.
Key Takeaways
- Install the Mida tracking script across the full application, not only one route.
- Test route changes separately from traditional page loads.
- Use stable selectors and event-based goals for dynamic components.
- Check direct visits, internal navigation, refreshes, and browser history.
- Review experiment data only after assignment and conversion tracking work correctly.
Why Single Page Apps Need a Different Test Setup
A traditional website requests a new HTML document when a visitor opens another page. The browser loads the page, the testing script runs, and the experiment targets the current URL.
An SPA often loads one document and updates the visible screen with JavaScript. React Router, Vue Router, and similar tools can change the URL through the browser History API without requesting a complete page. The navigation looks like a page change to the user, but the browser has not performed a full reload. The History API documentation on MDN describes the browser behavior behind this process.
That difference creates four common testing problems:
- The test runs only on the first screen. A visitor enters through the homepage, then moves to a product route. The Mida variation never appears on the product screen.
- The test runs on the wrong route. The application changes its URL after the Mida script has already evaluated the original page.
- The target element is not ready. The route loads first, then the application renders the button, form, or pricing block.
- The conversion event fires at the wrong time. A click or form submission can happen without a full pageview to trigger tracking.
Treat every route change as its own test condition. A visitor who moves from /home to /pricing has changed context, even when the browser stays on the same document.
A new URL is not always a new page load. Your Mida configuration must account for both events.
Start by mapping the application routes, the components that appear on each route, and the actions that define success. That map becomes the test plan.
Prepare Mida.so Before You Build the Experiment
Begin with the Mida installation. Add the Mida tracking script to the shared application shell or document template so it loads on every route. In a React or Vue application, the script should not exist only inside a single page component. A visitor can enter through any route, including a campaign URL or a bookmarked checkout page.
Use the Mida A/B testing platform to create the experiment after the base script is available. Keep the first test narrow. Test one route and one main change before adding several pages or complicated conditions.
Before editing the variation, record these details:
- The route or route pattern that qualifies for the experiment
- The component or element that changes
- The audience rules
- The primary conversion event
- Secondary metrics that could expose a bad result
- The pages where the test must not run
A route pattern such as /pricing is different from /pricing/enterprise. Decide whether the test should target one exact route, a route group, or a shared component used across several routes.
Set the experiment goal around an action, not only a pageview. Examples include a pricing CTA click, completed signup, submitted demo form, or checkout start. A pageview can confirm that someone reached a route. It doesn’t prove that the variation influenced the business action.
Use a stable selector for the target element. A class created for layout can change during a redesign. A durable data attribute, such as data-testid or a dedicated experiment selector, gives the test a better target. Avoid selectors based on position, generated class names, or visible text that changes by language.
Keep your first test independent of unrelated releases. A navigation redesign, analytics migration, and pricing experiment should not ship together when you need clean results. Record the release date and commit that contains the test setup.
Build a Route-Aware Experiment in Mida
Build the experiment in a short sequence. Check each step before moving to the next one.
1. Define the entry condition
Choose how visitors enter the test. This may be a direct route visit, an internal navigation event, an audience rule, or a combination of these conditions.
A direct visit to /pricing must qualify if that is part of the plan. An internal click from /home to /pricing must also qualify if the application changes routes without reloading the page. Test both paths.
2. Choose the safest implementation method
Use Mida’s visual editor for simple changes such as copy, color, spacing, or button styling. Use custom code when the variation depends on application state, conditional rendering, or a component that appears after navigation.
Don’t use a visual edit to hide a feature that the application immediately recreates. The application can overwrite the change during its next render. For stateful components, place the variation logic where it can run after the target component exists and after the route is correct.
3. Match the current route
Configure page targeting around the route that should qualify. If your Mida workspace includes SPA or route-change settings, enable the setting for the experiment. If your implementation uses a router event, connect that event to the current Mida-supported method described in its setup documentation.
Don’t force a full browser reload with window.location to make a test run. That changes application behavior and can damage the user experience. The test should work with the application’s normal client-side navigation.
4. Protect against duplicate changes
A route can render more than once. React Strict Mode, data fetching, and state updates can all cause repeated renders. Your variation should be safe to evaluate more than once.
Use a clear marker when custom code inserts or changes an element. Check for the marker before applying the change again. Remove event listeners when the route is left if your code creates them manually.
5. Set the conversion event
Select the event that answers the experiment question. For a new pricing CTA, track the CTA click and the completed signup separately. For a form layout test, track submission rather than only the button interaction.
If the conversion happens after an API request, confirm that the event fires only after the request succeeds. A click can be recorded even when the form returns an error.
Test Mida Experiments Before Publishing
A test is not ready because the variation appears once in the editor. Run it through the same navigation paths your users take.
Use this QA table before enabling traffic.
| Test path | Expected result |
|---|---|
| Open the target route directly | The correct variant loads |
| Enter through an internal link | The route change triggers the test |
| Refresh the target route | The same user keeps the assigned variant |
| Use browser back and forward | The variation matches the active route |
| Open a non-target route | The experiment does not appear |
| Submit the main conversion | The selected goal records once |
| Resize the viewport | Layout and targeting remain stable |
| Disable slow network conditions | No broken or half-applied variation appears |
Test the control as well as the variation. The control should show the original experience, and it should not inherit styles or event handlers from the variation after a visitor changes routes.
Check the browser console for JavaScript errors. Check the Network panel to confirm the Mida script loads with the expected status. Then inspect the application state and analytics calls when the visitor navigates. Your goal is to confirm three separate facts:
- Mida loads.
- The visitor receives one assignment.
- The conversion event reaches the reporting system.
Use a clean browser profile when you need to test a new assignment. Existing cookies or local storage can keep you in the same variant. Test persistence across refreshes, but clear the test state when you need to verify the opposite variant.
Automate repeatable route checks with a browser tool such as Playwright’s end-to-end testing framework. A useful test opens the app, clicks an internal route link, waits for the target component, checks the variation, and completes the conversion action. Add the test to your release checks when the experiment affects revenue or signup flow.
Manage Results Without Mixing Route Data
Once the experiment is live, monitor the primary goal and the application behavior together. A conversion lift doesn’t help if the variation causes errors on mobile or fails for visitors who enter through a different route.
Separate route-level performance when the same experiment covers several screens. A variation can improve /pricing while reducing signup completion on /enterprise. Mida results can show the overall outcome, but route and device breakdowns help you find uneven behavior.
Connect the experiment with your existing analytics process. If your team uses GA4, review its single-page application measurement guidance alongside Mida data. The systems should agree on the basic sequence: route viewed, variant assigned, action completed.
Watch for these data problems:
- A visitor receives different variants after route changes.
- The conversion fires twice after a component re-renders.
- Direct visitors are included, but internal navigators are not.
- The test counts failed form attempts as successful conversions.
- A release changes the target selector during the experiment.
- Analytics records a route change that Mida does not target.
Don’t call a winner because of a short early spike. Let the planned audience and conversion volume accumulate. If a serious bug appears, pause the experiment, record the reason, and preserve the data already collected.
When the test ends, remove the variation code or disable the experiment through Mida. Then verify the original experience on direct visits and client-side navigation. Leaving old experiment code in the application creates unnecessary selectors, listeners, and future debugging work.
Conclusion
Single page app testing requires more than checking whether a variation appears after the first load. You need to test route changes, delayed rendering, assignment persistence, and conversion events as separate parts of the same workflow.
Use Mida.so with a route map, stable selectors, event-based goals, and a repeatable QA pass. When the app changes screens without reloading, your test process must follow that behavior. That is how you keep SPA experiment data usable and your releases predictable.
