Catalog
concept#Architecture#Software Engineering#Integration#Platform

Single Page Applications (SPA)

Web architecture pattern where a single HTML page is loaded and content is dynamically updated client-side.

Single-page applications (SPAs) are web applications that load a single HTML page and dynamically update content using client-side JavaScript.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Intermediate

Technical context

Content Delivery Networks (CDNs)API gateways and backend servicesClient monitoring (RUM) and error tracking

Principles & goals

Clear separation of client and server responsibilitiesProgressive enhancement for critical contentDefine measurable performance and SEO goals
Build
Domain, Team

Use cases & scenarios

Compromises

  • Slow initial load due to large bundles
  • Broken client-state synchronization with backend
  • Security risks from incorrect client-side authorization
  • Code-splitting and lazy-loading for critical paths
  • Server-side rendering or pre-rendering for SEO-critical pages
  • Automated performance monitoring and budget alerts

I/O & resources

  • Design system and UI component library
  • Backend APIs (REST/GraphQL) with clear contracts
  • Build and CI pipeline for client bundles
  • Client-side app with routing and state management
  • Optimized bundles, caching strategies and monitoring
  • Documented SEO and PWA configuration

Description

Single-page applications (SPAs) are web applications that load a single HTML page and dynamically update content using client-side JavaScript. They centralize routing and state in the browser to create fluid, app-like interactions. SPAs trade server-rendered simplicity for richer interactivity and require considerations for SEO, performance, and routing.

✔

  • Smoother, app-like user experience
  • Reduced roundtrips for navigations
  • Fine-grained UI updates without full page reloads

✖

  • SEO challenges without server-side rendering
  • More complex build and deployment pipelines
  • Higher client resource usage on weak devices

  • Time to Interactive (TTI)

    Time until the page is fully interactive; important for user perception.

  • First Contentful Paint (FCP)

    Time until first visible element; measures perceived load speed.

  • Route change latency

    Duration of an internal navigation change without full reload.

Gmail (UI portion)

Mail interface partially implemented as an SPA with strong client interaction.

Google Maps Web

Interactive map application with extensive client-side updates.

Trello

Project board with fluid drag-and-drop interactions implemented as an SPA.

1

Decide architecture: SPA with SSR, SSG or pure CSR

2

Choose state management strategy (local, global, server-state)

3

Set up build pipeline and bundle optimization

4

Implement progressive enhancement and SEO measures

5

Define monitoring, tests and rollout strategy

⚠️ Technical debt & bottlenecks

  • Old, untrimmed libraries increase bundle size
  • Lack of component separation leads to hard-to-maintain code
  • No automated performance regression testing
Initial load timeClient memory usageAPI latency for dynamic data
  • Using SPA for purely informational, SEO-critical marketing site
  • Rolling out untested large bundles to production
  • Not implementing fallbacks for slow connections
  • Overlooking accessibility impacts of dynamic DOM changes
  • Missing handling strategy for broken client state
  • Insufficient caching strategies for API responses
Experience with modern JS frameworks (React, Vue, Angular)Knowledge of bundling, code-splitting and CI/CDBasic understanding of SEO, accessibility and performance
Requirements for interactivity and latencySEO and indexability requirementsScalability of API load and caching strategies
  • • Requirement for modern browser capabilities
  • • Limited bandwidth on mobile networks
  • • Corporate policies on SEO and accessibility