Suggest an edit

Improve this article

Refine the answer for “How does SSR work with SPA routing?”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

## 1. What routing does in an SPA

In a **classic SPA** (without SSR):

- The server always serves the same file, `index.html`.
- It loads a JS bundle (for example, React Router).
- When navigating between pages, the browser **does not make new requests to the server**,
it just changes the URL and renders a different component.

The server **doesn't know** about routes at all, the client handles everything.

---

## 2. What SSR adds

With **SSR**, the server becomes a participant in the process again:

1. The user requests `/about`.
2. The server **resolves the route** (`/about` → the `<About />` component).
3. The server **renders the HTML** for that page and sends the finished markup.
4. After the JS loads, the client **hydrates** the application, and routing continues to work just like in an SPA.

> The idea is simple:
> - the first route (the first request) is rendered **on the server**,
> - every subsequent transition happens **on the client**.

---

## 3. In detail: how SSR and SPA routing interact

### Stage 1: The first request (server-side routing)

- The browser makes a request to `/products/42`.
- The server (for example, Next.js) resolves that this route maps to the `<ProductPage id={42}>` component.
- It performs SSR → generates HTML → sends it to the browser.

The user sees an already-rendered page (SSR HTML).

---

### Stage 2: Hydration

- After receiving the HTML, the browser loads the JS bundles for the routes.
- React (or another framework) hydrates the page, attaching handlers and state, and initializes the router.
- From this point on, **client-side routing works**.

---

### Stage 3: Client-side transitions (client-side routing)

- The user clicks a `<Link to="/contact">Contact</Link>` link.
- The router (for example, React Router, the Next.js router) **intercepts the click**.
- Instead of a server request:
  - the history is updated (`history.pushState()`),
  - the needed component (`<ContactPage />`) is loaded,
  - and it renders without a page reload.

The server is no longer involved, the JS in the browser does everything.

---

## 4. SSR on reload or direct navigation

If the user:

- reloads the page (`F5`),
- or navigates directly to `/contact`,

the server has to render the needed page again,
because the browser makes a **new HTTP request**.

> So SSR routing and SPA routing work like mirrors of each other:
>
> - The server handles the **initial request**.
> - The client handles **navigation inside the application**.

---

## 5. How this is implemented in frameworks

### **Next.js**

- Each page (`app/about/page.tsx` or `pages/about.tsx`) is a separate route.
- On the first request, SSR renders the page component.
- After hydration, `next/router` works like an SPA router, transitions are instant.

```javascript
import Link from 'next/link';

export default function Nav() {
  return (
    <nav>
      <Link href="/">Home</Link>
      <Link href="/about">About us</Link>
    </nav>
  );
}
```

The first navigation to `/about` goes through the server,
and clicks on `<Link>` go through client-side routing.

---

### **Remix / React Router 6.4+**

- The server and client use **the same router**.
- On the server, `createStaticHandler()` prepares the data and renders the HTML.
- On the client, `createBrowserRouter()` takes the same routes and continues SPA navigation.

---

## 6. Advantages of this approach

| Advantage | Explanation |
|---|---|
| Fast first load | SSR serves HTML instantly |
| No reload on transitions | After hydration, it behaves like an SPA |
| SEO optimization | The search engine sees ready-made HTML |
| Improved UX | Navigation is smooth, like in native apps |
| Universal routing | One set of routes works on both the server and the client |

---

## 7. Potential difficulties

| Problem | Description |
|---|---|
| The router needs to be synchronized | The same routing must work on the server and the client |
| A slow SSR render blocks TTFB | You need to use Streaming SSR |
| Hydration mismatches on routes | Different state on the server and client → mismatch |
| Auth routes | Access checks must work on both the server and the client |

---

## Summary

**SSR and SPA routing work together:**

| Stage | Who handles it | What it does |
|---|---|---|
| First request | Server | Renders the HTML for the chosen route |
| JS loading | Client | Performs hydration and initializes the router |
| Further transitions | Client | Changes routes without a reload |
| Page reload | Server | Performs SSR again |

> SSR is responsible for the **first render**,
> and SPA routing is responsible for **navigation after hydration**.

Markdown · drag & drop images · ⌘B / ⌘I shortcuts779 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.