Static generation or server rendering.

With static generation the HTML is prepared at build time; with server rendering it is produced again on every request — the difference is not speed but how often the content changes.

The decision looks like a technology preference, but it is really a question about content: how often does the page change, and is it different for every visitor? The answers to those two questions determine the architecture; speed is a consequence, not a cause.

What static generation really buys

On a static page the only thing the server does is send a file. No database query, no template compilation, no application start-up. The time to first byte is low for that reason and, more importantly, PREDICTABLE — it does not change when traffic rises.

The second gain is a narrow failure surface. With no running application server there is no application to crash, no connection pool to exhaust and no runtime to patch. The measured time to first byte for this site and the three projects it manages is under 300 milliseconds, and that is the result of the architecture rather than of an optimisation effort.

What server rendering really buys

Personalisation cannot be done at page level with static generation. A user-specific dashboard, a session-bound cart or a list that varies by permission has to be produced on every request. Filling it in from the client is possible, but then the content is absent from the first paint — and invisible to a search engine as well.

The second gain is freshness. For data that changes by the minute — stock levels, a queue number, a broadcast schedule — the build step is a source of delay. Here the right question is not “which is faster” but “how costly is stale content”.

Which one this site uses, and why

This site is generated entirely statically: the content changes rarely, no personalisation is needed, and the budget targets are met without a plugin layer. The only dynamic endpoint is the contact form — and it runs as a separate function, without affecting the pages. The full list of trade-offs and time to first byte are written separately.

Criterion

1. When the HTML is produced — Static generation: At build time, once · Server rendering: On every request
2. Time to first byte — Static generation: Serving a file — typically the lowest · Server rendering: Production time is added; caching can reduce it
3. Personalisation — Static generation: None at page level — done on the client · Server rendering: Natural: different content per request
4. Content freshness — Static generation: Requires a new build · Server rendering: Immediate
5. Scaling — Static generation: Served from the edge cache, server load stays flat · Server rendering: Server load grows with traffic
6. Infrastructure — Static generation: Static file hosting is enough · Server rendering: A running application server is required
7. Failure surface — Static generation: Narrow — the file to serve already exists · Server rendering: Wide — database, application and cache layers
8. Where it fits — Static generation: Content that changes rarely: marketing, portfolio, documentation · Server rendering: Content that changes often or is user-specific: dashboard, cart, feed

FREQUENTLY ASKED QUESTIONS

Is a static site always faster?

In time to first byte, typically yes, because there is no production step. But a well-cached server-rendered site can be fast too; the difference lies in the cache hit rate, not the architecture.

If the content changes often, is static out of the question?

It can still be used, but the cost rises: every change means a build. For a publication that adds content a few times a day that is reasonable; for a feed updating every minute it is not.

Can the two be combined?

They can, and often are. Most pages are generated statically, and only the parts that need personalisation are filled in from the client or an endpoint. The contact form on this site works exactly that way.