What is a Single Page Application (SPA)?
A single page application (SPA) loads one web document and then updates its content with JavaScript, usually by fetching data from an API, instead of asking the server for a new HTML page on every click. The address bar still changes and the back button still works, because the app manages the URL itself. MDN defines it the same way and notes the costs: SEO, state, navigation and performance monitoring all take more effort than on a classic multi-page site.
How an SPA works
- The browser requests the page and the server returns a small HTML shell plus references to JavaScript bundles.
- The browser downloads and runs the bundles, and the framework renders the first view in the browser. This is client-side rendering.
- Clicking a link is intercepted by a client-side router, which updates the URL with the History API and renders the next view without a new document request.
- Each view fetches the data it needs from your backend, typically JSON over HTTP.
So the first load pays for downloading and running the app, and every later navigation is only an API call plus a render.
SPA vs multi-page application (MPA)
| Aspect | SPA | MPA |
|---|---|---|
| Navigation | Client-side, no new document | Server returns a full HTML page |
| First load | Waits for JavaScript | HTML is readable immediately |
| Later navigation | Fast, only data is fetched | Full request per page |
| Search crawling | Needs JavaScript rendering | Content is in the HTML |
| Best fit | Dashboards, editors, tools behind a login | Content sites, blogs, marketing pages |
The line is blurry now. Frameworks such as Next.js render on the server first and then hydrate into an SPA in the browser, so a site can have both.
SPAs and SEO
Google renders JavaScript with a headless Chromium, but it does so in a separate step after crawling, and it can only follow links that are real <a href> elements. Google's JavaScript SEO basics also say that server-side rendering or prerendering remains a good idea because it is faster for users and not every crawler runs JavaScript. Three practical points from that guide:
- Use real paths with the History API, not
#/fragmentroutes. - A client-routed app cannot send a real 404 status for a missing page by itself. Redirect to a URL that returns 404, or add a
noindexrobots tag, so missing pages are not indexed as soft 404s. - Do not block your JavaScript files in robots.txt.
Example
A project management tool is a typical SPA. After login the user opens a board, drags a card and edits a comment, and each action calls an API without a page load. The marketing site for the same product is a poor SPA candidate: it needs fast first paint and crawlable text, so it is better served as static or server-rendered HTML.
Common mistakes
- One huge bundle. Shipping every route up front delays the first view. Split code by route and lazy-load heavy components.
- Building marketing pages as a pure SPA. Crawlers and slow devices get an empty shell first.
- Broken history. Views that do not push a URL make the back button, bookmarks and sharing fail.
- No loading or error states. A blank screen while data loads feels broken. Use skeletons and error boundaries so one failed component does not take down the app.
- Measuring only the first load. In an SPA most of the experience happens after navigation, which a one-off page test does not show.
Testing and monitoring an SPA
An SPA moves work to the browser and turns your backend into an API, so test both halves.
- Rendering speed: track Largest Contentful Paint and the other Core Web Vitals. LoadFocus page speed monitoring runs Lighthouse from cloud locations on a schedule, and real user monitoring shows what visitors actually experience across client-side navigations.
- API capacity: every view is an API call, so a traffic spike lands on your backend. LoadFocus load testing runs JMeter and k6 scripts from more than 25 cloud regions. These tools work at the protocol level and do not execute your frontend JavaScript, so they measure the APIs the SPA calls, not browser rendering.
For a step-by-step approach, read how to optimize load testing for single page applications.
FAQ: Single Page Application
Are SPAs bad for SEO?
Not by definition, but a pure client-rendered SPA gives crawlers an empty shell until JavaScript runs. Server-side rendering or prerendering, real URLs and proper status codes remove most of the risk.
Does Google index SPAs?
Yes. Google runs JavaScript with a headless Chromium before indexing. Rendering happens as a separate step, so content that must be indexed quickly is safer in the initial HTML.
What is the difference between an SPA and client-side rendering?
Client-side rendering is how content is drawn: in the browser, with JavaScript. An SPA is an application style with one document and client-side navigation. Most SPAs use client-side rendering, but an app that is rendered on the server first and then takes over navigation in the browser is still an SPA.
What is the difference between an SPA and a PWA?
A progressive web app adds installability, offline support and service workers to a web app. Many PWAs are SPAs, but an SPA is not automatically a PWA.
When should I not build an SPA?
For content-led sites such as blogs, documentation and marketing pages, where fast first paint and search visibility matter most. Static or server-rendered pages fit better there.
Related terms
Related LoadFocus Tools
Put this concept into practice with LoadFocus, the same platform that powers everything you just read about.