How Server Location Affects WordPress Loading Times
A customer in Sydney clicks a link to a shop in Toronto. Before a single line of that page is drawn, her request travels roughly 15,000 km, waits for the server to build the page, and travels back. The physical part of that trip cannot be optimized away by a faster processor or a leaner theme. Light moves through fiber at about 200,000 km per second, which works out to 5 ms for every 1,000 km in one direction, and the route is never a straight line. Server location is the one factor in page speed that is settled before any code executes.
The Distance Floor
Engineers use a rough rule for this. Every 100 km between a visitor and a server adds roughly 1 ms of round trip time, and real networks come in at 1.5 to 2.5 times that theoretical minimum because traffic follows cable routes instead of great circles. Toronto to Sydney is a floor of about 150 ms in each direction under ideal conditions, and 200 ms or more in practice.
No amount of bandwidth changes this. Bandwidth determines how much data moves once the connection is open. Distance determines how long the visitor waits for the connection to open at all, and a WordPress page opens several.
Handshakes Before the First Byte
The first request to a server is not one trip. A TCP connection costs one round trip. The TLS negotiation on top of it costs one or two more. At a round trip time of 100 ms, the browser spends 200 to 300 ms on handshakes before it has sent the request the visitor actually cares about. A lightweight site hosted far away can lose to a heavier site hosted nearby. The heavy site’s extra 200 KB of assets downloads in parallel once the pipe is open. The distant site’s handshake penalty is paid up front, serially, every time a new connection is opened.
Region Availability at Signup
Where a site is physically served is decided at signup, and the map of available regions varies from one company to the next. A wordPress hosting provider with data centers on three continents gives a business in Europe an option a single-region company cannot, and the choice costs nothing extra at setup.
A Canadian retailer with a Canadian customer base should not accept a default deployment in Frankfurt because the signup form suggested it. The default region is a convenience for the company selling the plan. It says nothing about where the audience is.
Time to First Byte and Server Work
Round trip time is one half of Time to First Byte. The other half is the server building the page. WordPress is a database-driven application, so an uncached page load means PHP execution, several database queries, plugin hooks firing, and only then a response.
A distant server compounds a slow one. A page that takes 400 ms to generate and 200 ms to reach the visitor delivers its first byte at 600 ms, which leaves very little room inside a 2.5 second Largest Contentful Paint target. According to the 2025 Web Almanac, only 62% of mobile pages meet that target, and it remains the hardest of the three Core Web Vitals to pass.
Content Delivery Networks and Their Limits
A content delivery network copies static files to servers near the visitor. Images, stylesheets, and scripts are served from an edge node in the same city, which removes the distance penalty for the bulk of the page weight.
The limit is in what an edge node can hold. The HTML document itself is generated per request on a standard WordPress install, so unless full-page caching is active at the edge, the browser still makes the long trip to the origin server for the document, and everything else waits behind it. A network of 300 edge locations does not help the one request that cannot be cached.
Some pages cannot be served from cache at all. A logged-in dashboard, a cart with items in it, a checkout page, and a search results page are all generated per visitor, and most caching plugins exclude them by setting cache-control headers that tell the edge not to store the response. On those pages the origin server’s location is the only thing that matters, and the visitor pays the full distance cost on every click.
This is where the location decision has its sharpest effect. A brochure site with 12 static pages will feel fine on a distant server behind a good edge cache. A membership site or a store will not, because the pages that make it money are precisely the pages that cannot be cached.
Regional Audiences and Server Placement
Analytics answer this question better than intuition does. Pull the country breakdown of sessions for the past 90 days and look at where the traffic concentrates. If 70% of visitors are in one country, the server belongs in or near that country, and the remaining 30% can be handled by an edge network.
Split audiences complicate the picture. A business with half its customers in Los Angeles and half in London has no single correct answer, so the usual approach is to place the origin near the higher-value half and accept the compromise for the rest. Multi-region deployments with database replication solve the problem properly, and they cost accordingly.
A Test Worth Running Before Migration
Measure before deciding. Run a time to first byte test from three or four cities where the customers actually are, using any of the free testing tools that let a location be specified. Record the numbers. Then run the same test against a competitor whose site feels fast. When the gap is 200 ms or more, the cause is usually geography.
A migration to a closer region typically removes 100 to 300 ms from every uncached request, and it does so permanently, without a single change to the theme or the plugin stack. For a site failing its Largest Contentful Paint target by a small margin, that is often the entire fix, and it is the cheapest one available.