What is a SPA and what your site gains (and loses) with it
Published on 2026-09-12 by frfrand
Una sola página que se reescribe sola: qué problema resuelve, por qué rompió el botón de atrás durante años, qué pasa con el SEO y cuándo conviene no usarla.
SPA stands for Single Page Application: single-page application. The name describes the mechanism, not the experience.
There is a single HTML document. When you navigate, no new page is requested: JavaScript intercepts the click, requests the data it needs, and rewrites part of what is already on screen.
What problem it came to solve
In the classic web, every click discards everything and starts from scratch. That is perfect for reading articles and uncomfortable for working.
If you are on a panel with a filter applied, a sidebar open, and a form half-filled, every full navigation erases all that context. SPAs appeared so that the web would be more like a desktop application, where the state survives.
What you gain
Blink-free navigation. Once loaded, switching sections is instant: only a small JSON travels, not an entire document.
State survives. A player that keeps playing while you navigate, a cart that is not lost, a filter that remains applied.
The server sends less. It returns data, not HTML. That same thing serves for the mobile app without duplicating anything.
What you pay
The first load. You have to download the JavaScript and execute it before seeing anything. On a good connection it is milliseconds; on an old phone with a slow network it can be several seconds of blank screen.
You take responsibility for the browser. Everything the browser used to do for free is now your responsibility: the back button, history, tab title, scroll position when switching screens, loading and error states.
For years, SPAs had a bad reputation precisely because of this: they broke the back button. Today, routers handle it well, but it’s still something you have to do on purpose.
The content is not in the HTML. This affects two different things that are often confused:
- Search engines: Google executes JavaScript and indexes just fine, though more slowly. It’s not the disaster it used to be.
- Link previews: here it really hurts. When you paste a link into a chat or social media, the preview card almost never runs JavaScript. If your title and description are set by script, the preview comes up empty. This is the most common problem and the least anticipated.
The solution almost everyone uses
Prerendering: generate, at publish time, an HTML version of each public route with its title, description, and content.
Visitors get the full SPA and still enjoy instant navigation. Search engines and preview generators get real HTML. No need to choose.
This is exactly what we do on the ArduMaker site: each public route is prerendered at build time, and the app mounts on top when the browser finishes loading.
When it doesn’t make sense
If your site is content to read (a blog, documentation, a landing page), the SPA adds complexity without benefit. A static site generated at publish time is faster, cheaper, and harder to break.
The simple rule: if people read it, you don't need an SPA. If people work inside it, they probably do.
