comparison Backend & software
Static vs dynamic website
Static pages can still be interactive. The key distinction is when and where HTML is produced for a request.
What it means
A static website can send prebuilt HTML and assets without generating a new page on each visitor request. A dynamic website commonly uses server-side code to generate or tailor responses from state, data or user context at request time. Static versus dynamic here describes the serving/generation approach, not whether the screen can respond to clicks. Web server types Rendering terminology
A static page may contain JavaScript that opens menus, filters results or calculates values in a visitor's browser. That makes the interface interactive without requiring the server to generate its HTML for every request. Client-side code
Try it
Simulation — change when work happens. Edit the synthetic source, build an output, request it, or change the local counter. Each action affects a different state. The scene uses version labels rather than real files, a database or a running server.
When does the page change?
Edit data, build, request, and interact in the browser as separate operations.
Requests read the last build, not current source data. Browser interactivity is a separate execution phase.
| Item | State / result | Why it matters |
|---|---|---|
| Source data | v1 | Editing is not deployment. |
| Built HTML | v1 | Static delivery needs a generated artifact. |
| Last response | v1 | A failed action does not fabricate a new response. |
| Browser counter | 0 | Local interaction does not regenerate server HTML. |
Version numbers and actions are synthetic. No build, API call or server is started.
About this model
The static and browser-interactive fixtures serve the last built HTML. The request-generated fixture reads current data on each request only when its runtime is available. Browser counter actions modify local state, not stored HTML or a remote database. Hybrid sites combine such boundaries.
Read the article’s primary sources for protocol rules and implementation-specific limits. This scene has no network access.
Start in static mode. Edit source changes source v1 to v2, but Request still serves the existing build v1. Build output followed by Request serves v2. Switch to request-generated mode: with the runtime available, Request can use the current source without a separate static build. Make the runtime unavailable and try again; no new successful response is invented.
| Action sequence | Static output | Request-generated output |
|---|---|---|
| Edit source, then request | Previous build remains | Current source is used when runtime is available |
| Build, then request | New build is served | A static build is not the required step in this fixture |
| Runtime unavailable | Existing files can still be served in this model | Request is blocked |
| Browser counter action | Local UI can change without replacing HTML | Local UI can also change independently |
The browser-interactive mode changes only the local counter. It does not imply a new server-rendered document or a saved database record. Remove build demonstrates that static serving still needs an output artifact. Reset restores source/build/served v1, the original mode and a zero counter.
Real sites can combine these approaches at different routes. This scene excludes caches, deployment delays, APIs, databases and framework-specific rendering policies so that build-time, request-time and browser-time work remain distinguishable. Static export Server-side rendering Browser JavaScript
Compare the same criteria
| Criterion | Prebuilt static site | Request-time dynamic site |
|---|---|---|
| HTML generation | At build/deploy time | On the server when handling a request |
| Per-user content | Needs client code, external services or separate variants | Can be produced using server-side context |
| Runtime needs | Static file serving or CDN | Application runtime and often data services |
| Updates | Rebuild or update assets for prebuilt content | Server can reflect changed data at next response |
| Attack surface | No per-request application execution at static host | More runtime, state and input-handling concerns |
| Failure modes | Missing/old asset or deployment failure | Application, database and network dependencies |
Static exports are appropriate for predictable content, documentation and many marketing pages. Personalized accounts, private updates and payment flows generally require additional backend capabilities, even if the user-facing pages are initially static. Next.js static export limitations
Hybrid designs exist
A dynamic site almost always serves some static CSS, images or JavaScript. A static page can call a separate API, and a framework can pre-render some routes while computing others. The distinction should be applied to a particular page or response, not used as a universal label for the entire business.
Static export excludes request-dependent server functions by design. Next.js's documented static mode produces files at build time, while client-side components can still run in the browser. The limits matter if someone assumes a static upload can provide authenticated server actions or a writable database without another service. Export guide
In practice
Choose prebuilt delivery when public content can be generated ahead of time, and the editorial/rebuild workflow is acceptable. Choose server-side processing when requirements genuinely depend on secrets, private data, current shared state or validated writes. In either approach, plan caching, security, accessibility, backups and rollback.
Common mistake: assuming “static” means “no JavaScript,” or assuming every dynamic page requires a separate database. Neither statement is generally true. JavaScript roles
Key takeaways
Static describes how a response is prepared, not whether its page can be interactive. Request-time generation needs the appropriate runtime and data when the request arrives. Browser code changes the local interface; persistence or external checks require a separate, deliberately implemented capability.
Sources & model boundaries
Primary references used for this explanation. The interactive example is an educational model, not a live check.
- MDN — What is a web server?
Static/dynamic web server and hosting files. HTTP server role, served files, and the distinction between static and dynamic processing.
Checked .
- MDN — What is JavaScript?
Client-side versus server-side code. Browser JavaScript can create dynamic interactions even on statically hosted pages.
Checked .
- Next.js — Static exports
Supported and unsupported features. Static HTML at build time, client interactivity and limits of a serverless static export.
Checked .
- MDN — Server-side rendering
SSR vs static generation. Build-time generation differs from generation in response to each request.
Checked .