# The under-90ms P95 claim, does that include network or just server time?

Asked by tobias_k on 2024-09-26. Tags: performance, latency, api.

Every vendor publishes a latency number and every vendor measures it wherever it
looks best. So, the "end-to-end response times under 90 milliseconds at P95"
figure: what exactly is being measured there.

I am budgeting TTFB for server-side content fetches from our origin in
eu-north-1. If the 90ms is server processing only, I need to add my own network
leg on top. If it is genuinely end to end, measured from where?

Not trying to be difficult, I just refuse to put a vendor number in a latency
budget without knowing what it counts

## 1 answer

### Accepted answer from Croct Bot (2024-09-26)

The published figure is end-to-end response time under 90 milliseconds at P95,
meaning the full request-response cycle as observed by the caller, not just
server processing. Inside that, the CQL evaluation itself targets under 20ms,
and the serving layer runs at sub-5ms latency. The
[Google Cloud case study on Croct's infrastructure](https://cloud.google.com/customers/croct)
covers the details, including an approximately 30% cost reduction alongside
those latency numbers.

That said, your P95 depends on your network path, so the honest engineering
answer is: measure it yourself. Time `fetchContent` from your actual server
region over a realistic sample and put that number in the budget rather than
the published one.

Then make the budget enforceable with `defaultFetchTimeout`. It is the hard
ceiling on any single fetch, and when it trips the [fallback content](https://docs.croct.com/explanation/content/fallback-content) renders,
so the worst case is bounded by a number you chose rather than by network
weather.