Ask five hosting providers whether server location still matters and you’ll get five confident, slightly contradictory answers. The honest answer is: it matters less than it used to for a lot of what visitors see, and just as much as it ever did for everything else. Understanding the difference is what lets you make a smart decision instead of a superstitious one.
The physics you can’t cache
Data on a fiber optic line moves fast, but not infinitely fast. Light in glass fiber travels at roughly two thirds the speed of light in a vacuum, and every additional kilometer between a visitor and your server adds a small, fixed, unavoidable amount of delay. That delay is a floor. No amount of clever code, no PHP 8.3 opcode caching, no Redis object cache, and no NVMe drive can make a signal arrive before the laws of physics allow it to.
This floor is why a visitor in Sydney talking to a server in Virginia will always have a longer round trip than a visitor in Atlanta talking to that same server, no matter how well the server is tuned. Distance is not the only factor (routing, peering, and network congestion all add their own overhead), but it sets a baseline that nothing else can undercut.
RTT vs bandwidth: why small requests feel slow
Bandwidth and latency get confused constantly, and the confusion causes real decisions to go wrong. Bandwidth is how much data can flow per second once the connection is moving. Latency, and specifically round trip time (RTT), is how long it takes for a single signal to go out and come back. A high bandwidth connection with high latency can still feel sluggish, because so much of a web request isn’t about moving large files at all. It’s about many small round trips: DNS lookups, TCP handshakes, TLS negotiation, and the request/response cycle itself.
Loading a single WordPress page can involve several of these round trips before a single byte of the actual page content arrives. Each one pays the RTT cost. This is why Time to First Byte (TTFB) is so sensitive to physical distance and network path, even on a server with plenty of bandwidth to spare. It’s also why Core Web Vitals largely reward getting bytes moving quickly: Largest Contentful Paint (LCP), with its 2.5 second target, depends heavily on how fast the browser gets the first meaningful response, which starts with TTFB.
What server location does not fix
It’s worth being precise here. Interaction to Next Paint (INP), with its 200 millisecond target, is mostly about JavaScript execution and main thread work in the browser, not network distance. Cumulative Layout Shift (CLS), with its 0.1 target, is almost entirely a front-end layout issue. Server location primarily affects LCP and general responsiveness, not every Core Web Vital equally. Don’t expect a closer server to fix a bloated theme or an unoptimized image.
How edge caching changes the calculus
This is where the conversation gets more interesting than it was a decade ago. A CDN like Cloudflare sitting in front of your origin server changes the physics problem by moving the endpoint. Instead of every visitor’s browser talking directly to your origin, cacheable content, static assets, and full pages captured by something like LiteSpeed Cache can be served from an edge location physically near the visitor, regardless of where your origin server actually lives.
For a cached page, the visitor’s RTT is to the nearest edge node, not to your origin in a distant data center. That single change can erase most of the distance penalty for the majority of page views on a typical WordPress site, since most traffic hits pages that don’t change between visitors: home pages, posts, category archives, product listings. Cloudflare’s edge caching, combined with LiteSpeed’s full-page cache and Redis or Memcached for object caching on the origin, means a lot of requests never need to make the long trip at all.
Cloudflare also adds a WAF, bot mitigation, DDoS protection, and Universal SSL with HTTP/3 support in front of the origin, all of which reduce load and risk regardless of where the server sits. Keeping the origin IP unpublished, so traffic is forced through the edge network, matters here too: it’s not just a performance detail, it’s part of what makes the origin resilient against direct attacks that try to bypass the CDN entirely.
What still requires a trip to origin
Edge caching is not a universal fix, and pretending otherwise leads to bad assumptions. Several categories of request cannot be served from cache and will always pay the full origin round trip:
- Logged-in user sessions, including anything happening inside wp-admin
- Dynamic, personalized content such as cart contents or account pages on a store
- Form submissions and other POST requests
- API calls that need fresh data, including REST API requests from a headless front end or a mobile app
- The first request for any page that hasn’t been cached yet, or has just been purged
For sites that are heavy on logged-in activity, membership content, or e-commerce checkout flows, a meaningful share of traffic will always touch the origin directly. That’s exactly where origin location still earns its keep.
Choosing a region: practical guidance
Given all of the above, a reasonable approach looks like this: identify where the bulk of your traffic actually comes from, and where your dynamic, uncacheable traffic concentrates specifically (this is often narrower than your overall audience, since it’s driven by logged-in users and transactional flows). Choose an origin region close to that center of gravity. Then put a CDN in front of everything regardless of region, because it helps every visitor and adds security benefits that have nothing to do with geography.
If your audience is genuinely global with no concentration, origin location becomes a smaller lever, and investing in strong caching, a properly tuned object cache, and a well-configured CDN will do more for you than chasing the theoretically perfect data center.
Measuring it yourself
You don’t need to guess. curl exposes detailed timing information for any request:
curl -o /dev/null -s -w "DNS: %{time_namelookup}s Connect: %{time_connect}s TLS: %{time_appconnect}s TTFB: %{time_starttransfer}s Total: %{time_total}s\n" https://example.comRun this from different regions, or use a third-party latency testing service that hits your site from multiple global locations, and you’ll see the RTT floor show up directly in the TTFB numbers. wp-cli remains the standard tool for administering WordPress itself, and pairing it with straightforward network diagnostics like curl or traceroute gives you a clear, evidence-based picture instead of a hunch.
Takeaway
Server location hasn’t stopped mattering, it’s just been demoted from the whole story to one part of it. A CDN and full-page caching handle the geography problem for most cached, anonymous traffic. What’s left, logged-in sessions, dynamic pages, and API calls, still pays the physical distance tax every time. Pick an origin region close to where your uncacheable traffic actually lives, cache aggressively for everything else, and measure with real tools instead of assumptions.