MPA

Multi-Page Application

Updated October 6, 20263 min read

In short

An MPA is a website or web app where each link or form submission loads a new HTML page from the server, the classic way the web has worked since its start.

What is an MPA?

In a multi-page application, every page is its own HTML document. When the user clicks a link or submits a form, the browser asks the server for a new page, discards the old one and loads the new one. The server builds the HTML either ahead of time, as static files, or for each request, with a language such as PHP, Python, Ruby or JavaScript. JavaScript on the page is optional and adds interactivity on top.

Most of the web works this way: news sites, online stores, blogs, documentation and government services, built with tools such as WordPress, Django, Ruby on Rails, Laravel or Astro. MPAs are simple to build and to cache, every page has a real URL that search engines can read, the back button and scroll position work out of the box, and pages load quickly because each one carries only what it needs.

The classic drawback is the full reload: the screen briefly goes blank, shared parts such as the header are drawn again, and anything kept only in the page's memory is lost. Browsers have narrowed that gap. Cross-document view transitions animate from one page to the next, the back/forward cache restores recent pages instantly, and in some browsers speculation rules load a likely next page in advance. Libraries such as htmx and Turbo go further and swap in fresh HTML from the server without a full reload.

The opposite model is the single-page application (SPA), which loads one page and then redraws it with JavaScript. The line has blurred: frameworks such as Next.js render each page on the server like an MPA for the first load and then navigate like an SPA. Multi-page doesn't mean static, either: an MPA's pages can be generated on every request and personalized for each user.

Key takeaways

In an MPA, each navigation loads a new HTML page from the server.
It is the web's traditional model, used by most content sites and stores.
Pages work without JavaScript, have real URLs and are easy for search engines to read.
Full reloads are the main drawback; view transitions and prefetching soften them.
An SPA, by contrast, loads one page and updates it with JavaScript.

Example

Plain links and a form: each one loads a new pagehtml

<!-- Plain links: each click loads a new HTML document from the server -->
<nav>
  <a href="/">Home</a>
  <a href="/products">Products</a>
  <a href="/cart">Cart</a>
</nav>

<!-- The server answers this form with a new page of results -->
<form action="/search" method="get">
  <input name="q" type="search" aria-label="Search">
  <button>Search</button>
</form>

<!-- Animate between pages in browsers that support cross-document view transitions -->
<style>@view-transition { navigation: auto; }</style>

Readers ask

What is the difference between an MPA and an SPA?

An MPA loads a new HTML document from the server on every navigation. An SPA loads once and then fetches data and redraws the page with JavaScript, so navigation feels app-like, but the first load and SEO need more care.

Is an MPA better for SEO?

It is usually simpler, because every page arrives as complete HTML with its own URL. SPAs can rank well too, but they need server rendering or prerendering to give search engines the same content.

Should I build an MPA or an SPA?

For content sites, stores and forms, an MPA is usually simpler and faster. For highly interactive apps where users stay on one screen for a long time, such as editors or dashboards, an SPA or a hybrid framework fits better.

MPA