Single-page application (SPA)

What the browser actually receives

The server sends a nearly empty HTML file — often little more than <div id="root"></div> and a script tag — plus a JavaScript bundle. The bundle boots, reads the URL, renders the right view into that empty div, and takes over the browser's history API so that clicking a link changes the address bar without a full page load.

That buys real things. Navigation feels instant because only data moves, not a whole document. State survives between views, so a half-filled form or an open sidebar does not reset. It is the natural architecture for anything that behaves like an application rather than a document: dashboards, editors, booking flows.

The costs people underestimate

Nothing exists until the JavaScript runs. The first paint is delayed by download, parse and execution of the bundle, which is why SPAs so often have poor Largest Contentful Paint on mid-range phones.

Crawlers and AI fetchers may see the empty div. Google renders JavaScript, eventually and with a budget. Many other consumers — most LLM crawlers, link preview bots, some social scrapers — fetch the raw HTML and never execute a script. If the content only exists after render, to them the page is blank. The usual fix is prerendering or server rendering the routes that need to be found.

Routing has to be handled on the server too. Deep-linking to /pricing returns a 404 unless the host is configured to serve index.html for unknown paths.

The misconception

"Single-page" describes how the app is delivered, not how it looks. A single-page application can have a hundred distinct URLs and views; the point is that they are produced in the browser rather than fetched as separate documents. Conversely, a site with one physical page and no routing is not what anyone means by an SPA.