I cut the endpoint from 3 seconds to 200ms, and the app on the warehouse floor got slower.
I had split a fat order response into a thin list plus a detail call per line. The list query stopped joining everything at once, so the number on my dashboard dropped exactly as designed.
Then the operations people told me picking felt worse.
On a handheld over patchy wifi, the screen now needed one round trip per line item before it could render anything useful. Each call was fast. Together they weren't. Connection setup, auth, a retry whenever the link dropped, all of it multiplied by the number of lines on the order.
The rework is not what it cost me. It cost me credibility: the metric I reported had improved while the job people actually do had degraded, and I only found out because someone on the floor complained.
What I do differently now: the unit I measure is a user action, not an endpoint. "Courier opens an order", so total round trips, total bytes, worst case on a bad network. Endpoint latency sits inside that as one factor, not as the answer. And before I split a response, I count the calls the client will be forced to make afterwards.
Request latency is probably the easiest thing to improve, and the easiest thing to improve at someone else's expense.
I write up more of these trade-offs on my blog, if that's useful: https://polycratia.com/c/128a8657
So it's worth knowing where you draw your latency budget: per endpoint, or per screen...