Server components, edge functions, and the modern web stack
The way I build websites has fundamentally shifted in the last two years. Here's a practical guide to what server components and edge functions actually do, and when they're worth using.
How much of what you read about web development actually applies to your project? If you've been following web development discussions over the past couple of years, you've probably encountered terms like "React Server Components", "edge functions", and "streaming" thrown around with varying degrees of clarity. Having shipped production sites using all of these, I want to cut through the jargon and explain what they actually do, when they're useful, and when they're overkill.
Server components in practice
React Server Components (RSC) let you write React components that run on the server and send HTML to the browser, rather than sending JavaScript that the browser then executes. The practical benefit is straightforward: less JavaScript shipped to the client means faster page loads, especially on mobile devices and slow connections.
On a recent project, a content-heavy marketing site with around 200 pages, moving to server components reduced the client-side JavaScript bundle from 180KB to 45KB. Time to Interactive dropped from 2.8 seconds to 1.1 seconds on a simulated 3G connection. These aren't theoretical improvements. They translate directly to better Core Web Vitals scores and, more importantly, a better experience for the people actually using the site.
The mental model takes some adjustment. You can't use browser APIs (window, document) in server components. You can't use useState or useEffect. Components that need interactivity, forms, dropdowns, modals, still need to be client components. The art is in drawing the line between server and client at the right level. In practice, most of a typical website can be server-rendered, with client components only where genuine interactivity is needed.
Edge functions: useful or hype?
Edge functions run your server-side code on CDN nodes distributed globally, rather than on a single origin server. The promise is lower latency, a user in Tokyo gets served from a node in Tokyo rather than making a round trip to London.
If you're asking me honestly: for most websites, yours included, edge functions make a marginal difference. If your origin server is well-configured with proper caching, the latency difference between origin and edge is 50-100 milliseconds on the first request, and subsequent requests hit the CDN cache anyway. Where edge functions genuinely help is for personalised content that can't be cached, showing different pricing by region, for instance, or handling authentication at the edge to reduce time-to-first-byte for logged-in users.
I use edge functions selectively. Middleware for authentication checks, geolocation-based routing, and A/B testing, yes. Running the entire application at the edge, rarely worth the trade-offs in terms of database latency and cold start times.
Streaming and Suspense
Streaming lets the server send parts of a page as they become ready, rather than waiting for everything to resolve before sending anything. Combined with React's Suspense boundaries, this means the user sees the page shell and above-the-fold content immediately, while slower data fetches (API calls, database queries) stream in below the fold.
This is particularly valuable for pages that aggregate data from multiple sources. A product page that needs pricing from one API, reviews from another, and inventory from a third can stream each section independently. The user sees the product information in under a second, and the reviews and stock status appear moments later.
When to use what
For a typical marketing or content site: server components everywhere, client components for interactive elements, static generation where possible, streaming for pages with slow data dependencies. Edge functions only if you have a specific need for them.
Want to understand how these technologies apply to your specific project? I'm happy to talk through the options, just get in touch.
Chris Ryan
Managing Director
17+ years in full-stack web development, most of it leading teams agency-side across e-commerce, CMS platforms, and bespoke applications. Specialises in infrastructure, system integration, and data privacy, with hands-on experience as a Data Protection Officer. Founded Innatus Digital in 2020 to offer the kind of honest, technically-led partnership that he felt was missing from the agency world.