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
Principal Engineer, CodexLab
7 min read
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.
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.
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
Principal Engineer, CodexLab
Theo writes about the engineering side of the studio — performance, architecture, and building things that last.
Speed stopped being a back-office engineering concern a while ago. In 2026, Core Web Vitals sit squarely on the line between a good experience and lost revenue — and INP is the one that still trips teams up.
AI has gone from autocomplete to collaborator. Here’s how agentic tools are reshaping the way a studio researches, explores, and ships — and why a designer’s judgment matters more than ever.
A static interface assumes every user wants the same screen. Generative UI starts from the opposite premise — and quietly moves the designer’s job from drawing screens to defining the rules that build them.