There is no single good response time, but there are useful reference points. Google's Core Web Vitals call a page good when it loads within 2.5 seconds and responds to input within 200 milliseconds, at the 75th percentile. For a backend API, a common target is a p95 under a few hundred milliseconds for interactive requests. What matters more than any fixed number is measuring the right percentile and watching it against each route's own baseline. Here is why.
Is there a "good" response time?
Not as a single number. A good response time for a simple read is not a good response time for a search, a report, or a checkout that talks to a payment provider. Asking "what is a good response time" as if there is one answer is a bit like asking what a good price is: it depends on what you are buying. So the honest answer has two parts: a few reference points that are genuinely useful, and one rule that beats any fixed target.
It is worth getting right because speed maps straight to outcomes. A Google-commissioned Deloitte study of 37 brands and over 30 million sessions found that a 0.1 second improvement in mobile site speed lifted retail conversions by 8.4% and travel conversions by 10.1%.1 Small differences in response time are not cosmetic, they are revenue.
The reference points that do exist
There are two anchors worth knowing. For the frontend, Google's Core Web Vitals give concrete "good" thresholds: a Largest Contentful Paint (how fast the main content loads) within 2.5 seconds, an Interaction to Next Paint (how fast the page responds to a click or tap) of 200 milliseconds or less, and a Cumulative Layout Shift of 0.1 or less, all measured at the 75th percentile of visits.2 Those are the numbers Google itself uses to judge a page.
For the backend, there is no official standard, but a workable rule of thumb is a p95 in the low hundreds of milliseconds for interactive API calls, with slower being reasonable for anything a user expects to take time. The point of the table below is that "good" is a range tied to what the request does, not one universal figure.
| Kind of request | A reasonable "good" (p95) | Note |
|---|---|---|
| Simple read (fetch a record) | Under ~100ms | Should be fast; if it is not, suspect a missing index |
| Interactive action (login, save) | Under ~300ms | The common "feels instant" band for app actions |
| Search or list with filters | Under ~500ms to ~1s | More data and joins; still keep it under a second if you can |
| Report or aggregation | Seconds is acceptable | Users expect it to take time; show progress |
| Page load (frontend) | LCP under 2.5s, INP under 200ms | Google's Core Web Vitals thresholds, at p75 |
Why you measure percentiles, not averages
Notice every number above is a percentile, not an average. That is deliberate. The average response time is the most common way to measure latency and the most misleading. If 95 requests take 50 milliseconds and 5 take 4 seconds, the average is still a few hundred milliseconds, so the dashboard looks healthy while one in twenty users sits waiting.
Latency is one of the four golden signals from Google's site reliability engineering practice, the core set of things worth watching in any production system, alongside traffic, errors, and saturation.3 The way to watch it honestly is with percentiles. A percentile answers the question the average dodges: how slow is the slow end of my traffic, the part that actually generates complaints.
p95 vs p99: which to watch
p95 is the response time that 95% of requests come in under; p99 is the value 99% come in under. Put simply, p95 is where the slow requests begin and p99 is the slow tail your unhappiest users feel. You want both: p95 is more stable, which makes it good for baselines and alerts, while p99 is noisier but closer to an actual complaint.
Dean and Barroso's paper "The Tail at Scale" made the case that in real systems the tail is what defines the experience, because as one request fans out to more services, the odds it hits the slow p99 of at least one of them climb quickly.4 That is why "our average is fine" is cold comfort: the more moving parts you have, the more your users live in the tail. Measure it directly.
What to actually do with the number
Here is the rule that beats any fixed target: watch p95 and p99 per route, and compare each route to its own baseline, not to a universal number. A p95 of 400ms might be perfectly fine for a search and a red flag for a health check. What you are really looking for is drift: a route that used to come in at 180ms and now sits at 900ms. That change is the signal, and it points you at the exact request to trace and fix.
Traditional tools show you the percentile chart and leave you to spot the drift and go dig. Fixter works the other way: you drop in the SDK, built on OpenTelemetry, and your traces and metrics are stored, then you ask about latency in plain language over MCP from your editor. When a route's tail drifts up, it does the first pass for you, finds the slow requests, reads the traces, and tells you which step got slower.
The takeaway is not a magic number to memorize. It is a habit: measure the tail, per route, and react to drift. For the diagnostic side of that, see why is my app slow, and for the wider set of things worth watching, what you can do with your logs.
Key takeaways
- There is no universal good response time; it depends on what the request does
- Frontend reference: Core Web Vitals, LCP under 2.5s and INP under 200ms at p75
- Backend rule of thumb: p95 in the low hundreds of milliseconds for interactive calls
- Measure percentiles, not averages; the average hides the slow tail users feel
- Watch p95 and p99 per route against its own baseline, and react to drift
Frequently asked questions
What is a good response time for a web app?
There is no universal number, but useful reference points exist. Google's Core Web Vitals call a page good when it loads within 2.5 seconds and responds to input within 200 milliseconds, at the 75th percentile. For a backend API, a common practical target is a p95 under a few hundred milliseconds for interactive requests. Slower is fine for reports and batch work.
What is p95 and p99 latency?
p95 is the response time that 95% of requests come in under, and p99 is the value 99% come in under. They describe the slow end of your traffic. p99 is the slow tail your unhappiest users actually feel, which is why it matters more than the average, and often more than the median.
Why not just use the average response time?
Because the average hides the slow requests. If most requests are fast and a few are very slow, the mean stays low while a real slice of users waits. Percentiles like p95 and p99 show the slow tail directly, which is the part users complain about, so they are the honest way to measure latency.
Is p95 or p99 better to watch?
Watch both, but treat p95 as the early warning and p99 as the tail your worst-off users feel. p95 is more stable and good for baselines and alerts; p99 is noisier but closer to real complaints. The key is to compare each against a route's own normal, not a single global target.
What is a good API response time?
For an interactive API call, aim for a p95 in the low hundreds of milliseconds, and treat anything consistently over about a second as worth investigating. But the right number depends on the operation: a search or a report can reasonably be slower than a simple read. Watch the percentile against the route's baseline rather than one fixed number.
Sources
- Deloitte and Google, Milliseconds Make Millions (0.1s mobile speed improvement lifted retail conversions 8.4%, travel 10.1%)
- Google, Web Vitals (good thresholds: LCP under 2.5s, INP 200ms or less, CLS 0.1 or less, at the 75th percentile)
- Google, Site Reliability Engineering, the four golden signals (latency, traffic, errors, saturation)
- Dean and Barroso, The Tail at Scale, Communications of the ACM, 2013 (why the p99 tail defines user experience)