Static, serverless and the edge: how hosting quietly changed

For twenty years, hosting a website meant the same thing: a computer somewhere ran a web server and a database, and every time somebody visited, it assembled the page from scratch and sent it.

That model still runs most of the web. It also has an obvious inefficiency once you look at it directly — a page that says the same thing to every visitor is being rebuilt from a database thousands of times a day for no reason.

The shift: build once, serve everywhere

The alternative is to do the assembling ahead of time. When the site changes, everything is built into finished files. Those files are copied to locations around the world. A visitor gets the nearest copy, already built.

The consequences fall out immediately:

• It is faster, because nothing is computed while the visitor waits, and the files start from somewhere physically near them.
• It is more secure, because there is no database to inject and no application server to exploit. You cannot hack a file that is only ever read.
• It is cheaper, often free at small-business scale, because serving a file is close to the cheapest thing a computer can do.
• It does not fall over under traffic, because handling a spike is a bandwidth problem rather than a computation problem.

Faster, safer and cheaper at once is rare enough to be suspicious of, which is the fair question to ask next.

So what is the catch?

A real one: this only works if the page can be built in advance.

Plenty cannot. Anything showing a logged-in user their own data, live stock, a personalised basket or a search result has to be worked out at the moment of asking.

That is what serverless functions are for. Small pieces of code that run on demand, only when called, and cost nothing when idle. The static pages handle everything predictable; a function handles the form submission, the search, the payment.

And the edge means both run at locations near the visitor rather than in one data centre. Someone in Karachi and someone in Manchester are both served locally, which for a business selling internationally is a material difference rather than a technical footnote.

Where this genuinely does not fit

Being honest about the boundaries, because the enthusiasm around this model tends to skip them:

• WordPress does not work this way without significant additional tooling. If you are on WordPress and happy, this is not an argument to leave. Managed WordPress hosting is the sensible path instead.
• Heavily dynamic applications — anything where most pages differ per user — get less benefit, because less can be built in advance.
• It requires a build step. Content changes go through a rebuild rather than appearing the instant you hit save. Modern platforms make this near-instant, but it is a different mental model for whoever edits the site.
• The ecosystem is younger. Fewer plugins, fewer people who know it, and more of the work done by writing code rather than installing something.

How to tell whether it applies to you

One question: does every visitor see essentially the same page?

For a builder, a clinic, a restaurant, a solicitor, a consultancy — yes. Your services page says the same thing to everyone. There is no reason to rebuild it from a database on every request, and every reason not to.

For a store with accounts, a booking system with live availability, or a member area — partly. The catalogue can be static; the basket cannot. Modern platforms handle exactly this mix, which is the point.

Why this is worth knowing even if you change nothing

Because it reframes what “we need better hosting” means. The instinct when a site is slow is to buy a bigger server. Frequently the better answer is to stop doing work that never needed doing.

It also gives you a way to judge whoever builds your next site. A studio still putting brochure sites on database-backed hosting by default in 2026 is not necessarily wrong — but they should be able to tell you why, and “it's what we always do” is not a reason.

Our position

This site is built this way, so treat what follows as an interested party being upfront about it. Static pages, functions for the form and the estimate tool, served from the edge. It is fast, there is nothing to patch, and the hosting is not a meaningful line in our costs.

We would not recommend it for everything. A client who needs to edit content twenty times a day, or who has a large existing WordPress investment that works, is better served staying put. The right architecture is the one that matches the site, not the one that is newest.

If you want a straight answer on whether your site would benefit, book a free call. See also types of hosting compared and Core Web Vitals in plain English.