How long a request takes from asking to getting an answer. Users feel it once it crosses a threshold.
Why it exists
Even a correct system feels broken if every action takes two seconds, and the delay is rarely the code itself: it is time spent waiting on the network, the database, and other services. You cannot improve what you cannot name and measure. Latency exists as the word for that waiting time, so teams can point at where the seconds go and decide which are worth removing.
How it actually works
Every request travels to the server, gets processed, and travels back. Add those up and you get latency, measured in milliseconds. Under about 100ms feels instant. Past a second, people notice and start to disengage.
Latency comes from distance (a server far away), slow work on the server (a heavy database query), or a slow network. Each is fixed differently.
A senior PM walks you through it
A junior PM, stuck
The dashboard shows search latency jumped to about 900ms after last week's release, and in standup I was asked where the time is going. I said "the search is slow" and got a look. I do not want to hand-wave; I want to point at the part that is actually slow.
Latency is not one number, it is a sum of steps, and almost always one step is eating it while the rest are fine. Rafi traced a single search for kacchi through the system and timestamped every hop; the whole answer is in seven lines. Here is the trace exactly as he pulled it. Read the last line for the total, then find where the jump lives.
Trace of one search for "kacchi", captured after v2.4.0
2026-03-03T15:20:11.000ZINFOsearch GET /api/search?q=kacchi received t=0ms
2026-03-03T15:20:11.897ZINFOsearch 200 response sent t=897ms
Click a step to see the lines it points at.
Mistakes I've seen
Reporting "the search is slow" with no breakdown. Slow where? Without the per-hop trace you cannot tell a network problem from a database problem, and the two are fixed in completely different ways.
Asking eng to "make everything faster". Six of the seven hops here are already under 15ms; effort spent on them buys nothing. One query owns 851ms of the 897.
Treating latency as a fixed property of the feature. This search ran in about 90ms before v2.4.0; the code did not get heavier, an index went missing, so this is a regression tied to a specific release, not just how search is.
Quoting a number the trace does not show. If it felt like two seconds but the trace says 897ms, report 897ms; sending eng to hunt for a slowness that is not in the trace wastes the sprint.
Say in standup: "The 900ms is almost all one database query: it is sent at 12ms and does not return until 863ms, so 851ms is spent waiting on that single query, and everything else in the request is under 35ms. It ran in about 90ms before v2.4.0, which points at a missing index." You found where the time goes instead of calling the whole thing slow.
Where a PM meets this
"Why is the app slow?" starts with finding which request has high latency. It is rarely everything; usually one call is dragging.
Latency is a product metric, not just a technical one: slower pages measurably lose sales and sign-ups.
Hear it in a meeting
"Search latency jumped to 900ms after the last release."