Server components, edge rendering, and partial prerendering have changed what 'fast' actually means. Here's how we use them — and the trade-offs nobody talks about.
The web platform has quietly become one of the most powerful runtimes on the planet. What used to require a native app — instant interactions, smooth animations, real-time data — can now run inside a browser tab. But with that power comes a much wider menu of architectural choices, and choosing the wrong one will cost you users.
This is the stack we ship in 2026, what we'd skip, and the lessons we wish we'd learned earlier.
Start with the rendering model, not the framework
The biggest performance win is not which framework you pick — it's where your HTML is generated. The four practical choices today are static generation, server-side rendering, edge rendering, and client-side rendering. Most teams default to whichever their framework picks for them, and that's usually a mistake.
Static is unbeatable when content rarely changes. Edge rendering is the sweet spot for personalized but cacheable pages — think product detail pages with logged-in user data. Pure client-side rendering is now a niche choice; reserve it for genuinely interactive dashboards where SEO does not matter.
Picking the wrong model adds 100–400ms to your time-to-first-byte. That alone can drop conversion rates by 5–10% on commerce sites. Audit your highest-traffic pages first.
Server Components are not magic — but they are a real win
React Server Components let you write components that run only on the server and send zero JavaScript to the client. For content-heavy pages this is transformative: a typical marketing page that previously shipped 200 KB of React can now ship 20 KB.
The catch is that the mental model is genuinely different. State, event handlers, and browser APIs only exist in client components, and the boundary between server and client has to be explicit. Teams that try to retrofit RSCs into an existing client-first codebase usually end up with both worlds and the worst of each.
Our rule: server components by default, client components when you actually need interactivity, and a clear naming convention so reviewers can spot violations.
The performance budget that actually works
Most performance budgets fail because they are framed as ceilings ('the bundle must be under 250 KB') without any accountability. The version that works for us is a quarterly review tied to Core Web Vitals from real user monitoring.
We track three numbers per route:
- Largest Contentful Paint at the 75th percentile — under 2.5 seconds.
- Interaction to Next Paint at the 75th percentile — under 200 milliseconds.
- Cumulative Layout Shift — under 0.1.
If a route regresses, the PR that caused it is the team that fixes it. This single policy did more for our performance than any specific optimization.
What to skip
A few things that get a lot of hype but rarely move the business needle:
- Heavy state management libraries on content sites — the framework primitives are enough.
- Custom CSS-in-JS solutions — Tailwind plus a small set of design tokens covers 95% of cases with zero runtime cost.
- Micro-frontends below 5 teams — they add coordination overhead without solving a real problem at your scale.
What this means for your business
Page speed is no longer a technical detail. Google reports that conversion rates drop by 4.42% for every additional second of load time on mobile. If your site is two seconds slower than your competitor, you are losing roughly 9% of every cohort that lands on it.
The good news: the gap between a slow site and a fast one is mostly architectural decisions, not engineering hours. A two-week audit and rework on a modern stack typically pays for itself in the first month.
