Episode 1 — Fundamentals / 1.2 — Client Server Architecture
1.2.f - What are Static Websites and Dynamic Websites
Big Picture: Some sites are pre-made files the server hands out unchanged; others are assembled per request from code and data. Knowing which model you are using shapes performance, cost, security, and how you update content.
1. What is a Static Website?
A static website is built from pre-built HTML, CSS, and JavaScript (plus images, fonts, and other assets) that the server serves as-is. The files are written or generated before someone visits; the host does not run your application logic just to produce the HTML for that URL.
| Idea | What it means |
|---|---|
| Same bytes for every visitor | Everyone who requests GET /about.html receives the same document (ignoring CDNs that cache the identical file in many places). |
| Printed brochure | The page is “already printed.” You are not cooking a custom page per person at the origin. |
| No server-side processing for the document | The server does not run PHP/Node/Python (or similar) to build that HTML on each request, and no database is queried to compose the file. It stores and returns pre-built assets. Interactivity can still come from JavaScript in the browser or separate APIs — “static” describes how the primary HTML is produced and served, not “no JavaScript.” |
Important nuance: A static site can still feel interactive (tabs, animations, forms that POST to an API). “Static” refers to how the primary HTML/assets are produced and served, not “no JavaScript.”
2. How Static Websites Work
Files live on a web server or — very commonly — on object storage behind a CDN. The CDN keeps copies of the same files near users globally. The browser sends an HTTP request; the edge returns the file from cache or fetches it once from origin. No database is consulted to compose that HTML file for each hit.
Request flow (browser → server/CDN)
STATIC SITE — REQUEST FLOW
┌──────────────┐ ┌─────────────────────┐
│ BROWSER │ GET /about.html │ WEB SERVER / CDN │
│ (client) │ ───────────────────────────► │ (stores files) │
│ │ HTTP request │ │
│ │ ◄─────────────────────────── │ reads file from │
│ │ 200 OK + HTML/CSS/JS │ disk / object │
│ │ (same file for everyone) │ storage │
└──────────────┘ └─────────────────────┘
│ │
│ No per-request page assembly │
│ No DB query for the HTML document │
▼
Renders HTML; runs JS in the browser if present
Why “CDN” shows up so often (same files, many edges)
STATIC FILES AT THE EDGE
┌─────────┐ ┌─────────┐ ┌─────────┐
│ CDN POP │ │ CDN POP │ │ CDN POP │
│ (EU) │ │ (US) │ │ (APAC) │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
│ same │ same │ same
│ copies │ copies │ copies
│ of │ of │ of
│ /index.html│ /index.html│ /index.html
│ │ │
└───────────────┴───────────────┘
│
ORIGIN (optional)
(canonical copy of the files)
Typical stack: Static file hosting, object storage + CDN, or platforms optimized for static assets. Caching is straightforward because the resource is immutable or content-addressed (e.g. app.a1b2c3.js).
3. What is a Dynamic Website?
A dynamic website produces or selects the response when the request happens. Server-side code may read databases, check who is logged in, apply business rules, and generate HTML or JSON that reflects the current moment.
| Idea | What it means |
|---|---|
| Generated on the fly | The HTML you receive might be different at 9:00 and 9:01, or for User A vs User B. |
| Restaurant cooking to order | The “kitchen” (app + data) prepares the meal after you order — not a brochure printed last month. |
| Server-side processing | Languages like PHP, Node.js, Python, Ruby, Java, or Go often power the application server that sits behind the web server or runs as serverless functions. |
“Dynamic” is about where/when the representation is built. A Single Page Application can also feel dynamic in the browser; the first response might still be static, SSR, or a thin shell (see CSR below).
4. How Dynamic Websites Work
The browser requests a URL. The web server forwards the request to an application. That code runs business logic, often queries a database or other services, renders a template or component tree, and returns HTML, JSON, or a redirect.
DYNAMIC SITE — REQUEST FLOW (SERVER-RENDERED HTML)
┌──────────────┐ ┌─────────────────────────┐
│ BROWSER │ GET /dashboard │ APPLICATION SERVER │
│ │ ───────────────────────────►│ (PHP / Node / Python…) │
│ │ │ │ │
│ │ │ run routing + code │
│ │ │ ▼ │
│ │ │ ┌──────────────┐ │
│ │ │ │ DATABASE │ │
│ │ │ │ (queries) │ │
│ │ │ └──────┬───────┘ │
│ │ │ │ │
│ │ │ generate HTML / JSON │
│ │ ◄───────────────────────────│ │ │
│ │ 200 OK + body │ │ │
└──────────────┘ └─────────────────────────┘
Response can differ per user, per moment, per data in the DB
Note: Many real systems cache dynamic responses (full page, fragments, or query results). Caching makes them faster but you must handle invalidation and personalization carefully.
5. Static vs Dynamic — Comparison
| Dimension | Static | Dynamic |
|---|---|---|
| Speed | Often very fast at the edge; predictable. First byte is usually “read file / cache hit.” | Variable latency: routing + app + DB + external APIs. Can still be fast with caching, but tuning matters. |
| Security | Smaller origin surface if you truly only serve files. Client JS and any APIs you call are still security-relevant. | Broader surface: app bugs, dependencies, DB, auth, sessions, file uploads, admin tools. |
| Cost | Often cheap at scale: storage + CDN; little per-request compute for the HTML itself. | Compute + DB + egress grow with traffic and feature complexity. |
| Content updates | Update by changing files and redeploying (or rebuilding if you use an SSG). | Update data in a DB/CMS; HTML/API responses can change without shipping new front-end bundles (depending on architecture). |
| User accounts | Not built-in; usually client + API or edge auth patterns. | Natural fit for sessions, roles, per-user views. |
| E-commerce | Viable for marketing/catalog as static + API for cart/checkout; heavy inventory/pricing often pushes you toward dynamic or hybrid. | Standard for cart, checkout, fraud checks, order history, personalized recommendations. |
| SEO | Strong when real HTML is in the first response (static or prerendered). | Strong when the server returns meaningful HTML; pure CSR needs extra work (SSR, prerendering, meta strategies). |
| Hosting | Static hosts, object storage + CDN, GitHub Pages, Netlify/Vercel static exports, etc. | VPS, PaaS, containers, serverless + managed DB, Kubernetes, etc. |
| Examples | Portfolios, docs, file-based blogs, landing pages. | Marketplaces, social feeds, dashboards, authenticated web apps. |
6. Examples of Each
Static (typical)
- Portfolio — fixed case studies, résumé, contact
- Blog — posts as Markdown → HTML at build time (SSG) or as plain files
- Documentation — versioned guides, API reference, search via client or external indexer
- Landing pages — campaigns, product marketing with infrequent structural change
Dynamic (typical)
- E-commerce (e.g. Amazon-class inventory, pricing, recommendations)
- Social media (e.g. Facebook-style feeds, messaging, notifications)
- Dashboards — live metrics, admin consoles
- Web apps — accounts, permissions, collaboration, CRUD on shared data
7. Static Site Generators (SSG)
What they are: Tools that turn content + templates into static HTML/CSS/JS at build time (on your laptop or in CI) before deployment. Users still download files (or CDN-cached responses), not a custom server render on every request.
How they work (conceptually):
CONTENT + TEMPLATES BUILD (CI or local) OUTPUT
(MD, MDX, CMS export…) ───────────────────────► /dist HTML, assets
│ │
└──────────────► components + data merge ─────┘
Popular SSGs and static-friendly stacks:
| Tool | Notes |
|---|---|
| Next.js | Static export / SSG routes in the React ecosystem; often paired with hybrid SSR/ISR on other routes. |
| Gatsby | React-based; large plugin ecosystem; common for content/marketing sites. |
| Hugo | Go-based; extremely fast builds; great for docs and blogs. |
| Astro | Defaults to less JS shipped; optional “islands” and multi-framework components. |
| Jekyll | Ruby-based; long-standing GitHub Pages workflow. |
| 11ty (Eleventy) | Template-engine agnostic; strong for content sites. |
How they blur the line: The output is static files, but the experience may hydrate React/Vue/Svelte, call APIs after load, or rebuild on a CMS webhook. You get static delivery with dynamic behavior after paint.
8. Server-Side Rendering (SSR)
What it is: For a given request, the server runs your UI framework (or template engine), often fetches data, and returns HTML tailored to that request — not a single prebuilt file for all contexts.
How it differs from static (SSG):
| SSG (build-time) | SSR (request-time) | |
|---|---|---|
| When HTML is produced | Before deploy (build) | When the user requests the page |
| Freshness | Stale until rebuild / incremental regen | Can reflect live data and per-user state |
| Cost model | Mostly storage + CDN | CPU and data fetching per request (unless cached) |
Frameworks commonly used with SSR: Next.js, Nuxt.js, SvelteKit — each lets you mix static segments, SSR routes, and API endpoints in one app.
9. Client-Side Rendering (CSR)
What it is: The first response is often a small HTML shell plus JavaScript bundles. The browser downloads and runs the app, then fetches data (JSON from APIs) and builds the page in the client.
SPA (Single Page Application): One main HTML entry; a client-side router swaps views without full page reloads. Typical ecosystems: React, Vue, Angular.
Trade-offs (short):
- Pros: Rich, app-like UX after load; clear split when the backend is a pure API.
- Cons: Time-to-interactive depends on JS weight; SEO and social previews need prerendering, SSR, or careful meta handling.
10. The Modern Spectrum — SSG vs SSR vs CSR vs ISR
ISR (Incremental Static Regeneration): A hybrid (especially associated with Next.js on Vercel): a page is static for speed, but can be regenerated in the background on a timer or on-demand — combining CDN behavior with fresher content without rebuilding the entire site every minute.
| Approach | HTML produced | Data freshness | Edge/CDN friendly | Complexity |
|---|---|---|---|---|
| SSG | At build time | Stale until rebuild/webhook | Excellent | Low–medium |
| SSR | Per request on server | High (subject to caching) | Good with caching strategies | Medium–high |
| CSR | In the browser after JS runs | Depends on post-load API calls | Shell can be static; data hits API | Medium |
| ISR | Static + background regen | Tunable “mostly static” | Excellent | Medium |
Real products often blend these per route (marketing SSG, app CSR, checkout SSR, etc.).
11. When to Use What?
Use this as a first pass; hybrid architectures are normal.
| Your requirement | Favor |
|---|---|
| Mostly fixed public content; lowest cost at scale; global speed | SSG or pure static + CDN |
| SEO-critical pages with frequently changing public data | SSR or ISR (or SSG + very frequent rebuilds if feasible) |
| Highly interactive authenticated app feel | CSR + API, optionally SSR for first paint or SEO |
| Per-user HTML on first load (permissions, personalization) | SSR (or edge-render patterns) |
| Docs / blog with Git or CMS + review workflow | SSG (Hugo, 11ty, Astro, Jekyll, Next SSG, …) |
Decision flowchart (ASCII)
START: What must the first HTML contain?
│
┌──────────────┴──────────────┐
│ │
Same for everyone? User/time specific?
│ │
▼ ▼
Mostly SSG / static SSR (or ISR if "mostly static")
│ │
└──────────────┬──────────────┘
│
Need app-like UX after load?
│
┌─────────┴─────────┐
│ │
Yes No
│ │
▼ ▼
CSR + hydration SSG/SSR alone may suffice
(often inside a meta-framework)
12. Key Takeaways
- Static = pre-built files (HTML/CSS/JS) served the same way to everyone — like a brochure; the server’s job is mainly store and return files, not run page-building logic per request.
- Dynamic = server-side code (e.g. PHP, Node, Python) can query databases and generate HTML or JSON per request — like cooking to order.
- Static stacks excel at speed at the edge, simplicity, and predictable cost for content that changes on a publish cadence.
- Dynamic stacks excel at auth, personalization, transactions, and live business data tied to each request.
- SSG builds HTML at build time; SSR builds HTML at request time; CSR builds UI in the browser; ISR refreshes static pages on a schedule or trigger.
- Modern frameworks often let you pick per route — the skill is matching the rendering model to the requirement, not choosing a single buzzword.
Explain-It Challenge
Without looking back, explain to an imaginary friend:
- Why a printed-brochure analogy fits a static site, and what changes once you add client-side JavaScript that calls a login API (is the site still “static” in the usual sense?).
- One reason CDNs are a great match for static files, and one reason personalized dynamic pages are harder to cache safely.
- How SSG and SSR differ in when HTML is created, and when you would choose ISR instead of rebuilding the whole site on every content change.
If you can do that in under two minutes, you own the idea.