Many businesses host in Europe for good reasons: EU data residency, price-to-performance, or simply because the team is there. Then the US customers arrive, and the site that loads instantly in Frankfurt feels sluggish in New York and slow in California. The server is not slower for them. The distance is. This guide explains where the delay comes from, how to measure it, and the fixes in the order that usually gives the most benefit for the least work.
Why distance matters
Data travels through fibre at roughly two thirds of the speed of light, and real routes are longer than a straight line. A round trip between Western Europe and the US East Coast typically takes around 80 to 100 ms, and to the US West Coast around 140 to 170 ms. That sounds small, but a new visitor needs several round trips before the first byte of the page arrives: one to open the TCP connection, one for the TLS handshake with TLS 1.3, then the request itself, plus a DNS lookup. With the server’s own processing time on top, a page that takes 150 ms in Europe can easily take 500 ms or more from California, before a single image or script has loaded.
Step 1: measure from where your users are
Test from the US, not from your office. curl breaks a request into its phases:
curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer} total %{time_total}\n' https://www.example.com/Run it from a small test server or a monitoring service in the US East and West, and from Europe for comparison. If connect and tls are large, distance is the problem. If ttfb minus tls is large in every location, the server itself is slow, and you should fix that first. Real-user monitoring and the Core Web Vitals report in Google Search Console show what actual visitors in each country experience.
Step 2: put a CDN in front of the site
A content delivery network is the biggest single fix. Its edge servers in the US terminate the TCP and TLS connections close to the visitor, so those round trips take a few milliseconds instead of a hundred. Static files (images, CSS, JavaScript, fonts) are served from the edge cache. Even requests that must go back to Europe are faster, because the CDN keeps warm, reusable connections to your origin and often routes over a better network path. Our guide on how to choose a CDN compares the main providers.
Step 3: cache the HTML too
Static files are the easy part. The real win comes from caching pages: if the HTML for your home page, product pages and articles is cached at the edge, a US visitor gets the whole page from a nearby server and never waits for Europe. This needs care: logged-in users, carts, checkout and account pages must bypass the cache, and content updates must purge the right pages quickly. Done properly, most anonymous traffic is served entirely from the edge. On the origin, a page cache such as Varnish or NGINX FastCGI cache makes the remaining misses fast as well.
Step 4: use modern protocols
- TLS 1.3 needs one round trip for the handshake instead of two with TLS 1.2.
- HTTP/2 and HTTP/3 load many files over one connection. HTTP/3 runs over QUIC, which combines the transport and TLS handshakes and copes better with packet loss on mobile networks.
- Keep-alive and connection reuse between the CDN and your origin, so misses do not pay for a new handshake each time.
- Fewer third-party domains: every extra domain a page loads from means another DNS lookup and handshake. Self-hosting fonts is a quick win.
Step 5: make the origin fast
Every cache miss still crosses the Atlantic, so the time your server needs to build the page is added on top of the distance. Database query tuning, PHP OPcache, an object cache and enough CPU and memory keep that small. A miss that takes 80 ms to build plus 100 ms of distance is acceptable; one that takes 800 ms is not, wherever the visitor is.
Step 6: when to add a second origin in the US
If a large part of your traffic is logged-in or personalised and cannot be cached, such as a SaaS application, a dashboard or an API, a CDN helps less. Then consider running application servers in the US as well, for example in Hetzner’s Ashburn or Hillsboro locations or a US cloud region. This adds real complexity: the database has to be replicated or split, writes have to go somewhere consistent, and EU personal data may need to stay in Europe. Do it when measurements show it is needed, not by default.
A realistic target
With a well-configured CDN, cached HTML and a fast origin, most visitors on both sides of the Atlantic should see a time to first byte of a few hundred milliseconds or less for cached pages, and the difference between Europe and the US becomes hard to notice. Measure again after each step so you know which change made the difference.
Get help
TechProvidence engineers tune origins and CDNs together so sites are fast in every market we serve, with 24/7 support. See our CDN management and optimization and managed Hetzner services, read Hetzner vs DigitalOcean vs AWS for a European business, or contact us for a complimentary latency review.
