Back to the Journal
Engineering

Server-first: the performance pendulum swings back

For years we shipped the whole application to the browser and apologized for the spinner. In 2026 the default is server-first — and the client is finally getting lighter.

Theo Almeida
Theo Almeida
Principal Engineer, CodexLab
7 min read
A developer’s screen showing server-rendered components and a slim client bundle

For years we shipped the whole application to the browser and apologized for the loading spinner. In 2026 the pendulum has swung back: the default is server-first, and the client is finally getting lighter.

The pattern is now mainstream. React Server Components and server-side rendering move the heavy lifting off the user’s device, and the browser only receives the JavaScript it genuinely needs for interactivity. Less shipped code means faster first loads, less main-thread work, and interfaces that feel instant on the mid-range phones most people actually use.

A discipline, not a default

Server-first isn’t free. It forces a decision you used to be able to avoid: what is static, what is dynamic, and what truly needs to run on the client? Drawing that line up front is the new architectural skill. Get it right and the app feels effortless; get it wrong and you ship a confusing hybrid that’s slower than either extreme.

Abstract circuitry representing work moving from the client to the server and edge
The heavy lifting moves off the device — but only if you decide what belongs where.

Compiler-driven frameworks help. The React Compiler now handles much of the memoization developers used to write by hand, which means less defensive boilerplate and fewer performance footguns. The job moves from “optimize this component” to “describe intent clearly and let the toolchain optimize.”

The edge is part of the front end

More applications now default to edge deployment, running close to the user rather than in a single distant region. Edge awareness — designing within tighter runtime constraints and treating latency as a first-class concern — is becoming a core front-end skill rather than an ops afterthought.

Source code on a monitor with performance traces
We budget JavaScript like we budget image weight — and measure on real devices.

For a studio that ships marketing sites and product surfaces, this is good news. The same architecture that makes a landing page load instantly also makes it cheaper to run and easier to keep fast as it grows.

In 2026, performance isn’t the optimization you do at the end. It’s the shape of the decision you make at the start.

How we build now

Our default stack renders on the server, hydrates only what’s interactive, and pushes static content to the edge. We measure on real, mid-range hardware instead of the engineer’s laptop. None of this is exotic anymore — it’s just what “modern and fast” means this year.

The browser will always be where the experience lives. The lesson of 2026 is that it doesn’t have to be where all the work happens.

Theo Almeida
Theo Almeida
Principal Engineer, CodexLab

Theo writes about the engineering side of the studio — performance, architecture, and building things that last.

Keep reading