Architecture
Single Page Applications: What You Gain and What You Give Up
Updated July 15, 2015By the CalliArc team
Key takeaway
Single page applications are the right choice for interaction-heavy, logged-in tools where users stay a while. For content and marketing pages they add initial load time, SEO complexity, and accessibility work in exchange for benefits those pages don't need.
The single page approach — loading an application shell once and updating it with data rather than reloading pages — has become the default for new web work. It's excellent for some things and a poor trade for others.
What you gain
- Fast, app-like interaction after the initial load, with no full page refresh between views.
- State that persists across navigation — filters, unsaved input, open panels.
- A clean separation between the interface and an API that mobile clients can share.
- Rich interactivity that's genuinely awkward to build with full page loads.
What you give up
- Initial load: the browser downloads and executes a large bundle before anything appears, which is felt most on slow connections and modest devices.
- Search visibility — content rendered only in the browser is harder for crawlers, and server-side rendering to fix it is a real engineering commitment.
- Things the browser did for free: navigation, history, focus management, and page titles all become your responsibility.
- Accessibility work, because route changes don't announce themselves to screen readers unless you make them.
- Error handling — a failed request no longer produces a browser error page; you must design every failure state.
Decide per surface, not per product
- Marketing pages, documentation, blog, and support content: server-rendered pages. Fast first load, indexable, simple.
- Logged-in application where users work for extended sessions: single page application earns its cost.
- Checkout and signup: prioritise speed and reliability over interactivity; these are the pages where a heavy bundle costs money directly.
- Mixing the two is normal and sensible. There's no requirement for one answer across a whole site.
If you build one, do these
- Code-split by route so the initial bundle carries only what the first view needs.
- Update the page title and move focus on route change, for both accessibility and basic usability.
- Handle loading, empty, error, and offline states explicitly on every view — they're the majority of real states.
- Keep URLs meaningful and shareable; a single page application without proper routing is a step backwards.
- Measure real-world load on a slow connection, not on your development machine.