Guides

A single-page application, or SPA, is a website that loads a single HTML document once and then updates the content in the browser as you interact, instead of fetching a brand-new page from the server for every click. The "single page" is literal: the browser never does a full page reload during normal use. Everything after that first load is handled by JavaScript rewriting the current page.

From multi-page sites to the single page

To appreciate why SPAs exist, it helps to recall the traditional model they reacted against. In a classic multi-page site, every link or form submission asks the server for a complete new HTML document, which the browser then loads from scratch — header, footer and all. This is simple and robust, but each navigation involves a visible reload and a round trip to the server, which can feel slow and disjointed.

An SPA flips this around. The server sends one HTML shell and a bundle of JavaScript on the first visit; from then on, navigating to a new "page" runs code in the browser that swaps out the relevant part of the interface and fetches only the data it needs, usually as JSON from an API. Because there is no full reload, transitions can be instant and the experience feels closer to a desktop or mobile app.

Frameworks and the appeal of SPAs

This is precisely the territory of front-end frameworks. React, Vue, Svelte and Angular all exist in large part to make building SPAs manageable, providing the components, state management and client-side routing that swap views without reloading. When you hear that a site is "built with React" or "built with Vue", it is very often an SPA — the framework is what makes the single-page model practical to build and maintain.

• SPA: loads one HTML shell, then updates content in the browser via JS
• Built with frameworks like React, Vue, Svelte or Angular
• Pros: fast, app-like navigation after the first load
• Cons: heavier first load; care needed for SEO, accessibility, routing
• SSR (Next.js, Nuxt) gives a fast first paint plus SPA navigation

The appeal is a genuinely smoother experience. Once the initial bundle has loaded, interactions are fast because the app only requests data rather than whole documents, and the interface can update fluidly without the flicker of a reload. For highly interactive products — dashboards, editors, web apps that behave like software — this responsiveness is a real and lasting advantage over the multi-page model.

The honest trade-offs

But the SPA model carries honest trade-offs that you must design around rather than ignore. The first load is heavier, because the browser must download and run a JavaScript bundle before showing meaningful content, which can hurt the experience on slow connections or modest devices. If that bundle grows unchecked, the very speed the SPA promised can turn into a slow, blank initial screen.

Search and accessibility deserve particular care. Because much of the content is rendered by JavaScript after load, search engines and tools that do not execute scripts may see an empty shell unless you take deliberate steps. Client-side routing also has to be implemented thoughtfully so that the browser’s back button, deep links and history behave the way users expect, rather than breaking in subtle ways.

Server-side rendering to the rescue

The industry’s answer to these trade-offs is server-side rendering and its relatives. Meta-frameworks like Next.js for React and Nuxt for Vue render the initial page on the server so the user — and search engines — get real content immediately, then "hydrate" it into a full SPA in the browser. This hybrid keeps the fast first paint of traditional sites and the smooth navigation of an SPA, which is why so many modern apps adopt it.

Choosing the SPA deliberately

None of this makes the SPA universally right or wrong. A content site that is mostly articles may be better served by a traditional or static approach, while a richly interactive application benefits enormously from the SPA model. The skill is in choosing deliberately, knowing that "single page" buys you fluid interactivity in exchange for a heavier first load and more responsibility for search and accessibility.

Understood this way, the single-page application is not a buzzword but a specific architectural choice with clear strengths and clear costs. It loads once, runs in the browser, and feels like an app — and when you pair it with server-side rendering, you can have much of that benefit without paying the full price. Knowing the trade-offs is what lets you reach for it at the right moment.