# Cache Hit, Still Slow: 6 in 10 of Those Sites Have a Fast Server and No Edge

> 534 WordPress sites hold a cache hit and still take over 400ms. On 227, Google clocks the server at 21ms, so the slow byte is distance, not the host.

- Published: 2026-10-12
- Author: xSpeed Cache Team
- Tags: TTFB, Hosting, Research, Performance, check:D1
- Canonical: https://xspeedcache.com/blog/cache-hit-slow-server-or-distance/

---

Updated October 2026

Of the 2,291 WordPress sites in the xSpeed Scan public archive on 12 October 2026, 534 return cache-hit evidence in their response headers and still take over 400 milliseconds to deliver the first byte, at a median of 640ms. On 227 of them, Google's own Lighthouse run measured the same server answering in a median of 21ms. The comparison people expect here is one host against another. The more useful comparison is between the two timings already sitting in the same report, because they disagree about what is slow often enough to send a site to the wrong fix. This study is about which group a site belongs to, and it is written by the team that sells a caching plugin.

## Quick Summary: Which Fix Your Site Actually Needs

| If you want | Do this | Why |
|:---|:---|:---|
| To know whether your server is slow or merely far | Compare your scan's first-byte figure against the server-response line in the same report | On 61.4% of this cohort the two disagree by more than 3× |
| To fix a genuinely slow origin | Change the host or the plan, not the plugin | 62 sites here are slow in both instruments, and their mobile LCP is 8.3s |
| To fix a fast origin that is far away | Put an edge in front of the HTML | Zero of the 227 distance-bound sites serve HTML from an edge |
| To stop paying for a migration you do not need | Read both numbers before you move anything | A median 35× gap between the two readings is distance, not hardware |
| To check your own site in a minute | Run the free xSpeed Scan and read check D1's evidence line | It prints both timings and names the gap |
| To decide whether a cache plugin can help at all | Check whether your cache is already hitting | All 534 sites here already hold a cache hit |

Three weeks ago [the headroom study](https://xspeedcache.com/blog/when-not-to-use-caching-plugin/) named this cohort in a single row and called it a hosting decision. That row was half right, and this article is the half it got wrong.

## The Cohort We Named in September, Re-Measured in October

The September study harvested 886 WordPress sites carrying a server probe and reported that 199 of them, 22.5%, held a cache hit and still took over 400ms, at a median of 642ms. Its conclusion was that caching was already doing its job and the remaining time belonged to the server and the distance to it, which made it a hosting decision.

The archive has grown 2.6× since. The cohort did not change shape:

| Reading | Archive WordPress sites | Cache hit and over 400ms | Share | Median first byte |
|:---|:---:|:---:|:---:|:---:|
| 22 September 2026 | 886 | 199 | 22.5% | 642ms |
| 12 October 2026 | 2,291 | 534 | 23.3% | 640ms |

A share that holds within one point and a median that moves by two milliseconds across a 2.6× growth in sample is the most reassuring thing in this study. Whatever produces this cohort is structural. It is not an artefact of which sites happened to be scanned in September.

What September could not do was say why those sites are slow, because it only had one timing. Every report carries two.

## How the Split Was Measured, and What It Cannot See

Every scan report holds two independent measurements of how quickly the document starts arriving. Our own probe requests the page from Vilnius, Lithuania, takes the best of two requests, and its evidence line states that the figure "includes the network round trips between us and your origin, not just server time". Google's Lighthouse run, executed from Google's own infrastructure, reports a `server-response-time` audit for the same document. Both land in the same JSON.

[The cache-hit lift study](https://xspeedcache.com/blog/cache-hit-lift-study/) established in September that these two instruments value the same cache hit at 481ms and at 11.5ms, a factor of 42, and concluded that Google's figure is the wrong gauge for asking whether a cache is working. That conclusion stands. This study asks a different question, and it is the one question Google's figure answers well: is the origin slow, or is it simply distant from our prober? A measurement taken inside Google's network carries almost none of the Vilnius round trip, so where the two numbers diverge, the divergence is the distance.

**Method.** Every report in the public archive was read from the scan API on 12 October 2026: 3,350 sites across 8,036 scans run. 2,291 are WordPress. 1,547 of those return cache-hit evidence. 534 of those take over 400ms on our probe. Of those 534, 370 also carry a Lighthouse `server-response-time` figure, and each was placed in one of three groups by that figure alone: at or under 200ms, between 200ms and 400ms, over 400ms.

**Four things this split cannot see.**

1. **164 of the 534 carry no Lighthouse figure at all**, because the audit did not report for that page. They are excluded rather than assumed, so every group size below is a count within 370, not within 534.
2. **One prober, one city.** Our figure comes from a single European vantage point. A site whose origin sits in Sydney is far from Vilnius and near its own visitors, and this method reads it as distance-bound without knowing where its audience is.
3. **The archive is our own scanner's traffic, and it is skewed towards our own users.** 1,276 of the 2,291 WordPress sites run xSpeed Cache, and within this cohort the share is higher still at 404 of 534. Cache-hit evidence is also easier for our scanner to see on our own header than on a competitor's HTML comment, so "holds a cache hit" is a floor on every plugin including ours.
4. **Real-user data is too thin to settle it.** Only 24 of the 227 distance-bound sites carry Chrome field data at all. Where it exists it points the right way, and the sample is too small to carry the claim on its own, so it is reported below as a direction rather than a result.

Seven rubric versions appear across the 534, from 2026.08.1 to 2026.10.1. Both numbers used to build the split are raw probe and audit measurements rather than rubric-scored values, so pooling them across versions is safe. The scores quoted later in this article are rubric-dependent and are reported per group rather than compared against the archive.

## Three Groups, and the Biggest One Is Not About Hosting

| Group | Sites | Share | Our probe | Google's server response | Scan score | Lighthouse | Mobile LCP |
|:---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
| Distance-bound: Google sees 200ms or less | 227 | 61.4% | 647ms | 21ms | 72 | 88 | 5,626ms |
| Ambiguous: Google sees 200ms to 400ms | 81 | 21.9% | 667ms | 290ms | 67 | 76 | 6,834ms |
| Server-bound: Google sees over 400ms | 62 | 16.8% | 548ms | 638ms | 67 | 72 | 8,327ms |

![Grouped bar chart of 370 cache-hit WordPress sites split into three groups by Google's server-response figure: distance-bound 227 sites at 647ms on our probe against 21ms in Google's, ambiguous 81 sites at 667ms against 290ms, server-bound 62 sites at 548ms against 638ms](https://xspeedcache.com/images/blog/cache-hit-slow-two-instruments.webp)

The queued expectation for this study was that the cohort would be mostly hosting-bound. It is not. The largest group by a wide margin has a server that Google clocks at 21 milliseconds. The median ratio between the two readings in that group is 35×, and at the upper quartile it is 169×. Those two figures come from different instruments and are never subtracted from each other here, only divided, because the ratio is the signal and the difference would be meaningless.

The three rows also fall in order on the one metric a visitor actually feels. Mobile Largest Contentful Paint climbs from 5.6 seconds in the distance group to 8.3 seconds in the server group, against the 2.5-second threshold [web.dev publishes as a good LCP](https://web.dev/articles/lcp). The group our own headline number treats as worst is the group that is least bad for users, and the group that is genuinely worst is the smallest one. That ordering is the finding.

## The Distance Group: A Fast Origin With Nothing In Front Of It

227 sites, median first byte 647ms on our probe and 21ms in Google's. They share three things.

**The cache is working and has nothing left to give.** Check D2, page served from cache, passes at the full 7 points on all 227. There is no second page cache to add. A plugin has already done the part a plugin does.

**There is no edge in front of the HTML.** 145 of the 227, 63.9%, show no CDN at all. Of the 82 that do, not one serves the HTML document from the edge: the CDN is in the path and forwarding to the origin on every request. That matches the pattern [the CDN adoption study](https://xspeedcache.com/blog/wordpress-cdn-adoption-ttfb-study/) measured across the whole archive, and it is the single fact that makes this group actionable, because an origin answering in 21ms with nothing cached at the edge is a solved problem with an unused solution.

**The remaining weight is in bytes, not seconds of server time.** Median total transfer in this group is 2.26 MB. Their Lighthouse score of 88 says the page itself is built reasonably, and their 5.6-second mobile LCP says the bytes still arrive too late on a phone. Moving this site to a faster host changes neither number.

Where Chrome field data exists for these sites, 24 of 227, the median real-user LCP is 2.94 seconds. For the server-bound group the same figure is 4.07 seconds on 11 sites. Both samples are small and both are stated here with their n, because a direction on 24 sites is worth printing and a conclusion is not.

## The Server-Bound Group: 62 Sites Where Google Agrees With Us

This is the group the September row described, and it is real. Our probe reads a median 548ms and Google reads 638ms, which is the only group where Google's figure is worse than ours. Lighthouse sits at 72, the scan score at 67, and mobile LCP at 8.3 seconds.

Six of the 62 have a CDN. The cache is hitting on all of them, as the cohort definition requires, so the slow byte is being produced by the origin while serving a cached file, which points at the machine rather than at WordPress. For these sites a plan change or a host change is the fix, and no plugin setting reaches it. We recommend [xCloud](https://xcloud.host/) for that move, and xCloud is ours: WPDeveloper, which builds xSpeed Cache, and xCloud are both Startise companies.

The 81 sites in the middle band are the honest remainder. At 290ms in Google's own network their origins are neither fast nor clearly at fault, and the split as built cannot resolve them. They are reported rather than assigned.

## The Second-Number Test: Read Both Timings Before You Move a Site

The framework this study produces is four steps, and it costs nothing:

1. **Scan the site and read check D1's evidence line, not just its score.** The line prints both figures and names the gap in plain words. Our probe's number comes first; Google's server-response figure is quoted in the same sentence.
2. **Divide.** Take your first-byte figure and divide it by Google's server-response figure for the same page. Under about 3× the two instruments broadly agree and the origin is the suspect. Over 3× they disagree, and the excess is the network between the prober and the origin.
3. **Place the site in one of three states.** Both numbers slow means the origin. Our number slow and Google's fast means distance. Both fast means the first byte is not your problem and the bytes after it are.
4. **State your limitation before you act.** A single prober cannot tell you where your visitors are. If the gap is wide, check Chrome field data or your own analytics for where traffic comes from before concluding the origin is well placed.

**What the test cannot do.** It cannot tell a slow origin from a fast origin behind a slow first hop inside the same datacentre, it cannot see any origin whose page Lighthouse declined to audit, and it has no opinion at all on the bytes that arrive after the first one. On the sites in this archive it separates 61.4% of a cohort from the fix they would otherwise have bought, which is the whole of its value.

![The four steps of the second-number test, from reading check D1's evidence line to stating the limitation, with a stacked bar showing where the 370 sites landed: distance 61.4%, ambiguous 21.9%, server 16.8%](https://xspeedcache.com/images/blog/second-number-test.webp)

Run the free scan on your own site: [xspeedcache.com/scan/](https://xspeedcache.com/scan/)

## What Our Own Scoring Does With This, and Why It Is Wrong

Check D1 grades time to first byte against a 200ms threshold using our probe's figure alone. Across the 227 distance-bound sites it awarded 372 of 1,816 available points: 134 sites scored zero out of 8, and 93 scored 4 out of 8. **1,444 points were docked for a slow server from sites whose servers Google measured at or under 200 milliseconds.** Across all 370 sites with both readings the figure is 2,300 points of 2,960.

![Check D1's scoring across the 227 distance-bound sites: 1,444 points docked, 372 awarded of 1,816 available, 134 sites scoring zero of 8 and 93 scoring 4 of 8, while check D2 scores the full 7 of 7 on all 227](https://xspeedcache.com/images/blog/check-d1-points-docked.webp)

The evidence line in each of those reports already says what is happening. One of them reads, verbatim:

> TTFB 524ms measured from Vilnius, Lithuania (EU) (best of 2 requests). This includes the network round trips between us and your origin, not just server time. Google measured your server responding in 3ms from its own network — the gap between the two numbers is distance, not your server.

The report tells the reader the truth in prose and then scores them as though it had not. A site owner who reads the number and skips the sentence concludes their hosting is bad. That is our defect, not theirs, and it belongs on the same list as the other scan checks whose scoring is narrower than their own evidence. The fix is available in the data already collected: score D1 on the lower of the two readings, or keep the current score and report the distance component separately so it cannot be mistaken for server time.

This is published because withholding it would leave the most decision-relevant fact in the study off the page. Our own plugin is also over-represented in the cohort, at 404 of 534 against 1,276 of 2,291 across the WordPress archive, and part of that is simply that our users scan with our scanner more often than anyone else's do.

## Running This Across a Portfolio of Client Sites

At one site the test is two numbers and ten seconds of arithmetic. At forty it is a spreadsheet, and the question changes from "is this server slow" to "which of these forty should I spend a migration on".

The scan API returns both figures per report, so the division can be run over an inventory rather than a page. That is how this study was built, and the same route is open to anyone: the public archive endpoints are documented with [the scan MCP](https://xspeedcache.com/docs/scan-mcp/), and an authenticated client can run them against your own sites. For [agencies](https://xspeedcache.com/use-cases/agencies/) the output is a ranked list of which sites need an edge, which need a host, and which need neither.

xSpeed Cache is one of several plugins that will get a WordPress site to a cache hit, which is the state every site in this study has already reached. What the free tier adds past that point is the browser-cache and resource-hint work that moves the bytes after the first one, and the [page cache documentation](https://xspeedcache.com/docs/page-cache/) lists which routes are expected to miss. Edge configuration for the HTML itself is covered in [the CDN documentation](https://xspeedcache.com/docs/cdn/), and [Free vs Pro](https://xspeedcache.com/free-vs-pro/) says which tier carries which module.

## Common Mistakes Teams Make With a First-Byte Number

- 🟥 **Reading one timing and buying a migration.** The most expensive mistake in this dataset. 61.4% of a cohort that looks hosting-bound on one number is not hosting-bound on two.
- 🟧 **Treating a CDN in the path as an edge for the HTML.** 82 of the 227 distance-bound sites have a CDN and none of them serve the document from it. A CDN that forwards every HTML request is a DNS entry, not a cache.
- 🟨 **Using Google's server-response figure as a cache receipt.** It barely separates a hit from a miss, which is the September finding and still true. It is good for one job and poor at the other.
- 🟩 **Adding a second cache plugin to a site that already holds a cache hit.** Two purge mechanisms that disagree about staleness, and no new speed. [The guide to what caching does not fix](https://xspeedcache.com/blog/caching-did-not-fix-slow-wordpress/) covers the symptoms.
- 🟦 **Comparing a first byte measured after a host change against one measured before, from a different place.** [The post-migration regression guide](https://xspeedcache.com/blog/site-slower-after-host-change/) sets out how to split the number before drawing a conclusion.
- 🟪 **Assuming a wide gap means the origin is well placed.** It means the origin is far from Vilnius. Where your visitors are is a separate question and [the first-byte reduction guide](https://xspeedcache.com/blog/reduce-ttfb-wordpress/) covers the part you can change.

## Frequently Asked Questions

### My scan says my server takes 700ms but my host says it responds in 20ms. Who is right?

Both, about different things. Your host is measuring the time its machine spends producing the page. The scan is measuring the time between a request leaving Vilnius and the first byte arriving back, which includes every network hop in between. When the two disagree by more than about 3×, the difference is distance.

### I moved hosts because a speed test said my server was slow, and nothing improved. What happened?

On the evidence here, that is the most likely outcome for 61.4% of sites in this state. If the new host is roughly as far from the prober as the old one, the number that sent you moving does not move. Check Google's server-response figure on the old report if you still have it.

### Where exactly does the second number come from?

The `server-response-time` audit in the Lighthouse run that every scan report includes. [Google's documentation for that audit](https://developer.chrome.com/docs/lighthouse/performance/server-response-time) describes it as the time for the main document to start arriving in its own run, measured from Google's infrastructure rather than from ours.

### My site has Cloudflare in front of it and the first byte is still 600ms. Is the CDN broken?

Probably not broken, probably not caching your HTML. That was the state of all 82 CDN-carrying sites in the distance-bound group here. A CDN caches static assets by default on most setups and leaves the HTML document to the origin unless you tell it otherwise.

### I enabled a caching plugin and check D1 did not improve at all. Is the plugin working?

Check D2 rather than D1. If D2 passes, the cache is serving and the plugin has done its job, and whatever time remains is the origin plus the distance to it. Every site in this study is in exactly that position.

### Does a faster host fix a 2.26 MB page?

No. The distance-bound group here carries a median 2.26 MB of transfer and a 5.6-second mobile LCP with a server that answers in 21ms. Those seconds are in the bytes, not the first one.

### Which of the three groups should spend money first?

The server-bound group, which is the smallest. Its mobile LCP is 8.3 seconds against 5.6 in the distance group, and a host or plan change is the only lever that reaches it. The distance group should spend configuration time instead of money, on caching the HTML at an edge.

### Why trust an archive the scanner's own vendor publishes?

Treat the skew as stated rather than absent. 1,276 of 2,291 WordPress sites in it run our plugin, so it over-represents our own users, and the cohort over-represents them further. The split itself does not depend on which plugin a site runs: it compares two timings of the same document, and both come from instruments outside the site.

### Can I run this comparison without a scan?

Yes, approximately. Time your own first byte from a machine near your visitors, then run PageSpeed Insights on the same URL and read its server-response figure. The arithmetic is the same. A scan is faster because it prints both numbers in one place and names the gap.

### Our agency manages 40 sites. Is there a bulk version?

The scan API returns both figures per report, so the division runs over an inventory. The endpoints are documented with the scan MCP, and the output is a list of which sites need an edge, which need a host, and which need neither.

### Does any of this change what a cache plugin is for?

It narrows it honestly. A page cache takes server time out of the first byte, and the evidence from the September lift study is that it takes a lot: 481ms at the median. It has no mechanism for the distance between your origin and your reader, and no mechanism for 2.26 MB of page.

## Conclusion: Host, Edge, or Neither?

| If your two readings say | The fix is | Not |
|:---|:---|:---|
| Both slow | A host or plan change | More plugin settings |
| Ours slow, Google's fast | Cache the HTML at an edge | A migration |
| Both fast, LCP still bad | Page weight and images | Anything about the server |

The row in the September study that called this cohort a hosting decision was right for 62 sites out of 370 and wrong for 227. The difference between those two answers was always in the report, one line below the number everybody reads.

**What to do this week:**

1. Scan your slowest site and read check D1's full evidence line, not its score.
2. Divide your first-byte figure by Google's server-response figure. Over 3× and the origin is probably not your problem.
3. If the gap is wide, turn on HTML caching at your edge before you price a migration.
4. If both numbers are slow, price the migration, and look at [xCloud](https://xcloud.host/) among the options. It is ours, and it is where we would move a server-bound site.
5. If both numbers are fast and the page is still slow, the work is in the bytes. xSpeed Cache is free on wordpress.org and its browser-cache, minify and lazy-load modules are the free tier's answer to that; paid plans start at $29/yr with a 14-day money-back guarantee on [pricing](https://xspeedcache.com/pricing/).

If you run this test on your own sites and get a split that looks nothing like ours, that is worth knowing, and the [xSpeed Hub](https://xspeedcache.com/xspeed-hub/) is where those readings are compared.