In short
Choose the region closest to where most of your users are, unless data-residency rules dictate otherwise. Round trips cost real time — roughly 100–150ms across an ocean — and a page making several sequential requests multiplies that. A CDN fixes distance for cached assets but not for database queries, so put your origin near your users, not near you.
Distance is a hard floor
A request travelling between continents takes roughly 100 to 150 milliseconds each way, and no amount of tuning changes it. That is the speed of light through fibre plus routing overhead.
A single round trip is tolerable. The problem is that pages rarely make one. A TLS handshake, an authentication check, a couple of API calls and a database query, each waiting on the last, multiplies the penalty. Two hundred milliseconds of distance becomes a second of waiting.
Which is why region choice matters more than it appears: it sets a floor that optimisation cannot go below.
Choose for your users, not your desk
The most common mistake is hosting near the team rather than near the audience. It feels fast in development because the developers are close to it.
Use actual data. Look at your analytics by country, and at your real-user performance metrics segmented geographically. If most visitors are in one country, host in or beside it.
Where users are genuinely split — say half in Europe and half in North America — accept that one group will be further away, and choose based on which group matters commercially, or on which is larger. Splitting the difference in the middle of the Atlantic serves nobody well.
Data residency can override everything
Some decisions are not yours.
Personal data belonging to people in certain jurisdictions may need to stay within them. Public sector, health and financial clients frequently have explicit requirements. Some contracts specify a country outright.
Check this before choosing on performance, because moving a database between regions later is genuinely disruptive — it usually involves downtime, and it is the kind of migration that gets deferred until it becomes urgent.
If you serve regulated markets, region choice is a compliance decision that performance then works within.
What a CDN does and does not solve
A CDN puts cached content near users, which removes distance for static assets and cacheable pages. That is a large share of many sites.
What it does not remove is distance for anything dynamic. A logged-in dashboard, a search query, a checkout — these reach your origin, and the origin is where it is.
So the two work together rather than substituting: a CDN for assets and cacheable pages, an origin near the users who do the uncacheable work. If your product is mostly authenticated, the CDN helps less and origin placement matters more.
Multiple regions, and why to avoid them at first
Running in several regions sounds like the answer and usually is not, at least not early.
Application servers are straightforward to duplicate. The database is the problem. You then face genuine distributed-systems questions: replicate reads and accept lag, shard by geography and accept complexity, or use a globally distributed database and accept its trade-offs. Each is a real commitment.
Most applications are better served by one region close to the majority, a CDN for everything cacheable, and an architecture that avoids unnecessary sequential round trips.
Go multi-region when you have measured a problem that only multi-region solves — usually a large secondary market with genuinely poor performance, or an availability requirement that survives losing a region.
Reducing round trips matters more than you think
Since each round trip carries the full distance penalty, the highest-value optimisation for a distant audience is making fewer of them.
Combine sequential API calls into one where possible. Move logic that requires several queries to the server rather than orchestrating it from the browser. Cache aggressively at the edge. Avoid client-side waterfalls where one request's response determines the next.
A page making eight sequential requests from Australia to Europe is slow for reasons no server upgrade fixes.
A practical decision
Check data residency requirements first, since they may decide it. Then look at where your users actually are and choose the closest region. Add a CDN for assets and cacheable pages. Then measure real-user performance by country, and only consider a second region if a substantial market is genuinely underserved.
And if you inherit a site hosted somewhere odd — a common finding — check the region before optimising anything else. It is occasionally the whole explanation.
If your site is fast for you and slow for customers elsewhere, book a call.
Common questions
How much does hosting region affect performance?
Substantially, because distance sets a floor optimisation cannot pass. A request between continents takes roughly 100 to 150 milliseconds each way, and pages that make several sequential requests multiply that — turning a physics penalty into a second of waiting.
Should I host near my team or near my users?
Near your users, always. Hosting near the team is a common mistake precisely because it feels fast during development. Use analytics by country and real-user performance data segmented geographically to decide, rather than convenience.
Does a CDN mean the hosting region doesn't matter?
No. A CDN removes distance for cached assets and cacheable pages, but anything dynamic — a logged-in dashboard, a search, a checkout — still reaches your origin. If your product is mostly authenticated, the CDN helps less and origin placement matters more.
When should I run in multiple regions?
Only after measuring a problem that nothing else solves — usually a large secondary market with genuinely poor performance, or an availability requirement that survives losing a region. Application servers duplicate easily, but the database forces real distributed-systems trade-offs.
What if data residency rules apply to my project?
They override performance considerations, and you should check them before choosing. Personal data from some jurisdictions must stay within them, and public sector, health and financial contracts often specify a country outright. Moving a database between regions later usually involves downtime.
