Skip to content

SPA, MPA, and Hybrid Navigation Architectures

When designing web applications, terms like SPA, MPA, and Hybrid often get mixed together. In practice, building a web app involves four distinct choices: how the browser navigates between pages, where the HTML comes from, how URLs are routed, and how new data reaches the screen.

I put this guide together to explain how these parts work together, what happens in the browser during page transitions, and how to choose the right setup for your project.

Navigate this post

How browser navigation works

When a user moves between pages, the browser handles the transition in one of two ways:

  • Cross-document navigation (Full page load): The browser throws away the current page, fetches a new HTML document from the server, and renders it from scratch. This is how standard links work.
  • Same-document navigation (Client-side routing): The browser keeps the current page open in memory. JavaScript updates the content on the screen and changes the URL in the address bar using the browser's History API (history.pushState).
---
title: "Browser Navigation Paths"
---
flowchart TB
    accTitle: Browser navigation paths
    accDescr: Navigation either reloads the entire document or updates the current page in place using JavaScript.

    A["User clicks a link"] --> B{"Keep the current page open?"}
    B -->|"No"| C["Fetch new HTML from server"]
    C --> D["Reload and render a fresh page"]
    B -->|"Yes"| E["JavaScript intercepts the click"]
    E --> F["Fetch data and update the page content"]
    F --> G["Update the URL in the address bar"]

Keeping the current page open allows in-memory data to stay alive across page transitions. Active audio playback, unsaved form drafts, open chat boxes, and map views continue running without interruption. With full page reloads, that state resets unless it is saved to a database, cookies, or local storage.

The four core decisions

Building an application requires answering four separate questions:

Decision Question Common Choices
1. Server output What does the backend return? Static files, generated HTML, or JSON APIs
2. First render Where is the first screen built? On the server, during a build step, or in the browser using JavaScript
3. Navigation How do links work inside the app? Full browser page reload or JavaScript-based in-place updates
4. Data updates How does new data reach the page? Full HTML pages, small HTML chunks, or JSON payloads

These choices can be combined in many ways:

  • A framework like Next.js or Remix renders the first page on the server, sends it to the browser, and then uses client-side JavaScript for subsequent link clicks.
  • A tool like HTMX or Turbo keeps standard server-rendered HTML, but swaps out specific parts of the page when links or buttons are clicked without a full browser reload.

What is Hydration?

Hydration is the step where browser JavaScript attaches event listeners (like click handlers) to HTML that was already created by the server.

Common navigation setups compared

Setup Route Transitions First Page Load Subsequent Updates Main Consideration
Traditional Multi-Page (MPA) Full page reload per link Server-rendered HTML Full page reloads State resets on each click
Single-Page App (SPA) In-place updates via JavaScript Empty HTML shell + JS file JSON API calls Slower first load; direct URLs need server setup
Enhanced Multi-Page (Hybrid) In-place updates for internal links Server or pre-built HTML HTML fragments or swapped content Custom scripts must re-run after content swaps

Example: instant navigation in MkDocs

This blog uses a hybrid setup. MkDocs builds a separate, static HTML file for every post during the build step. A direct visit loads quickly from static storage without needing a backend server.

To make clicking between posts faster, Material for MkDocs includes an instant navigation setting:

mkdocs.yml
theme:
  features:
    - navigation.instant

When this is enabled:

  1. Opening a direct link or refreshing the page loads the full static HTML document.
  2. Clicking links inside the site fetches the next page in the background and replaces the main content area without a full browser reload.
  3. Page flicker is eliminated, and scroll positions are managed smoothly.

Because the page stays open during these transitions, any custom scripts must listen for page-swap events instead of the standard DOMContentLoaded event.

How to choose a setup

Use these guidelines to pick the right approach:

  1. Check your state requirements: If your app needs continuous background processes—such as active audio playback, persistent chat, or complex dashboard filters—use same-document navigation.
  2. Consider first-load speed and search visibility: If fast initial loading, public search indexing, or simple sharing are top priorities, generate your initial HTML on the server or during your build step.
  3. Choose your data style: If your backend handles most of your business logic, returning HTML fragments keeps your frontend simple. If you have rich, highly interactive components, JSON APIs paired with a frontend UI library are effective.
  4. Ensure direct URLs work: Make sure every link works when opened directly in a new tab or shared with someone else.

Conclusion

Web architecture is a set of modular choices: where your HTML is created, how data travels, and how the browser handles transitions between links.

For most content-heavy sites and dashboards, combining pre-rendered HTML with smooth in-place page navigation gives you fast load times while keeping page transitions responsive and clean.

References and further reading

Open the complete reference catalog

Primary Sources