You keep hearing that your website should use server components. Here's what that actually means for your speed, your costs, and your search ranking — translated out of jargon and into the numbers you care about.
- A web page can be assembled on your server or on the visitor's phone — server components move that work back onto your server.
- That shift makes pages appear faster, easier for search engines to read, and often cheaper to host.
- You don't need the technical detail; you need to know which parts should still run on the visitor's device, and to ask your developer why.
Imagine two coffee shops. In the first, you order and the barista hands you a box of beans, a grinder, a jug of milk and a printed set of instructions, and you make the coffee yourself at your table. In the second, you order and they hand you the finished cup. Both sell you coffee. But one of them feels fast and effortless, and the other depends entirely on how good you are at operating a grinder — and on a bad day, at a wobbly table, with cold hands, you might just walk out.
For most of the last decade, a lot of websites were built like the first coffee shop. That sounds absurd when you put it that way, and in a sense it was, but there were real reasons for it at the time. "Server components" are, in plain terms, the industry quietly deciding that handing people the finished cup is usually the better idea. This piece is about what that means for the three things you actually care about — how fast your site feels, whether Google favours it, and what it costs you to run — without asking you to understand a line of code. You don't need to. You do need to understand the trade-off, because it lands on your bottom line.
Two places a page can be built
Here's the one idea that makes the rest fall into place. When someone visits your site, the page they see has to be assembled out of your content and your design. That assembly can happen in one of two places: on your server, before anything is sent, or on the visitor's own device, after their phone or laptop downloads a bundle of instructions and runs them.
For years the fashionable approach was the second one — send the visitor's browser a large bundle of code and let their device build the page. This is the "client-side" way, the client being the visitor's device. It made websites feel like slick apps, and for genuinely app-like things that was the right call. But it quietly moved a lot of work onto hardware you don't control: your visitor's ageing phone, on a train, on a weak signal.
Server components shift that work back to where you do have control — your server, which is powerful, consistent, and paid for by you. The visitor receives a page that's already mostly built, so their device has far less to do. Nearly every benefit that follows comes from that single move.
Client-side (old way)
┌──────────┐ big bundle ┌───────────────────────────┐
│ server │ ───────────▶ │ visitor's phone builds │ slow on
└──────────┘ │ the page, then shows it │ weak devices
└───────────────────────────┘
Server components (new way)
┌────────────────────────┐ finished page ┌──────────┐ shows almost
│ your server builds it │ ──────────────▶ │ phone │ immediately
└────────────────────────┘ └──────────┘Why your site feels faster
Follow the first path and picture what the visitor's phone actually has to do: download a big bundle of code, run it, then reach back out to fetch the real content, then finally paint something on screen. On a new laptop over office broadband, all of that is a blink. On a mid-range phone with two bars of signal — which is how a large share of your real customers arrive — it's a stutter, and they spend it staring at a blank or half-drawn screen while their phone grinds through work you handed it.
Take the second path and the phone receives something close to a finished page and can show it almost at once. The heavy lifting already happened on your server. The result is that content appears faster, and it appears faster most for the visitors on slower devices and weaker connections — which, uncomfortably, are often the very visitors you're most likely to lose to a sluggish site.
A visitor who waits too long doesn't complain. They leave, and you never find out they were there.
That's why speed isn't a vanity metric. Every second of delay quietly sheds people who would otherwise have become an enquiry or a sale. Faster pages simply keep more of the people who arrive, and that shows up in the numbers that matter to you rather than the ones that matter to engineers.
Why it helps you get found
Two things about this approach help you with search engines, and both feed directly into how easily customers find you.
The first is straightforward: speed is something Google explicitly measures and rewards. Search engines want to send people to sites that give a good experience, and how quickly and smoothly a page loads is part of how they judge that. All else equal, a faster site is easier to rank — and building the page on the server is one of the more dependable ways to be genuinely, measurably faster.
The second is subtler and matters more than most business owners realise. When a page is assembled on the visitor's device, a search engine trying to read it has to do that same assembly work itself to see your content — and it doesn't always do so reliably or completely. Your beautifully written service descriptions can be effectively invisible to the thing deciding whether to show you in results. When the page arrives already built from the server, your content is simply there, plainly readable the moment a search engine looks. For a business that lives or dies by being found — which is most businesses — that reliability is not a small thing.
Why it can lower your costs
This one is less obvious but real, and it comes down to a word worth adding to your vocabulary: caching. Because the page arrives already finished, you can often keep a ready-made copy of it and hand that same copy to visitor after visitor, without rebuilding it each time. For any page that doesn't change from minute to minute — most of your marketing and content pages — your server ends up doing dramatically less work per visitor.
Think of it as the difference between a restaurant that cooks every dish from raw ingredients the moment it's ordered, and a bakery that made a tray of the same thing this morning and hands them out as people come in. When a rush arrives, the bakery barely notices; the cook-to-order kitchen falls over. Less work per visitor translates fairly directly into lower hosting bills, and into a site that stays quick even when a lot of people show up at once — during a campaign, or when a piece of content does unexpectedly well. A site built the older way often has to do the full job for every single visitor, which costs more and buckles sooner under a surge. Serving far more people from the same infrastructure is money that stays in the business.
The honest trade-offs
I promised no salesmanship, so here's the other side. Server components are not free and they are not right for everything.
| If your site is mostly... | The benefit is... | Because... |
|---|---|---|
| Marketing and content pages | Large | The page rarely changes, so it caches beautifully and reads cleanly for search engines |
| A mix of content and some interactive features | Solid, with judgement needed | Most of it gains; the interactive parts need careful placement |
| A heavily interactive app, interactive on every screen | Smaller | Much of it genuinely needs to run on the visitor's device to feel responsive |
A few things worth being clear-eyed about:
- Not every part of a page benefits. Genuinely interactive features — a live search, a product configurator, a booking calendar that reacts the instant you click — still need to run on the visitor's device to feel snappy. The modern approach isn't "everything on the server"; it's "the server by default, with the interactive bits running on the device where they belong." Getting that line in the right place is a judgement call, and it's part of what you're paying an experienced developer for.
- It's a genuinely different way of building. Teams used to the old way have to adjust, and done carelessly you can end up with a muddle that carries the downsides of both. That's a reason to work with people who understand the model, not a reason to avoid it.
What to carry into the room
You don't need to manage the technical detail, and you shouldn't try. What's worth taking into your next conversation with a developer is exactly this: building pages on the server tends to make your site faster for real visitors, easier for search engines to read and rank, and cheaper to run — and the main trade-off is deciding which interactive parts still belong on the visitor's device.
That framing hands you the questions that matter. Are we building on the server by default? Which parts genuinely need to run on the visitor's device, and why those? Are we caching everything that can be cached? Those look like technical questions, but they're business questions wearing technical clothes, and you are perfectly equipped to ask them. A good developer will welcome them — because they're the questions that lead to a site built to serve your business, rather than one built to impress other developers.