Key takeaways
- A single-page application builds pages in the browser; a multi-page application gets a new page from the server for each URL.
- Public, search-facing, content-led sites usually fit a multi-page or hybrid architecture.
- Logged-in, interactive tools used for long sessions usually fit a single-page application.
- Hybrids, such as server rendering with hydration, islands, or a split by section, let you use each where it fits.
- If you build an SPA with public pages, render them on the server, use real URLs, set titles per page and return correct status codes.
- Measure performance on the devices and networks your users actually have.
Whether to build a single-page application (SPA) or a multi-page application (MPA) is one of the first architecture decisions on any web project, and one of the most expensive to reverse. It shapes how fast the first page appears, how search engines see the site, how the code is organised and what the team needs to know.
There is no architecture that is better in general. There is one that fits your project better. What each one is comes first, then the project traits that should decide it, the hybrid options that let you mix them, and the SEO details a single-page application has to get right.
What is a single-page application?
A single-page application loads one HTML page once and then uses JavaScript in the browser to draw each screen and fetch data as the user moves around, without loading a new page from the server. The address bar still changes, but the browser never does a full page reload.
How it works, in practice:
- The first request returns a small HTML shell and a JavaScript bundle.
- The JavaScript builds the interface, asks the server’s API for data, and renders the view.
- When the user clicks a link, a client-side router swaps the view and updates the URL using the browser’s History API.
- From then on, only data travels between browser and server, usually as JSON.
SPAs are usually built with a front-end library or framework such as React, Vue, Angular or Svelte, talking to an API built separately.
Where they fit well: dashboards, editors, design and project tools, chat and collaboration apps, and admin panels. These are products people log into and use for long sessions, where fast, app-like movement between views matters more than the first load.
What is a multi-page application (MPA)?
A multi-page application serves a separate HTML page from the server for each URL, so every click on a link loads a new, complete page. It is how the web has always worked, and it remains the default for most content on the web.
The pages can be produced in different ways:
- Server-rendered on each request, by a back-end framework such as Django, Ruby on Rails, Laravel or Express on Node.js.
- Pre-built as static files, by a static site generator, and served from a CDN.
- A mix, with most pages static and some rendered on demand.
Where they fit well: marketing sites, blogs, documentation, news and research publishing, and most online stores. These are sites people often reach from a search result or a shared link, read for a while and leave.
How do single-page and multi-page applications differ in practice?
They differ mainly in where the page is built: in the browser for an SPA, and on the server or at build time for an MPA. That one choice affects the first load, navigation, search visibility, state, offline use and how the code is organised. The table sets the two side by side, with three traits that matter either way at the end.
Neither column wins outright. Which rows matter most depends on who your visitors are and what they come to do, which is what the traits below sort out.
Public site and an app?
Tell us where your visitors come from and what they do once they sign in, and we’ll talk through which architecture fits each part.
How to choose: the project traits that decide it
Choose by listing your project’s traits and seeing which way each one pushes. Most projects have a clear answer once the traits are written down; when they genuinely pull both ways, that is usually a sign the product should mix both.
Traits that point towards a multi-page application:
- Most visitors arrive from search, social posts or shared links.
- The main job is reading content: pages, articles, product listings, reports.
- Many visitors use mid-range or older phones, or slow mobile networks, where heavy JavaScript costs the most.
- Pages need reliable link previews and indexing from day one.
- Content is updated by editors in a CMS rather than by users in the app.
- The team’s strength is server-side development.
Traits that point towards a single-page application:
- Users log in and stay for long sessions, moving between many views.
- The interface is highly interactive: drag and drop, live editing, real-time updates, complex filters.
- The app needs to work offline or on a poor connection after the first visit.
- Search visibility for the app’s screens doesn’t matter, because they sit behind a login.
- The same API will also serve a mobile app or third parties.
- The team’s strength is front-end JavaScript development.
Hosting, accessibility and analytics matter whichever way you go; they are the last three rows of the table above. If you are also choosing the framework itself, our guide on how to choose a web framework covers that decision in more detail.
Hybrid options: you rarely have to pick just one
Modern frameworks let you mix the two: pages that arrive as complete HTML like an MPA, then behave like an SPA where it helps. For many projects, a hybrid is the right answer. These are the five common ways to do it, with the tools usually named for each.
Browsers are also closing the gap from the MPA side. Cross-document view transitions let a multi-page site animate between pages, though browser support is still growing, so treat them as an enhancement rather than something the design depends on.
What does an SPA need to rank in search?
A single-page application needs its important content in the HTML that crawlers receive, real URLs for every view, its own title and description per page, correct status codes and normal links. Google can render JavaScript, but rendering can happen later than crawling, and not every crawler renders JavaScript at all. Check your SPA against the seven tests below.
If an SPA’s pages sit behind a login, most of this matters less, because those pages shouldn’t be indexed anyway. Focus the SEO effort on the public pages around it.
Performance: what to watch in each
Each architecture has its own performance risks, and both can be fast or slow depending on how they are built.
For a broader look at diagnosing slow pages and slow apps, see our guide to speed up a slow web app.
How we’d choose the architecture for a project
We’d start from the project’s traits, not from a favourite framework. We’d list where visitors come from, what they do on the site, which pages must rank, what devices and networks they use, whether there is a logged-in product, and what the team that will maintain it knows. Then we’d pick the simplest architecture that fits: often a multi-page or hybrid site for public pages, and a single-page app for a logged-in tool, each on its own part of the domain. Our own site is an example: tailwebs.com is a multi-page site built with Astro, because every page is public and has to rank in search, and there is no logged-in area.
If you are planning a product that needs both, our web application development service covers the build, and our page to choose a technology by project sets out the options. For server-rendered front ends and APIs, see Node.js development.