Where your website actually lives — Cloudflare's edge vs SiteGround's servers

If you have a website, somebody has been quietly charging you for “hosting” for as long as you have owned the domain. Most clients I work with have a vague idea that it means “where the website lives” and a clearer idea that it means “the bill that arrives every month or every year.” The difference between two hosting plans is normally framed in terms of the dashboard, the storage allowance, or the support response time.

The thing nobody talks about is that the actual physical model of how the website reaches you has changed dramatically in the last few years, and it is increasingly the most important thing about your hosting choice.

What traditional hosting actually is

When you buy a hosting plan from SiteGround, or from any provider in that lineage — Bluehost, IONOS, GoDaddy, the IONOS rebadge of the week — what you are buying is a slice of a real, named server sitting in a real, named datacentre. That server is in a single physical location. If you are on SiteGround’s UK plan, the server is in London. Possibly Eemshaven. One specific building, one specific rack.

When somebody in Manchester visits your website, their browser sends a request to that London server, the server hands back the page, and the browser renders it. That is fine. The round trip is a few tens of milliseconds.

When somebody in Sydney visits your website, the same thing happens, except the request now has to travel from Sydney to London, the server has to do its work, and the response has to travel back. That round trip is closer to half a second. Every image, every script, every CSS file makes that same round trip. The page is slow not because it is a bad website, but because the server is on the wrong side of the planet.

Underneath all of this is a stack: PHP runtime, MySQL database, Apache or Nginx, a filesystem with your WordPress install on it. Every request hits PHP, PHP queries MySQL, MySQL hits the disk, the response is assembled and shipped back. That sequence is the same whether the visitor is around the corner or on the other side of the world. The work is happening in one specific room.

This model is not bad. It is the model the web was built on. It is what every “shared hosting” provider is selling, in some form or another, and for many websites it is genuinely fine.

It is also forty years old, and it shows.

What Cloudflare actually is

Cloudflare runs over 300 datacentres — they call them Points of Presence, or PoPs — in over 100 countries. When you deploy a website to Cloudflare, you do not push it to one server in one room. You push it to all of them, simultaneously. When the visitor in Sydney requests your page, the request is answered by the Cloudflare datacentre in Sydney. The visitor in Manchester is answered by the Cloudflare datacentre in Manchester. There is no transatlantic round trip because the page is already on the closest continent.

The thing that makes this work is that the underlying compute is not “a server sitting in a room.” It is a network of small JavaScript runtimes — Cloudflare Workers — that boot up in milliseconds the first time they are needed and then stay warm. There is no PHP, no MySQL on the request path, no shared filesystem to fall over. There is your code, running at the edge, close to the visitor.

For a static site this is very nearly free. The page is pre-rendered at build time and cached at every PoP. By the time a visitor asks for it, it is already there. Latency to first byte is measured in single-digit milliseconds in most of the world. The page loads before the visitor’s brain has finished processing that they clicked the link.

This is not a Cloudflare-specific idea. Discord runs on edge infrastructure. Shopify runs large parts of its store rendering on Cloudflare’s edge. Spotify, GitHub Pages, the BBC’s homepage on a good day. The pattern is called “the edge” and it is the dominant infrastructure for new web software. The model that traditional hosts sell is the one being competed away.

Why WordPress can’t easily move there

The honest answer is: because WordPress is structurally a server-side PHP application backed by a MySQL database, and that combination does not survive the trip to the edge.

PHP needs a runtime. MySQL needs a stateful database engine, a filesystem, a network stack and time to boot. None of those things are cheap to deploy to 300 datacentres simultaneously, and none of them are designed to run inside a 50-millisecond edge request. There are projects that try to bridge the gap — server-side caching plugins, edge CDN integrations, the various “WordPress on Workers” experiments — but they are all working uphill against an architecture that was designed for one server in one room.

This is why traditional shared hosts are still selling traditional shared hosting. The market they serve, almost entirely, is WordPress. WordPress needs PHP and MySQL. PHP and MySQL fit on a shared server in a single datacentre. The whole business model is built on it.

It is also why I host static sites on Cloudflare and WordPress sites on SiteGround. The two models do different jobs. WordPress at the edge is a forced fit. WordPress on a UK server with a CDN bolted on is the right setup for WordPress. A static site on a UK server is wasting most of what the static-site model is good for.

What this means for choosing a host

If you are running a brochure or marketing site that does not need a content management system, the mental model has flipped. Putting that site on shared hosting now is paying a monthly fee for the slow version. Putting it on Cloudflare’s edge is paying a similar monthly fee for the fast version, with global reach and meaningfully better security as side effects.

If you are running WordPress, the choice is slightly different. SiteGround on UK servers, with proper caching and a CDN in front, is still close to the right answer. The newer model has not made traditional hosts obsolete for the workloads they serve well. It has just dramatically narrowed the range of workloads they serve well.

The question I ask new clients on the discovery call now is not “what host are you on?” — it is “what kind of website do you actually have?” If the website is mostly static content, somebody has been charging you the wrong shape of bill for the last five years. If the website is genuinely dynamic and CMS-driven, the bill is roughly right.

The era when “get a hosting account from a cPanel reseller” was the obvious default is over. There are now at least two distinct shapes of website infrastructure and they cost roughly the same money. Picking the right one is most of what hosting decisions are about now.