Why our marketing sites are server-first instead of client-first

React makes it easy to build a website as if every page were an application. We usually do the opposite. The default state of a business website is information. Headings, paragraphs, services, case studies, locations, articles, proof, contact details, and navigation do not become more useful because the browser had to execute JavaScript before displaying them.

So our default is server-first.

The browser should receive the answer, not the assignment

A client-first page often sends JavaScript that says, in effect, "Here is the application. Please run it so you can discover what the page contains." A server-rendered or statically generated page sends the page. That difference sounds philosophical until you look at what the browser has to do. Client-side application code has to be downloaded, parsed, compiled, executed, and often hydrated before the page becomes fully interactive. On a fast desktop connection that cost may be hard to notice. On a weaker phone, a busy CPU, or a poor connection, it becomes visible.

For most public content, we would rather spend that compute before the visitor arrives.

Our repositories show the pattern repeatedly

Dynamic service pages call server-side content loaders, generate static parameters, generate metadata from the loaded content, and render the resulting page without turning the whole route into a client component. Location pages do the same thing. The application discovers the valid locations from content files, generates their paths, creates page metadata, and passes the finished data model into the page.

Article systems read MDX from disk on the server. Case-study routes can discover MDX filenames during the build and create a route for each one. None of that requires a browser state manager.

Client components still have a clear job

We use client-side React when the interaction genuinely belongs in the browser. Examples include a modal that opens from a user click, a gallery that responds to arrow keys, a mobile navigation drawer, form state, or a control that reads the current URL.

The pattern we care about is the boundary. On one build, a gated resource uses a client component for opening and closing the dialog, capturing the input, showing submission state, and responding to Escape. The actual validation and provider forwarding happen through a server route.

That is a healthy split. The browser owns the interaction. The server owns the trust boundary.

Narrow client boundaries keep pages understandable

If an entire page is marked as a client component because one button needs state, several things happen. More code becomes eligible for the client bundle. Server-only data access becomes harder. The mental model gets blurrier because content rendering and browser interaction are mixed together.

Instead, we try to isolate the smallest useful interactive island. A gallery can be interactive without making the case study client-rendered. A menu can be interactive without making the site shell client-rendered. A form can manage state without making every paragraph above it part of the hydration tree.

This is also an SEO decision

Search engines are much better at rendering JavaScript than they used to be, but that does not mean we should require it for content that can be available immediately. Server-rendered HTML gives crawlers and assistive technologies a straightforward document. Links exist as links. Headings exist as headings. Metadata is generated before the page is sent.

That is a cleaner starting point.

Server-first does not mean static-only

Some pages genuinely need request-time information. Some applications need real-time state. Some user experiences require substantial client logic. We do not force static generation onto a problem that needs a server request, and we do not force Server Components onto a feature that depends on browser APIs.

The principle is not "never use JavaScript." It is "do not make JavaScript prove it deserves to be there."

Why this tends to outperform heavier builds

A page-builder site can accumulate JavaScript from the builder itself, animation systems, plugin frameworks, analytics tools, form plugins, sliders, popups, and theme code. A custom server-first site begins with almost none of that. The performance advantage is structural. We are not taking a giant client application and shaving milliseconds from it. We are avoiding the need to ship much of that application in the first place.

That is why our fastest sites often look ordinary from a user's perspective. They have images, menus, forms, motion, and responsive layouts. The unusual part is how little browser work is required to produce the experience.