SPA vs MPA

A Multi-Page Application (MPA) loads a new HTML document for page navigation. A Single-Page Application (SPA) usually loads an application shell once, then uses JavaScript to update the current document as the user moves between views.

MPA: Click link -> Request document -> Receive HTML -> Display new page
SPA: Click link -> Client router runs -> Fetch data/code if needed -> Update view

One-line idea: An MPA navigates between documents, while an SPA changes views inside the current document.

Core Concepts

What Is a Multi-Page Application?

In an MPA, each route can return a separate HTML document from the server.

GET /products
      ↓
Server returns products HTML
      ↓
User opens /cart
      ↓
Server returns cart HTML

The browser replaces the current document during navigation. Its JavaScript context and in-memory UI state normally start again unless that state was stored elsewhere.

An MPA does not have to be a simple static website. Server templates, databases, JavaScript and APIs can still produce highly dynamic pages.

What Is a Single-Page Application?

In an SPA, JavaScript usually controls navigation after the initial document loads. A client-side router maps URLs to views and updates the visible interface without requesting a complete replacement document for every route.

Initial HTML, CSS and JavaScript load
                ↓
        Application starts
                ↓
     User visits /products/42
                ↓
Router updates the URL and renders the product view

The application may fetch JSON, HTML fragments or additional JavaScript during navigation. "Single page" therefore means one active document, not one screen, one URL or no server requests.

Client-Side Routing and Browser History

An SPA can use the browser's History API to change the visible URL without loading a new document:

history.pushState({ productId: 42 }, "", "/products/42");

The router must also respond when the user presses Back or Forward:

window.addEventListener("popstate", () => {
  renderRoute(window.location.pathname);
});

Every important view should have a meaningful URL. The server must be configured so that directly opening or refreshing an SPA route returns the application entry point instead of a 404 page.

Navigation Flow

MPA Navigation

User selects a link
        ↓
Browser requests the destination document
        ↓
Server prepares and returns HTML
        ↓
Browser parses and displays a new document

The browser handles document navigation by default. Standard links can continue to work even when little or no JavaScript is available.

SPA Navigation

User selects an internal link
        ↓
Client router intercepts the navigation
        ↓
Required code and data are loaded
        ↓
The current document is updated

This can preserve application state and avoid rebuilding the entire document, which is useful for frequent, app-like interactions.

SPA vs MPA

Area	MPA	SPA
Navigation unit	New HTML document	New view in the current document
Routing	Primarily handled by the server	Primarily handled by a client router after startup
Page transition	Usually a document reload	Usually an in-place UI update
JavaScript requirement	Can work with minimal JavaScript	JavaScript is normally central
In-memory state	Usually reset during navigation	Can remain available between views
Initial payload	Often route-focused	May include a larger application runtime
Later navigation	Downloads a new document	Can load only the code or data needed
Failure isolation	A broken script may affect only enhanced behavior	A startup failure can block much of the application
Typical fit	Content and document-oriented sites	Highly interactive, stateful products

These are architectural tendencies, not guaranteed performance results. Caching, code splitting, prefetching, server speed, rendering strategy and application design can change the outcome.

Rendering, Performance and SEO

SPA Does Not Mean Client-Side Rendering Only

SPA/MPA describes navigation behavior. CSR, SSR and SSG describe how initial HTML is produced. They are related decisions, but they are not synonyms.

Rendering term	Meaning
CSR	JavaScript renders most of the view in the browser
SSR	The server generates HTML for a request
SSG	HTML is generated ahead of requests, usually during a build
Hydration	Client JavaScript attaches behavior to server-generated HTML

A framework can send server-rendered HTML for the first visit and then use SPA-style client navigation. It can also choose different rendering behavior for different routes.

Performance Trade-Offs

An MPA often sends only the assets needed for the requested page, but repeated document navigation may redo work and download shared resources when they are not cached effectively.

An SPA can provide fast later transitions because it preserves the document and application state. Its first visit can become slow when it ships too much JavaScript or waits for client-side requests before showing useful content.

Useful SPA optimizations include:

• route-level code splitting
• caching shared data and assets
• prefetching likely destinations carefully
• rendering useful HTML on the server when appropriate
• measuring JavaScript execution as well as transfer size

The correct comparison should use real measurements such as loading responsiveness, interaction latency and route-transition time rather than assuming either architecture is always faster.

SEO and Shareability

MPAs commonly return complete, route-specific HTML, which makes content straightforward for crawlers and link previews to consume.

An SPA can also be discoverable when each view has:

• a stable URL
• useful initial HTML through SSR or pre-rendering when needed
• a unique title and metadata
• crawlable links
• correct status codes and canonical URLs

SEO is therefore not exclusive to MPAs, but a client-rendered SPA requires deliberate implementation and testing.

Choosing an Architecture

Prefer an MPA When

• the product is mainly articles, documentation, listings or public content
• each route can behave as an independent document
• minimal client-side JavaScript and progressive enhancement are priorities
• simple server routing is more valuable than preserving in-memory state

Prefer an SPA When

• users perform many interactions without leaving the product
• state must remain available while moving between views
• the interface behaves like an editor, dashboard, inbox or collaboration tool
• the frontend consumes APIs and owns substantial UI behavior

Use a Hybrid Approach When

Different routes have different needs. A modern application might server-render a public product page, statically generate documentation and use client-side navigation inside an authenticated dashboard.

Public landing page -> Server-rendered or static HTML
Search results      -> Server-rendered, then enhanced
User dashboard      -> SPA-style client navigation

The better system-design question is not only "SPA or MPA?" It is: What should happen on the first visit and on later navigation for each route?

Common Mistakes

Mistake	Better approach
Saying an SPA has only one URL	Give every meaningful view a stable route
Treating SPA as another name for CSR	Separate navigation architecture from rendering strategy
Saying MPAs cannot be interactive	Add JavaScript where interaction provides value
Assuming MPAs are always fast	Measure document generation, transfer and repeated navigation
Shipping one large SPA bundle	Split code by route or feature and load it when needed
Breaking refreshes on nested SPA routes	Configure the server to return the application entry point
Replacing links with click handlers	Preserve link semantics, keyboard use and open-in-new-tab behavior
Assuming SEO is automatic	Validate HTML, metadata, URLs, links and status codes

Official References

• MDN: SPA (Single-page application)
• MDN: History API
• MDN: Fetch API
• Next.js: Linking and Navigating

Summary

An MPA navigates by loading separate documents, while an SPA keeps one document active and changes its views; modern systems often combine both ideas route by route.

User opens a route
        ↓
How should its first useful HTML be produced?
        ↓
Static, server-rendered or client-rendered
        ↓
How should later navigation behave?
        ↓
New document, in-place update or a hybrid by route