Skip to content

How we build

Six Reasons Your Next Website Should Be Server-Rendered, Explained Without the Jargon

The most consequential decision about your next website is whether the page arrives finished or assembles itself after it gets there.

5 min read

Server-rendered means the page is put together before it is sent, so it arrives complete. The alternative sends a near-empty page and a set of instructions, and your visitor's phone does the assembly on arrival. Both can look identical once finished. The difference shows up in how fast the page appears, whether machines can read it, and how much of it you control - which is why it is worth understanding before you commission anything.

Here is the plainest version of the distinction. A server-rendered page is a meal delivered cooked. The other kind is a delivery of ingredients with a recipe, prepared in the visitor's kitchen, on whatever equipment they happen to have. If they have a good kitchen - a new phone, a fast connection - the difference is small. If they are on a five-year-old handset on mobile data outside your shop, it is not small at all.

For a business website, cooked is nearly always right. Here is why.

1. The page appears sooner

The visitor's device has nothing to do but display what it received. There is no waiting for code to download, run, and fetch the content it needs before anything can be shown.

This matters more than it sounds, because the first few seconds are where visitors are lost - and they are lost silently. Nobody emails to say your site was slow. They go back to the results page and click the next one. The cruel part is that the visitors you paid to acquire, through advertising or hard-won search position, are exactly the ones a slow first screen throws away.

2. Machines can read it without doing any work

Search engines can generally handle pages that assemble themselves, though they do it on their own schedule and not always completely. AI assistants are less uniform about it, and some simply take what they are given. If what they are given is an empty shell, that is what gets read.

A server-rendered page removes the question entirely. The words are in the page when it arrives. Every crawler, every assistant, every link preview and every screen reader gets the real content on the first attempt. As more people find businesses by asking an assistant rather than scrolling results, this stops being a technical nicety.

3. You control every tag on the page

Titles, descriptions, heading structure, structured data, the image and headline that appear when your link is shared into WhatsApp or LinkedIn - on a custom server-rendered build, each of those is written deliberately, per page.

On a platform or a heavy theme, you get whatever markup it emits, and you get whichever settings it chose to expose. When something is wrong - a heading level skipped, a title truncated, structured data missing or describing the wrong thing - you can often see the problem perfectly well and simply cannot reach it. Controlling the markup means the fix takes ten minutes instead of a support ticket.

4. Your site carries your site, and nothing else

A hosted platform ships every feature it has ever built to every site on it. Your visitors download the machinery for the booking system you do not use, the store you never opened and the gallery you removed. A self-hosted site with a long plugin list arrives at the same place by a different road: each plugin adds its own weight to every page.

A custom build carries what your site needs. Nothing arrives to support a feature you never asked for. This is also why performance holds up over time on a custom build and tends to decay on the alternatives - decay is what happens when things are only ever added.

5. It grows without permission

Traffic spikes are the good problem, and the platforms charge for them. So does the plan that gates the feature you now need, and the app subscription for the integration you have outgrown.

Pages that are built ahead of time and served from a content network are effectively just files sitting close to your visitors. Handling a hundred times the usual traffic is not an upgrade event; it is Tuesday. Hosting a professionally built site is genuinely cheap - typically tens of euros a month, not hundreds - and the ceiling is somewhere you will probably never reach.

6. It is ordinary code that anyone can pick up

This is the one that matters in five years rather than five seconds.

Our own builds use Next.js and React, which are the mainstream tools for this - widely used, well documented, and known by a large number of developers. That last point is the whole benefit. A site built this way can be handed to any competent developer, moved to any host, and continued by someone who has never met us. It is not a proprietary format, not a private framework, and not a licence that renews.

Ask any prospective builder what happens if you stop working with them. On an ordinary, standards-based codebase, the honest answer is: nothing much, you take it elsewhere. That answer is worth more than any feature.

What this does not mean

Two honest qualifications.

Server-rendering is not the same as being fast. It is a strong foundation that can still be ruined by enormous unoptimised images, half a dozen tracking scripts and a video autoplaying in the header. Most slow sites are slow for those reasons rather than architectural ones. The architecture sets your ceiling; the discipline decides where you land under it.

And some platform sites are perfectly quick. If yours is fast, indexed and doing its job, none of this is an argument for replacing it. The distinction matters when you are choosing what to build next, not as a reason to throw away something working.

The question to ask

If you are commissioning a website, ask one thing: "Will my pages be rendered on the server, so the content is in the HTML when it arrives?" You do not need to follow the answer into the technical detail. You need to see whether the person you are hiring understands the question and can answer it plainly.

If you already have a site and want to know where it stands, our free website health check tests exactly this - whether your content is present when the page arrives, how fast it becomes usable, and what is holding it back. It takes a few seconds and there is no sign-up.

Written by Whitespace ·