# Fast for You, Slow Abroad: It Depends Who Answers Your First Byte > Your page is quick from your desk and slow from another continent. Find out whether an edge near your visitor or your own origin answered, then fix that half. - Published: 2026-10-02 - Updated: 2026-10-04 - Author: xSpeed Cache Team - Tags: CDN, Performance, Caching, TTFB, WordPress, Troubleshooting, check:D5, platform:cloudflare - Canonical: https://xspeedcache.com/blog/slow-for-visitors-abroad/ --- Updated October 2026 The median TLS negotiation on a CDN runs 57 milliseconds against 177 milliseconds straight to an origin server, over three times slower, per the HTTP Archive [Web Almanac's 2025 CDN chapter](https://almanac.httparchive.org/en/2025/cdn) published 15 January 2026. Nothing about your site changed between those two columns. Only which machine picked up the phone. The comparison people expect is a fast host against a slow one. The more useful one is who answered: something near your visitor, or your server. This guide separates the two and fixes whichever half is yours, buying nothing. ## Quick summary: which half of the distance you are paying | If you see this | Do this | Why | |:---|:---|:---| | Nothing in front of the site | Put a CDN in front | Every phase of the first byte crosses the full distance | | A CDN in front, `cf-cache-status: DYNAMIC` | Make HTML eligible with a cache rule | The handshake lands nearby, the document still crosses | | HTML cached, first view per region slow | Turn on Tiered Cache | Each data centre caches alone, so every region pays a first miss | | Only logged-in pages and checkout slow | Move the origin toward that audience | Those never cache, so they always travel | ## Confirm it is geography and not your server "It is fast for me" is a warm measurement. Your browser holds an open connection, your DNS answer is cached, and your own reloads keep the page warm. A first-time reader nine time zones away shares none of that. One request settles it, made **from the slow region**, not from your desk: ``` curl -so /dev/null -w 'tls %{time_appconnect} first-byte %{time_starttransfer}\n' https://example.com/ ``` Divide the first figure by the second. That share is the wait before your site was asked for anything. The remainder is one more trip plus whatever your server did, and the next two sections separate them. **One trap, easy to walk into.** Behind a VPN, a corporate proxy or any intercepting gateway, both phases are timed to the gateway, not to your site. A connect under five milliseconds to another continent is impossible, so it proves you measured the wrong machine. ## Every phase of the first byte crosses the same distance Time to First Byte is not one journey. Per [web.dev's guide](https://web.dev/articles/ttfb), updated 18 November 2025, it sums redirect time, service worker startup, DNS lookup, connection and TLS negotiation, and the request itself. It puts a good TTFB at 0.8 seconds or less and a poor one above 1.8 seconds. ![Who answers the first byte: origin only, a CDN with uncached HTML, and HTML cached at the edge](https://xspeedcache.com/images/blog/fbwho.webp) Read each phase against what a fix reaches: | Phase | Crosses the distance when | Shortened by | |:---|:---|:---| | DNS lookup | Your nameservers sit far away | Anycast DNS, in most CDNs | | TCP and TLS | Nothing terminates the connection nearby | Any CDN in front of the site | | Request to first byte | The answerer must ask your origin | HTML cached at the edge | | Server think time | Always, wherever the visitor is | A page cache at the origin | A page cache is the last row only. ## The region's first visitor pays for everyone behind them Putting Cloudflare in front is not the same as having it answer. A direct probe of 1,748 WordPress sites in our scan archive reports a CDN signature on 33.5%, and of the 556 behind Cloudflare, 330 returned `cf-cache-status: DYNAMIC`, meaning the origin answered with no cache lookup. The breakdown is in [our CDN adoption study](https://xspeedcache.com/blog/wordpress-cdn-adoption-ttfb-study/). Cache Rules make the document eligible, and Cloudflare's documentation, updated 14 August 2026, states they are available on the Free plan, limit 10. ![A region's cold path from edge miss to upper tier to origin, and where each fix cuts it](https://xspeedcache.com/images/blog/coldpath.webp) Then one more thing bites. Cloudflare's [Tiered Cache documentation](https://developers.cloudflare.com/cache/how-to/tiered-cache/), updated 29 September 2026, states that uncached content means "the Cloudflare edge data centers must contact the origin server". Each data centre caches alone, so your first reader in São Paulo pays a full origin trip while Frankfurt has held the page for hours. Tiered Cache puts an upper tier between them, on Free as well. ## A page cache sits at your origin, and so does your HTML xSpeed Cache, which is ours, serves cached pages as static files before PHP starts, cutting server think time to a 5 to 15 millisecond hit. It does not move the file. A reader in Jakarta still waits for the round trip to wherever your server lives, and saves only the part it was never slow at. Our own CDN panel is narrower than its name suggests. [Our CDN settings](https://xspeedcache.com/docs/cdn/) rewrite asset URLs across 19 file extensions, so images, fonts, stylesheets and scripts come from a pull zone near each visitor. The document is not one of them. Everything after the first byte gets quicker and the first byte does not move, which is what people report when they expected the opposite. Neither of those changes who answers the document, which is why the cache rule above is the step that moves your first byte. ## Running this across client sites in four time zones Across twenty-five sites the question becomes which one regressed. [xSpeed Hub](https://xspeedcache.com/xspeed-hub/) grades a fleet from one screen, and our [Cloudflare integration](https://xspeedcache.com/docs/cloudflare/) purges the edge whenever xSpeed purges itself, on by default, so the two layers stop disagreeing. Its cache level, browser TTL and APO controls are Pro, and APO needs a paid Cloudflare plan, so the free path stays the cache rule. Run the free scan on your own site: [xspeedcache.com/scan/](https://xspeedcache.com/scan/) Hosting is the other half: a cache is only as fast as the server behind a miss. We recommend [xCloud](https://xcloud.host/), and it is ours: xCloud and WPDeveloper are both Startise companies. [WooCommerce stores](https://xspeedcache.com/use-cases/woocommerce/) feel it most, since carts never cache. ## Common mistakes with an audience in other countries | Mistake | What it hides | |:---|:---| | Testing from your own browser | You are the warmest visitor the site has | | Expecting an asset CDN to move the document | Different file, different fix | | Moving the server before measuring | Several things change at once, as in [a host move](https://xspeedcache.com/blog/site-slower-after-host-change/) | ## Frequently Asked Questions ### My host is in Europe and my visitors are in Asia. Should I move the server? Only if most of your traffic is uncacheable. Cached HTML answered at an edge makes the origin's location nearly irrelevant for anonymous readers. Sessions, carts and REST calls still travel, so move it toward those readers. ### Does putting a CDN in front improve Largest Contentful Paint as well? Less than you would expect. Our 958-site study reports caching cut TTFB sharply and left LCP alone, because LCP is mostly render work and asset weight. [Why caching did not fix a slow site](https://xspeedcache.com/blog/caching-did-not-fix-slow-wordpress/) covers the split. ### I enabled a CDN and my overseas numbers did not move. What did I miss? Read `cf-cache-status`, or its equivalent, on an HTML response. If it says `DYNAMIC`, `BYPASS` or `MISS` every time, the edge proxies without caching, and a cache rule is the missing step rather than a bigger plan. ### My checkout is still slow for international customers. Why did none of this help? None of it applies to checkout. Those pages must be personal, so they skip every cache and pay full distance. Shorten the work instead: fewer queries, a quicker origin, an object cache. ### How do I know the fix worked rather than the cache being warm? Re-measure from that region on a cold connection and confirm the HTML cache header says the edge answered. [Checking whether caching is working](https://xspeedcache.com/blog/check-wordpress-caching-working/) reads those headers, and [reducing TTFB](https://xspeedcache.com/blog/reduce-ttfb-wordpress/) covers the origin half. ## Conclusion: shorten the cold path, not your own Your experience is the warm path and your visitor abroad is on the cold one. Measure from their region, find who answered the first byte, and fix that layer. **What to do this week:** 1. Measure the first-byte phases from the region that complained. 2. Read the cache header on an HTML response, not on an image. 3. Add a cache rule making the document eligible, then confirm the header changed. 4. Turn on Tiered Cache so one region's miss stops at an upper tier. 5. Keep the origin quick for everything uncacheable with xSpeed Cache. [Free vs Pro](https://xspeedcache.com/free-vs-pro/) shows where the line falls and [pricing](https://xspeedcache.com/pricing/) starts at 29 dollars a year, founding price, with a 14-day money-back guarantee. Got a region that stayed slow? Post the header you saw and the city it came from, and we will read it together.