# For users far from your servers, does the sub-90ms P95 still apply?

Asked by hiroshi on 2026-10-19. Tags: performance, p95, latency.

My audience is genuinely global, spread across regions that I suspect are
far from wherever Croct runs. I want to understand the published sub-90ms P95
with that in mind.

Is that figure something that holds for a visitor several thousand kilometres
from the servers, or is it realistically a near-the-datacentre number that
degrades for distant users? I would rather set expectations correctly for my
international traffic than optimise for the happy path only.

## 2 answers

### Accepted answer from Marcos Passos (2026-10-21)

The published figure is an end-to-end response time under 90 milliseconds
at P95, measured as the full request-response cycle rather than server
processing alone. The platform runs on Google Cloud, and in the
[Google Cloud case study on our infrastructure](https://cloud.google.com/customers/croct)
you can see the internal latency is sub-5ms alongside roughly a 30% cost
reduction, so the serving layer itself is not where distance shows up.

For a distant visitor, the honest framing is that your own network path
adds its leg on top of ours, so measure from your regions rather than
trusting one global number. Two things keep the experience robust
regardless of distance. First, content resolves on the server, so the
resolved variant is already in the response, there is no extra client round
trip stacked on the far-away user. Second, if a call is slow, fault
tolerance serves the [fallback content](https://docs.croct.com/explanation/content/fallback-content)
rather than blocking the page, so a bad network leg degrades to default
content instead of a hang. The
[server-side content rendering guide](https://docs.croct.com/reference/sdk/nextjs/content-rendering)
shows how the resolved variant ends up in the response.

If you want the precise definition of what the P95 counts, we broke it down
in [what the sub-90ms P95 covers](/answers/sub-90ms-p95-what-it-covers).

### Answer from vikram_r (2026-10-22)

Data point from us: we serve a lot of APAC and EU traffic from a single
origin and the extra latency we see on distant users is our own network leg,
not the personalization layer. Once we timed it from each region the
resolution cost stayed flat, the variance was all in the transit.

#### Reply from hiroshi (2026-10-23)

For anyone else with a global audience reading this later: the useful
takeaway is to instrument per region yourself and treat the transit leg
as the variable. The resolution cost was the constant in both answers
here, which matches what I measured after wiring it up.