An MPA (multi-page application) is a web application in which every navigation requests a new HTML document from the server, so the browser discards the current page and renders the next one from scratch. In web applications, the MPA is the classic model of the web: links and form submissions are handled by the browser itself, and each URL corresponds to a real document produced by the server or prepared in advance.
The term became common only after the rise of the single-page application (SPA), which keeps one document alive and swaps content with JavaScript. Today the MPA is no longer a legacy label: modern frameworks combine server-rendered pages with small interactive islands, and browser features such as cross-document view transitions have narrowed the gap in perceived smoothness.
How an MPA handles navigation
An MPA relies on the browser’s native navigation model. When a user follows a link or submits a form, the browser sends an HTTP request, receives a complete HTML response, tears down the old document, and then parses, styles and paints the new one. The server decides what each page contains, which keeps routing, data access and access control on the server.
Because each page is a fresh document, JavaScript state does not survive navigation. Anything that must persist, such as a shopping cart or a login session, lives in cookies, server-side sessions, URL parameters or browser storage. This constraint is also a strength: a crash or memory leak on one page disappears with the next navigation.
The following table traces a single navigation step by step and shows where the work happens.
| Step | Where it happens | What it involves |
|---|---|---|
| Request | Browser to server | GET for a link, usually POST for a form |
| Page generation | Server or CDN | Template rendering, database queries or a prebuilt file |
| Response streaming | Network | HTML can be streamed so the browser starts parsing early |
| Teardown | Browser | Old document, its listeners and its JavaScript heap are discarded |
| Render | Browser | Parse HTML, apply CSS, run scripts, paint the first frame |
| History entry | Browser | Back and forward buttons work without extra code |
Rendering strategies behind multi-page applications
An MPA describes how navigation works, not how the HTML is produced. The documents can be generated on every request, built ahead of time, or mixed, and the choice affects freshness, hosting cost and response time.
| Strategy | When HTML is created | Typical fit |
|---|---|---|
| Server-side rendering (SSR) | On each request | Personalized dashboards, search results, account pages |
| Static site generation (SSG) | At build time | Documentation, marketing pages, blogs |
| Incremental regeneration | At build time, refreshed on a schedule or event | Large catalogs with occasional changes |
| Edge rendering | On request, close to the user | Pages needing low latency and light personalization |
Interactivity is added on top with progressive enhancement or partial hydration. In an islands architecture, most of the page stays static HTML while only components such as a date picker or a cart widget load JavaScript, which keeps the script budget per page small.
MPA compared with SPA and hybrid models
The central difference between an MPA and an SPA is who owns navigation: the browser in an MPA, a client-side router in an SPA. That choice shifts costs between the first load and subsequent interactions, as the comparison below shows.
| Aspect | MPA | SPA |
|---|---|---|
| First load | Fast, only the current page is sent | Often slower, the application bundle loads first |
| Later navigations | Full document request each time | Data fetch and partial rerender |
| JavaScript dependence | Low, core flows work without scripts | High, routing requires scripts |
| Search indexing | Straightforward, content is in the HTML | Needs SSR or prerendering for reliability |
| State between views | Lost unless stored externally | Kept in memory |
| Accessibility of navigation | Native focus and announcement handling | Focus management must be built manually |
Many current frameworks are hybrids: they deliver server-rendered HTML on the first request and then intercept links for client-side transitions. Such applications behave like an MPA for crawlers and first visits and like an SPA afterwards, at the price of more complex hydration and caching logic.
When to choose a multi-page architecture
An MPA is the sensible default for content-heavy and transactional sites where most visits are short and enter through search or shared links. An SPA earns its complexity mainly when users stay for long sessions and manipulate rich state.
| Situation | Recommended model | Reason |
|---|---|---|
| News, documentation, e-commerce listings | MPA | Fast first render and reliable indexing matter most |
| Government and public service forms | MPA | Must work on weak devices and without scripts |
| Design tools, editors, mail clients | SPA | Long sessions with heavy in-memory state |
| Marketing site with an app dashboard | Hybrid | Static pages for visitors, client routing for logged-in users |
Performance budgets favor the MPA on low-end mobile devices, where parsing and executing large bundles can take seconds. Core Web Vitals such as Largest Contentful Paint usually benefit from server-delivered HTML, while Interaction to Next Paint depends on how much script each page still runs.
Limitations and common mistakes
The main weakness of an MPA is the visible reload between pages, which can feel abrupt in workflows with many small steps. Most problems, however, come from implementation choices rather than from the model itself.
- Ignoring HTTP caching: without proper cache headers for CSS, fonts and scripts, every page repeats downloads that should be instant.
- Shipping a full SPA bundle on every page removes the main benefit of the model and doubles the work.
- Losing form input on validation errors frustrates users; the server should return the submitted values with the error messages.
- Skipping prefetching and the back-forward cache: speculative prefetch of likely next pages and bfcache-friendly code make navigation feel near-instant.
- Duplicating validation only on the client leaves the server unprotected; server-side checks remain mandatory.
A non-technical view
An MPA works like a printed catalog with separate pages. Each time you click a link, the website hands you a brand-new page, and the old one is put away. Nothing has to be kept in memory between pages, so each page is simple and usually appears quickly.
The alternative, an SPA, is more like a single whiteboard that is constantly erased and redrawn. It can feel smoother, but it needs more preparation before the first picture appears. For most websites that people visit briefly, separate pages are the simpler and faster choice.
A concrete example
A regional public transport authority rebuilds its journey planner and ticket shop. Analysis shows that most visitors arrive from a search engine on a mid-range phone, check one timetable and leave within two minutes. The team chooses an MPA in which timetable pages are generated statically each night and the ticket checkout is rendered on the server per request.
Each page loads only a small script for the stop autocomplete, and the remaining interface is plain HTML with forms. The checkout keeps working even when scripts fail on an old browser, and timetable pages are indexed fully. The result is a fast first view on weak connections, reliable search visibility and a codebase that a small team can maintain.