← Dashboard

Web Foundations · Reference

Web Application Concepts

Rendering models & vocabulary · 6 min read

Web Application Concepts

Status: living reference (extended as the research proceeds) Last updated: 2026-06-16 Scope: foundational vocabulary for the rest of the web research — what the terms mean, how the pieces fit, and the trade-offs behind them. Start here; the framework and meta-framework pages assume these concepts.

This page is intentionally a growing glossary-with-context. Today it covers rendering models (SPA / CSR / SSR / SSG / prerendering). Future sections: state management, data fetching, auth, caching, accessibility, performance budgets, build/bundling.

The one question everything hangs on

Every rendering strategy is an answer to: where and when is the HTML produced?

  • Where — on the user's browser (client) or on a server/build machine.
  • When — at build time (once, ahead of time), per request (on the server), or live in the browser (at runtime).

That's the whole axis. The named strategies below are just points on it.

SPA — Single-Page Application

A SPA is an architecture where the browser loads one HTML page (a near- empty shell) plus a JavaScript bundle, and from then on JavaScript renders every screen and handles navigation without full page reloads. Clicking a link doesn't fetch a new HTML document — the router swaps the view in place and the URL is updated via the History API.

Traditional site (MPA):  click → server returns a whole new HTML page → full reload
SPA:                      click → JS swaps the view, fetches only data (JSON) → no reload

What you get: app-like fluidity, instant in-app navigation, rich client state. What it costs: a larger initial JS download, a blank screen until the JS boots (poor first paint), and SEO/accessibility work that server HTML gives you for free. React and Svelte are both typically deployed as SPAs when used without a meta-framework.

A SPA is rendered using CSR (below). The terms are often used interchangeably, but precisely: SPA is the app shape, CSR is the rendering technique it uses.

The four rendering strategies

CSR — Client-Side Rendering

The server sends a minimal HTML shell; the browser downloads JS, runs it, and builds the DOM. This is the classic SPA model.

  • Pro: cheap/simple hosting (static files + an API), fluid navigation, heavy interactivity.
  • Con: slow first paint (nothing visible until JS loads and runs), weak SEO without extra effort, more work on low-end devices.
  • Best for: authenticated dashboards, internal tools, app-like UIs where first-paint SEO doesn't matter.

SSR — Server-Side Rendering

For each request, a server runs the components and returns fully-formed HTML, which the browser shows immediately; JS then hydrates it (below) to make it interactive.

  • Pro: fast meaningful first paint, good SEO, per-request fresh/ personalized content.
  • Con: needs a running server (cost, ops), higher TTFB than static, hydration cost on the client.
  • Best for: content that must be fresh and indexable — storefronts, dashboards with SEO needs, personalized pages.

SSG — Static Site Generation (a.k.a. prerendering)

HTML is generated once at build time and served as static files from a CDN. Every visitor gets the same pre-built HTML; JS hydrates it for interactivity.

  • Pro: fastest possible delivery (static files on a CDN), cheapest hosting, excellent SEO, no server to run.
  • Con: content is only as fresh as the last build; not suitable for per-user/per-request data without client-side fetching on top.
  • Best for: docs, blogs, marketing sites, and — as in our own KB app — content known at build time.

"Prerendering" usually means SSG: rendering pages to HTML ahead of time. (Confusingly, it's also used for Partial Prerendering — see below.)

Hybrid & modern variants

The lines blur; meta-frameworks let you pick per route:

  • ISR (Incremental Static Regeneration) — SSG pages that re-build in the background on a schedule or on-demand, so static content can stay fresh without a full rebuild.
  • Streaming SSR — the server flushes HTML in chunks as it's ready, so the user sees content sooner (and <Suspense> boundaries fill in progressively).
  • PPR (Partial Prerendering) — a single page combines a static prerendered shell with dynamic parts streamed in per request. Next.js's current direction ("Cache Components").
  • Islands architecture — ship a static HTML page and hydrate only the interactive "islands," leaving the rest as zero-JS HTML. Astro's model; minimizes client JS.
  • RSC (React Server Components) — components that run only on the server and send no JS for themselves; see react.md.

Hydration — the concept that ties SSR/SSG together

When HTML is produced on the server or at build time, it's just markup — the buttons don't do anything yet. Hydration is the client-side step where the framework downloads its JS, walks the server-rendered DOM, and attaches event handlers and state to make it interactive.

Hydration is why "server-rendered" doesn't mean "no JS": you pay for the HTML and the JS. The cost of hydration (downloading + executing JS to "wake up" the page) is precisely what islands, RSC, and Svelte's small output aim to reduce. Approaches like resumability (Qwik) try to skip hydration altogether by serializing the needed state into the HTML.

Side-by-side

CSR / SPA SSR SSG / prerender
HTML built In the browser On a server, per request At build time
When Runtime Per request Once, ahead of time
First paint Slow (after JS) Fast Fastest (from CDN)
SEO out of the box Weak Strong Strong
Server needed No (static + API) Yes No (CDN)
Data freshness Live (client fetch) Live (per request) As of last build
Hosting cost/ops Low Higher Lowest
Best for Apps, dashboards, internal tools Fresh + indexable content Docs, blogs, marketing, known-at-build content

Performance vocabulary (you'll see these everywhere)

  • TTFB (Time To First Byte) — how long until the server starts responding.
  • FCP (First Contentful Paint) — first time something renders.
  • LCP (Largest Contentful Paint) — when the main content is visible; a core Web Vital.
  • TTI (Time To Interactive) — when the page actually responds to input (after hydration). SPAs often have a gap between FCP and TTI — it looks ready before it is.

How this maps to our research

  • React and Svelte can both do all of the above — but only the bare library gives you CSR/SPA. SSR/SSG/streaming/islands come from a meta-framework (Next.js, SvelteKit, …). See meta-frameworks.md.
  • For long-lived, safety-adjacent internal apps, a CSR SPA + JSON API (paired with our .NET/ASP.NET backend) is often the simplest, most self-hostable choice — no Node server to run in production, no SSR ops. SEO rarely matters for authenticated line-of-business UIs.
  • Reach for SSR/SSG only when first-paint SEO, public content, or strict load-time budgets justify the added moving parts.
  • Our own KB app is a concrete example: it's prerendered (SSG) — pages built once, served as static files, markdown rendered at build time.

Sources