The choice between serving a website as pre-built static files and rendering it dynamically on a server is one of the most consequential architectural decisions a web project makes, and it is frequently decided by habit rather than analysis. The thesis of this article is that the decision should follow from a single question: does the content depend on the individual request, or is it the same for everyone until the next deployment. Content that is identical for all visitors should be static; content that genuinely varies per request needs server computation. Most projects contain both kinds, and modern tooling lets each page choose independently.
The Static Model and Its Strengths
A static site is a collection of HTML, CSS, and JavaScript files generated ahead of time and served directly, typically from a content delivery network. Because the work of producing each page happens once at build time rather than on every request, the result is fast, cheap, and highly resilient. There is no application server to crash under load, no database to become a bottleneck, and the attack surface is minimal because there is no request-time code execution on the origin.
A static-first generator such as Astro embodies this model. By default, Astro renders pages to HTML at build time and ships minimal JavaScript, which produces excellent performance for content-driven sites such as blogs, documentation, and marketing pages. When content changes, the site is rebuilt and redeployed. The trade-off is that build time grows with the number of pages, and content that must reflect the present moment cannot be baked in ahead of time without a rebuild.
When a Server Becomes Necessary
Server rendering computes the response when the request arrives. This is required whenever the output depends on something known only at request time: the identity of the authenticated user, a personalised dashboard, search results, the contents of a shopping cart, or data that must be current to the second. No amount of pre-building can produce a page whose content is determined by who is asking and when.
Server-side rendering also suits content that changes far too frequently to justify a full rebuild on each change, or sites with so many pages that building them all in advance is impractical. The cost is operational: a runtime now executes per request, which must be provisioned, scaled, and monitored, and which introduces latency and failure modes that static files do not have.
The Spectrum Between the Extremes
The framing of static versus server is a simplification, because contemporary platforms offer a spectrum. Incremental and on-demand approaches build pages lazily or revalidate them on a schedule, combining the speed of static delivery with the freshness of server rendering. Astro supports a hybrid posture in which most pages are static while selected routes opt into on-demand rendering through a server adapter. The principle is to render statically by default and reach for server computation only where the content demands it, page by page rather than for the entire site.
Deployment platforms reinforce this granularity. Vercel, for instance, serves static assets from its edge network while routing dynamic paths to serverless functions, so a single project can mix pre-rendered pages with request-time logic without the developer managing separate infrastructure. The architecture follows the content rather than being imposed uniformly.
A Practical Decision Procedure
For each route, ask whether its content varies by request. If it does not, render it statically and serve it from a CDN. If it does, determine whether the variation is per-user, in which case server rendering is appropriate, or merely time-sensitive, in which case scheduled revalidation may preserve static delivery while keeping content fresh. Reserve always-dynamic rendering for the cases that truly require it, because every page made static is a page that is faster, cheaper, and harder to break.
Conclusion
Choosing between static sites and servers is not an ideological commitment but a per-route engineering judgement driven by whether content depends on the request. Static generation should be the default for its speed, economy, and resilience, with server rendering introduced deliberately where personalisation or real-time data make it unavoidable. Tools such as Astro and platforms such as Vercel make this hybrid posture straightforward, allowing each page to adopt the simplest architecture that satisfies its requirements.