Why a static site beats a tuned server

There is a particular kind of afternoon that anyone who has run a busy website will recognise. A page is slow. You add a caching plugin. You tune the database. You move to a bigger plan. The page is now slightly less slow, and you have spent a fortnight finding that out.

The awkward truth is that most of the time was never in the parts you were tuning.

Where the time actually goes

A request to a database-driven page has to complete a chain of work before a single byte comes back:

1. The request reaches your origin server.
2. The web server hands it to an application runtime.
3. The application works out which page this is.
4. It queries the database, usually more than once.
5. It renders a template around the results.
6. The response finally starts travelling back.

Every one of those steps has a bad day occasionally. The database gets a slow query. A plugin decides to phone home. The server is busy with someone else's traffic. You inherit the worst of them on every request that misses cache.

A static page does none of it. The file was finished when you built it, and the only remaining question is how far it has to travel.

The number that surprises people

Here is the part that catches people out: once you remove the server-side work, the dominant cost is distance, and distance is not something you can optimise your way out of. Light in fibre covers roughly 200 km per millisecond, and a TCP connection needs several round trips before any content flows.

Dallas to London is about 7,500 km. That is a floor of roughly 37 ms each way before anybody has done anything useful, and in practice you should budget two to three round trips for connection setup. You can have the fastest server ever built and a visitor in London will still wait.

This is why we put the edge network on every plan rather than selling it as an upgrade. Serving a cached copy from near the visitor removes the largest single component of the delay, and no amount of server tuning competes with it.

When static stops being the answer

Static hosting is not a universal recommendation, and it would be strange for a hosting company to pretend otherwise.

• You need a database. A store, a forum, a members area or anything with per-user state needs somewhere to keep that state.
• Content changes constantly. If your site rebuilds every few minutes, a build step becomes friction rather than a benefit.
• You need server-side logic. Form handling, authentication, payment callbacks: these want a runtime.

If any of those describe your site, our Basic Shared plans start at $2.99 a month and run on the same edge network. You lose the "nothing to compute" advantage and keep everything else.

The honest summary

Static hosting is not a clever optimisation. It is the removal of work that never needed doing for pages that were the same for everybody. If your site is mostly that kind of page, you will find it very hard to beat, and you will not have to spend a fortnight proving it.