Static, server-rendered, or both

The architecture conversation usually arrives as a stack question — should it be static, should it be server-rendered, should it be a single-page application — and the honest answer is that the question is being asked at the wrong altitude. A website is not one thing. It is thirty routes with thirty different relationships to time and identity, and the reason so many technically modern sites feel slow is that somebody answered the question once and applied it to all of them.

Take the routes that are the same for every visitor and change when an editor decides they change: the home page, the capability pages, the journal, the legal text. These should be rendered at build time and served from a CDN edge as files. There is no database in the request path, no server to warm, nothing to go wrong at three in the morning, and the first byte arrives from a machine in the same country as the reader. Most of a marketing site is this, and most of a marketing site is not built this way.

Then the routes that are the same for everyone but change without an editor: a catalogue that updates from the ERP, a listing that reprices hourly. These want incremental regeneration — served as a static file, rebuilt in the background on a schedule or when the source system says so. The reader always gets a file; the file is just never very old. It is the single highest-leverage pattern in modern web architecture and it is routinely skipped in favour of rendering the page on every request, which is how a catalogue page ends up costing four hundred milliseconds it did not need to spend.

Then the routes that are different per person: the cart, the account, the dashboard, anything behind a login. These are rendered on the server per request, and the useful refinement is streaming — sending the shell of the page immediately and letting the slow, personal parts arrive as they resolve, so the reader is looking at something real while the recommendation engine is still thinking.

Client-side rendering, after all that, is not an architecture. It is a tool for the parts of a page that are genuinely interactive: a filter, a configurator, a map, a media player. Every kilobyte of JavaScript shipped to make static text appear is a kilobyte the phone has to download, parse and execute before anything is usable — and the phone in question is usually a mid-range Android on a train, not the laptop the site was designed on.

Underneath, the database choice is less interesting than people make it and the discipline around it matters more. PostgreSQL is the default for a reason: it is relational when the data is relational, holds JSON well when it is not, does full-text search competently enough that most projects never need a separate search cluster, and is owned by nobody, so the licence cannot be changed under you. What it needs in a serverless deployment is a connection pooler, which is the most common omission we are called in to fix — a site that works perfectly until it is popular, then exhausts its connections and fails at exactly the moment success arrives.

The content layer is where the trade-off is genuinely a trade-off. A headless CMS gives a marketing team an interface, a preview, a publishing workflow and a history, at the cost of a subscription and a network hop. Content held in the repository is faster, free and version-controlled, and requires a developer for every comma. The right answer depends entirely on who edits, how often, and whether they are willing to open a pull request. Anyone who tells you there is one correct answer has only ever worked with one kind of client.

Last, the part that keeps the architecture honest: measurement, from the field rather than from a laptop. Largest Contentful Paint under two and a half seconds, Interaction to Next Paint under two hundred milliseconds, Cumulative Layout Shift under a tenth — measured on real visitors, at the seventy-fifth percentile, on the devices they actually hold. A performance budget agreed before design starts is worth more than any amount of optimisation afterwards, because it turns speed from a thing engineering is blamed for into a constraint everybody designed within.