Single Page Application

How an SPA works

On the first visit the browser loads the HTML shell, the CSS and the application’s JavaScript
bundle. Everything after that is client-side: link clicks are intercepted by a JavaScript router,
which updates the URL through history.pushState and renders a new component into the DOM — with no
request to the server for HTML.

Traditional multi-page site:
  /catalog → [HTTP GET] → server HTML → browser renders

SPA:
  /catalog → router.push('/catalog') → Catalog() component → DOM update

Data is fetched through API calls to the backend, but the page shell stays in place. That is the
source of the smoothness — and the source of the difficulty with third-party SDKs.

Integration problems in an SPA

Analytics. No pageview fires on a route change. Every router transition has to call
analytics.page() or its equivalent explicitly. In GA4 that is gtag('event', 'page_view', {...}).
Without it every visit looks like one endless session on a single page.

Personalization and recommendations. The personalization SDK initialises when the page loads. On
a transition inside the SPA it does not re-initialise automatically — you have to call the
re-initialisation method on the route change and pass the new page type (pdp, category,
search).

A/B testing. A test variant is applied when the SDK first initialises. If the move to the target
page happens inside the SPA, with no reload, the SDK never sees the page change and may not apply
the right variant. An explicit lifecycle hook on the route change is required.

Tip: on React or Next.js, use useEffect with pathname as a dependency to call SDK methods
when the route changes. This is the standard solution and is documented in most personalization
SDKs.

SPA, multi-page and SSR: choosing for e-commerce

For e-commerce the current standard is an SSR framework (Next.js, Nuxt) with SPA behaviour on top.
That solves SEO, gives server-level personalization and keeps navigation smooth.