Static vs Dynamic Websites: Which Fits Your Content Model?

A static website serves pages that were built before anyone asked for them. A dynamic website builds each page when the request arrives. That is the whole difference, and it is a timing difference, not a content one.

The old definition said static meant no database. That is out of date. A static site can pull from a CMS on every build and still be static. It just reads the data early. Draftbase serves content over a cached API, so either timing works from the same entries.

What Is a Static Website?

A static website ships pre-built HTML files. Each page exists on disk before the first visitor lands. A CDN copies those files to edge servers near your users.

Nothing runs at request time. There is no database call, no template render, no plugin chain. The server hands over a file.

That is why static sites are fast by default. Well-cached pages usually answer in the 100 to 300 millisecond range. (web.dev)

Static does not mean unchanging. It means built ahead. A docs site that rebuilds twelve times a day is still static.

What Is a Dynamic Website?

A dynamic website builds the page during the request. The server runs code, queries a database, fills a template, and returns HTML.

That work costs time on every visit. Dynamic pages are generally expected to stay under 500 milliseconds. (web.dev)

The payoff is freshness and personalization. A dashboard, a cart, a search result page, and a signed-in feed all need per-request work. You cannot build those ahead of time, because the content depends on who is asking.

A CDN helps less here than people expect. It cannot rescue a slow backend for content that was never cached. (web.dev)

Static vs Dynamic: The Real Comparison

Here is the split on the factors that decide real projects.

Factor	Static	Dynamic
Renders at	Build time	Request time
Typical TTFB	100–300 ms	Under 500 ms if healthy
Per-user output	No	Yes
Publish latency	Wait for a rebuild	Instant
Scaling cost	Flat, CDN bandwidth	Grows with traffic
Failure mode	Stale content	Slow or down under load

Read the last two rows carefully. They flip the usual argument.

Static sites scale almost for free. Ten times the traffic is ten times the bandwidth, and nothing else. A dynamic site pays compute for every extra visitor.

But static sites fail differently. When something breaks, visitors see old content instead of an error. That is often the better failure, which is worth naming out loud.

Which One Fits Your Content Model?

Ask one question about each page. Does this output depend on who is asking?

If no, it can be static. A blog post, a docs page, a pricing page, and a product listing all fit. Everyone sees the same bytes.

If yes, it must be dynamic. An account page, a cart, and a personalized feed all fit. The output changes per visitor.

Then ask a second question. How stale can this page get before someone complains? A marketing page can be an hour old. A stock counter cannot.

Those two answers give you the model. Most content sites end up mostly static with a handful of dynamic routes.

The Part Most Guides Get Wrong: Static Is Not Site-Wide

Almost every static-versus-dynamic guide treats this as one choice for the whole site. That has not been true for years.

Modern frameworks decide per route. Astro's hybrid output pre-renders by default, then lets a single page opt out with one export. (Astro Docs)

The build step splits routes into two piles. Pre-rendered routes become HTML files. On-demand routes ship to a serverless function instead. (Astro)

// Static by default, dynamic where it has to be.
export const prerender = false;

One line changes the model for one route. Next.js does the same thing with cache options and server components.

So the real question is not "is my site static or dynamic." It is "which of my routes need request-time work." Usually the answer is a short list.

That reframing has a practical payoff. You stop paying compute for pages nobody personalizes. Only 48% of mobile origins pass all three Core Web Vitals, and loading is where most of them fail. (Web Almanac 2025) Pre-rendering the pages that can be pre-rendered is the cheapest fix available.

Does Static Mean You Cannot Use a CMS?

No, and this is the second stale idea worth killing.

The old static site was hand-written HTML. Change a heading, edit a file, redeploy. That is what "no database" meant.

A modern static build reads a CMS at build time. Editors write in a normal admin. The build pulls entries over an API and writes HTML. Editors never touch a file.

The content is fully data-driven. The read just happens on your schedule instead of the visitor's.

That is why the CMS choice matters more than the static-versus-dynamic label. What you actually need is an API you can call from a build step, cached and keyed. Draftbase's delivery API is exactly that shape, in REST or GraphQL.

The tradeoff is publish latency. A static build means a publish waits for a rebuild. That gap is the honest cost of the model, and it is the thing to size before you commit.

When Is a Fully Dynamic Site the Right Call?

Static gets the better press. It is not always the right answer.

Go dynamic across the board when most pages differ per visitor. A social app, an internal tool, or a marketplace with live inventory all qualify. Pre-rendering a page nobody sees twice is wasted work.

Go dynamic when the page count is enormous and the traffic is thin. A million product pages with a long tail is a bad fit for a full build. You would spend hours rendering pages that get no visits that week.

Go dynamic when content must be exact at read time. Prices, stock levels, and anything with a legal or money consequence belong here. A cached page that is five minutes stale is a real problem, not a rounding error.

There is also a plain team answer. If nobody wants to own a build pipeline, a dynamic site is simpler to reason about. One code path, no build step, no cache to explain during an incident.

That simplicity is worth something. Just price it against compute cost at your real traffic, not at launch traffic.

How Do You Cut the Publish Delay?

Three options, in order of effort.

The cheapest is a webhook. The CMS fires on publish, your host rebuilds, and the new page is live in minutes. Draftbase sends webhooks on every entry event, so this is wiring, not code.

The second is incremental rendering. Only changed pages rebuild instead of the whole site. This is what makes static viable past a few thousand pages.

The third is to make that one route dynamic. If a page truly must be current to the second, stop fighting the build. Flip it and move on.

Pick the cheapest option that meets the actual requirement. Teams routinely go dynamic site-wide to solve a freshness problem on three pages.

Conclusion

Static versus dynamic is a question about timing, not about capability. Static builds pages early and serves them from a CDN. Dynamic builds them per request and pays compute each time.

For most content sites the answer is both, split per route. Pre-render everything that looks the same for everyone. Leave the rest dynamic and stop there.

That plan needs a CMS that can feed a build step and a server the same way. Draftbase serves the same MDX entries over a cached REST and GraphQL API, with webhooks to trigger rebuilds. The Hobby plan is free and Startup runs $49/mo. See the pricing page, or read how to choose a web framework next.