SPA vs MPA: Single Page vs Multi Page Applications
SPA updates a single page dynamically; MPA loads new pages for each route.
Single Page Applications vs Multi Page Applications
Single Page Applications and Multi Page Applications represent two fundamentally different approaches to building web frontends. Your choice between them affects initial load performance, navigation speed, SEO, development complexity, and the overall experience your users have when interacting with your product.
What Is a Single Page Application
A Single Page Application (SPA) loads a single HTML document once and then handles all subsequent navigation entirely within the browser using JavaScript. When a user clicks a link or navigates to a different section, the JavaScript framework intercepts the navigation, fetches only the data it needs through an API call, updates the relevant parts of the DOM, and changes the URL using the History API, all without triggering a full browser page reload. From the user's perspective, the transition feels instant because there is no blank screen between pages.
React, Vue, and Angular are the dominant frameworks for building SPAs. In each case, the server delivers a minimal HTML shell on the first request and a JavaScript bundle that contains the entire application logic. After that initial load, the application runs entirely in the browser, communicating with the server only to fetch or submit data through API endpoints.
- First load: The browser downloads and parses the full JavaScript bundle, which may be several hundred kilobytes or more. The application initialises and renders the first view. This is slower than loading a traditional HTML page.
- Subsequent navigations: Only the data needed for the new view is fetched via API calls. The framework updates the DOM in place without a full reload. Navigation feels near-instant.
- URL management: The History API allows the browser address bar to update with meaningful URLs on each navigation without triggering a server request, preserving bookmarkability and browser back and forward functionality.
- State management: Application state such as logged-in user data, UI state, and cached responses lives in JavaScript memory for the duration of the session, eliminating the need to re-fetch common data on every page visit.
What Is a Multi Page Application
A Multi Page Application (MPA) is the traditional web model that the browser was originally designed for. Every page is a separate HTML document served by the server. When a user clicks a link, the browser makes a new HTTP request to the server, which generates and returns a fresh HTML response. The browser then parses and renders that new document from scratch, replacing the entire current page in the process.
Classic web frameworks like WordPress, Laravel with Blade templates, Django with its template engine, and Ruby on Rails all produce MPAs by default. The server does the work of generating HTML, often by querying a database, populating a template, and returning the result. The browser's role is relatively simple: receive HTML, render it, and wait for the next request.
- Every navigation: Triggers a new HTTP request to the server and a full HTML response. The browser discards the current page and renders the new one.
- Server generates HTML: Business logic, database queries, and template rendering happen on the server before anything is sent to the browser.
- Browser renders fresh: Each page load starts from scratch. There is no persistent JavaScript state between pages unless cookies or localStorage are used to carry information.
- Predictable caching: Individual pages can be cached at the CDN or browser level with standard HTTP caching headers, making repeated visits fast without any special configuration.
SPA vs MPA: Full Comparison
| Feature | SPA | MPA |
|---|---|---|
| First Load Speed | Slower. The browser must download, parse, and execute the full JavaScript bundle before rendering anything meaningful. | Faster. The server returns fully rendered HTML immediately. The browser can start displaying content as it arrives. |
| Navigation Speed | Instant after initial load. Only data is fetched and the DOM is updated without a full page reload. | Slower. Every navigation requires a full HTTP round-trip, server processing, and complete page re-render. |
| User Experience | App-like, fluid transitions, no blank screens between pages. Feels like a native desktop application. | Traditional web experience with brief blank periods between pages. Acceptable for content sites but disruptive for complex tools. |
| SEO | Challenging by default. Search engine crawlers may not execute JavaScript or may index an empty HTML shell. Requires SSR or prerendering to solve. | Excellent. Search engines receive fully rendered HTML on every request with no JavaScript execution required. |
| Development Complexity | High. Requires client-side routing, state management, API integration, and careful handling of loading and error states. | Lower for content-heavy sites. Server handles routing, templating, and data fetching. Less JavaScript to manage. |
| Server Load | Lower for page rendering. The server only handles API requests for data, not full HTML generation per page. | Higher. Every navigation requires the server to generate complete HTML, which involves template rendering and often database queries. |
| Initial Bundle Size | Large. The JavaScript bundle includes the framework, routing library, and all component code. | Small per page. Each response contains only the HTML needed for that specific page. |
| Caching | API responses can be cached but full-page caching is not applicable. The HTML shell is identical for all routes. | Individual pages can be cached at the CDN edge. A cached HTML page serves instantly with no server processing. |
| Accessibility | Requires careful implementation of focus management and announcements for screen readers on client-side navigation. | Naturally accessible. Browser handles focus management and page announcements natively on each load. |
| Best For | Dashboards, social platforms, collaborative tools, SaaS applications, anything prioritising interactive experience | Blogs, marketing sites, e-commerce catalogues, documentation, any content-heavy SEO-critical site |
How to Solve the SPA SEO Problem
The SEO weakness of client-side SPAs is a solvable problem rather than an inherent limitation. Modern frameworks provide several mechanisms for ensuring search engines receive fully rendered HTML content, combining the interactive experience of an SPA with the indexability of an MPA.
- Server-Side Rendering (SSR): The server executes the JavaScript framework on the first request and returns fully rendered HTML to the browser. The browser then hydrates the page, attaching event listeners and activating the SPA functionality. Search engine crawlers receive the same complete HTML that a browser would see without executing JavaScript. Next.js and Nuxt.js support SSR natively.
- Static Site Generation (SSG): All pages are pre-built as static HTML files at deploy time rather than being generated on each request. The static files are served instantly from a CDN and are fully crawlable. This is ideal for content that does not change frequently, such as documentation, blogs, and marketing sites. Next.js, Gatsby, and Astro support SSG.
- Incremental Static Regeneration (ISR): A Next.js feature that combines SSG with the ability to regenerate specific pages in the background after a defined interval, providing fresh content without a full site rebuild for every update.
- Prerendering: A build-time technique that crawls your SPA with a headless browser, executes the JavaScript, and saves the resulting HTML. Effective for sites where the set of pages is known in advance and content changes infrequently.
- Hydration: The process of sending pre-rendered HTML from the server and then attaching the JavaScript framework on top of it in the browser to restore full interactivity. The user sees content immediately while the JavaScript loads in the background.
Popular Frameworks for Each Approach
| Approach | Framework | Language | Notes |
|---|---|---|---|
| SPA | React + React Router | JavaScript | Most widely used. Flexible and large ecosystem. Needs additional setup for SSR. |
| Vue + Vue Router | JavaScript | Approachable and progressive. Excellent documentation and gentle learning curve. | |
| Angular | TypeScript | Opinionated and full-featured. Strong choice for large enterprise teams. | |
| MPA | Laravel + Blade | PHP | Full-stack framework with built-in routing, ORM, and templating for traditional web apps. |
| Django + Templates | Python | Batteries-included framework with a powerful ORM and built-in admin interface. | |
| Ruby on Rails | Ruby | Convention-over-configuration framework that excels at rapid MPA development. | |
| Hybrid (SSR/SSG) | Next.js | JavaScript (React) | Supports SSR, SSG, ISR, and client-side rendering per route. The most popular hybrid framework. |
| Nuxt.js | JavaScript (Vue) | Vue equivalent of Next.js with the same rendering mode flexibility. | |
| Astro | JavaScript | Ships zero JavaScript by default, with optional framework islands for interactive components. | |
| SvelteKit | JavaScript (Svelte) | Full-stack Svelte framework with flexible rendering modes and excellent performance. |
The Hybrid Approach: Getting the Best of Both
The strict SPA versus MPA distinction has become less relevant as hybrid frameworks have matured. Modern frameworks like Next.js allow you to choose the rendering strategy on a per-page or per-route basis. A marketing homepage can be statically generated for maximum SEO and performance. A product catalogue can use server-side rendering to always show current inventory. A user dashboard can use client-side rendering since it is behind a login and does not need to be indexed.
This granular control means you are no longer forced to make a single architectural decision for your entire application. You can serve each part of your product in the way that best suits its requirements, combining the indexability of an MPA for public-facing pages with the interactivity of an SPA for authenticated, complex tool interfaces.
Frequently Asked Questions
- Can an SPA rank well in Google?
Yes, but it requires work. Google's crawler can execute JavaScript and index client-side rendered content, but it does so with a delay compared to indexing plain HTML. For pages where SEO is critical, server-side rendering or static generation ensures crawlers receive fully rendered HTML immediately without relying on JavaScript execution. For authenticated pages behind a login where indexing is not required, client-side rendering is perfectly fine. The general rule is to use SSR or SSG for any page that needs to appear in search results. - Is React always a Single Page Application?
No. React is a JavaScript library for building user interfaces, not an architectural pattern. By default, a Create React App project produces a client-side SPA. But React used with Next.js can server-render pages on every request, pre-render them at build time as static HTML, or any combination of the two, making it behave more like an MPA from the browser and search engine perspective. The rendering strategy is a framework decision, not a React decision. React itself is rendering-strategy agnostic. - Which approach is better for performance?
It depends on which performance metric matters most for your use case. MPAs typically have faster first contentful paint because the server delivers rendered HTML immediately. SPAs have faster subsequent navigation because only data is fetched and the DOM is updated in place. For a content site where most users arrive from search and visit a small number of pages, MPA performance is better. For a complex tool where users navigate frequently within a session, SPA navigation performance is better. Hybrid SSR approaches often provide the best overall profile by combining fast initial HTML delivery with smooth client-side navigation. - What is hydration and why does it matter?
Hydration is the process of taking pre-rendered HTML from the server and attaching the JavaScript framework on top of it in the browser to restore interactivity. The server renders the full HTML so the user sees content immediately without waiting for JavaScript. Then, in the background, the JavaScript bundle loads and the framework reconciles its virtual DOM with the existing HTML, adding event listeners and enabling all the interactive features. Hydration matters because it is the mechanism that allows hybrid frameworks to combine the SEO and performance benefits of server-rendered HTML with the interactive capabilities of a JavaScript framework. A poorly configured hydration can cause a flash of non-interactive content if the JavaScript takes too long to load. - When should I choose a SPA over an MPA for a new project?
Choose an SPA when your application requires rich interactivity, frequent client-side state changes, real-time updates, and a user experience that resembles a desktop application more than a website. Dashboards, collaborative editing tools, social media feeds, project management applications, and any tool where the user performs many actions per session are natural fits. Choose an MPA or a hybrid SSR framework when SEO is critical, when most content is publicly accessible, when the site is primarily informational or e-commerce focused, or when your team is more comfortable with server-side development. For most new projects that have both public marketing content and authenticated tool features, a hybrid framework like Next.js is the most practical choice because it handles both scenarios without forcing a compromise.
Conclusion
Single Page Applications and Multi Page Applications each represent a coherent philosophy about where work should happen and what kind of experience users should have. SPAs move rendering to the client, delivering fluid app-like experiences at the cost of initial load time and SEO complexity. MPAs keep rendering on the server, delivering fast initial loads and natural SEO indexability at the cost of full page reloads on every navigation. Modern hybrid frameworks have largely dissolved the need to make a single choice for an entire application, allowing developers to apply the right rendering strategy to each part of their product independently. Understanding the trade-offs between the two approaches and the tools available for each is foundational knowledge for any frontend developer or architect choosing how to build a new web product. Continue with website vs web application, browser rendering, and static vs dynamic content to build a complete picture of modern web architecture.