Single-page application (SPA): plainly explained.

A single-page application (SPA) is a web app that loads a single HTML page once, then updates the content dynamically with JavaScript as the user navigates, instead of requesting a full new page from the server for every click. Gmail, Trello, and most apps built with React, Vue, or Angular work this way: the browser fetches the page shell and a JavaScript bundle up front, then swaps views in and out of the DOM without a full reload. Navigation feels instant, closer to a native app than a traditional website.

The trade-off is that the browser does more work up front, and the app needs its own routing logic to keep the URL, browser history, and back button behaving correctly, since only one document is technically served.

On the first request, the server sends a mostly empty HTML shell plus a JavaScript bundle. Once loaded, a client-side router intercepts link clicks and updates the URL and the visible content without asking the server for a new document. A minimal client-side route might look like this:

const routes = {
'/': HomePage,
'/pricing': PricingPage,
'/contact': ContactPage,
};

window.addEventListener('popstate', () => {
render(routes[location.pathname] || NotFoundPage);
});

Data that used to arrive embedded in a server-rendered page instead comes through API calls made from the browser, typically REST or GraphQL endpoints, and the interface updates as soon as the response arrives, without a visible page transition.

• Client-side rendering (CSR): the browser builds the whole page from JavaScript; fast navigation, but a slower first paint and weaker default SEO.
• Server-side rendering (SSR): the server renders the first view as HTML, then the SPA takes over; faster first paint, better indexing.
• Static site generation (SSG) with client-side hydration: pages are pre-built at deploy time, then become interactive once JavaScript loads.
• Progressive web app (PWA): a SPA that also works offline and can be installed like a native app, through a service worker and a web manifest.

React, Vue, and Angular remain the most common frameworks for building SPAs, often paired with a meta-framework such as Next.js, Nuxt, or Angular Universal to add server-side rendering when SEO or first-load speed matters.

• Render critical content on the server (SSR or SSG) whenever a page needs to rank in search results, since a purely client-rendered page can delay indexing.
• Keep the initial JavaScript bundle small and split it by route, so users are not forced to download the whole app before seeing the first screen.
• Update the page title and meta tags on every route change; without this, every view of the SPA can share the same title tag.
• Preserve normal browser behavior (back button, direct links, page refresh) through proper client-side routing, otherwise deep links can land on a blank page.

A SPA that renders everything in the browser can hurt Largest Contentful Paint (LCP) and Time to Interactive, since the page stays visually empty until the JavaScript bundle downloads, parses, and executes. Search engines can index JavaScript-rendered content, but crawl budget and rendering delays make server-side rendering or static generation the safer choice for pages that depend on organic traffic. A dashboard or an internal tool behind a login has far more freedom to stay purely client-rendered, since it is never meant to rank.

We build SPAs for clients when the product needs an app-like experience (dashboards, configurators, member areas), and we pair them with server-side rendering or static generation whenever a public-facing page also needs to rank in search results. This keeps a product fast and interactive without sacrificing indexability on the pages that drive traffic. See our web apps service for how we architect these front-ends.