Placing an order from abroad?

Latency is the reason most people ask the location question, and it is usually the least important answer. A round trip between a browser and a server crosses Western Europe in tens of milliseconds — real, measurable, and far smaller than the delay caused by an unoptimised hero image or a theme loading four font files. Moving a server five hundred miles closer typically buys back less time than deleting one plugin.

Distance does bite in two places. Uncached requests — a dashboard login, a checkout step, a search query hitting the database — make the full return journey every time, so an editor working all day feels a gap a reader never notices. And the further out you go, the more the gradient steepens: the difference between Dublin and Warsaw is small, the difference between Dublin and Karachi is not.

The practical rule: pick your origin for the audience you actually have, then let caching flatten the rest. A cached page can be served from an edge node near the reader no matter where the origin lives, which is why a single well-run facility beats a scattered fleet of slow ones.

Where a server sits decides which courts, regulators and disclosure regimes can reach what is on it. That is a different question from speed and it has a different answer. Our hardware is in London and the company invoicing you is registered in England and Wales, so UK law governs the processing and the ICO is the regulator with jurisdiction over us.

For most sites this is a paragraph in a privacy notice rather than a decision. It becomes a decision when someone else sets your rules: a public-sector tender, a client's security questionnaire, an insurer, or a data protection impact assessment that names permitted countries. When that is the brief, the honest move is to check the requirement before you buy rather than after the invoice clears.

Residency is the narrow version of the jurisdiction question: not whose law applies, but which country the bytes physically occupy. Ours is a single answer — London — and it does not change by plan, by region or by how much you spend. There is no menu of locations here and we would rather say so on the hub than let you discover it at checkout.

That suits the large majority of sites, including every business whose customers simply want the page to load. It does not suit a project under a rule that requires storage inside a named country. If yours is one of those, no amount of caching solves it, and a host with one facility is the wrong shape for the job.

Country-code domains carry eligibility rules that have nothing to do with hosting, and they are the most genuinely local part of this whole decision. Some registries want a registrant established in the region — .fr expects an EU or EEA presence — while others, .es and .nl among them, hand the ending to anyone who asks. Brexit removed .eu from UK residents while leaving it open to buyers in Dublin, Berlin or Lisbon.

We register a specific list rather than everything, and each country guide names the endings we can actually get you along with the year-one price from the live list. Where we cannot supply the national ending, the guide says so in the same sentence instead of steering you toward a .com and hoping you do not notice.

The gap that catches people out is rarely technical. Every country has a payment habit — iDEAL in the Netherlands, BLIK in Poland, Bizum in Spain, Multibanco in Portugal — and our checkout takes cards. If the rail you normally use is one we cannot process, that is worth knowing on the first page you read, so each country guide names it outright.

Support runs around the clock in English, with first replies targeting 2 hours and 1 hour when a site is down. What differs by country is not the cover but the overlap: from Lisbon your working day sits on top of ours, from Karachi your afternoon lands in our overnight shift. Both get answered; only one gets answered while you are still at the keyboard.