A backend team profiles a slow screen, finds every individual database query running in a few milliseconds, and concludes performance is fine. The screen still takes several seconds to load on a real phone. The gap between those two facts is almost never explained by server-side speed — it's explained by the shape of the API itself: how many separate round trips the client has to make before it has everything it needs, and how many bytes travel across a connection that, unlike the data center the backend was profiled in, has real, often highly variable latency and bandwidth. Performance is an API design property, not just a backend implementation property, and it's one most teams don't measure until a user on a slow connection complains.
Two costs dominate almost every API performance problem, and they behave differently, which is exactly why they need to be reasoned about separately rather than folded into one vague notion of "slow." Round trips cost you a fixed delay each, dictated by the network path's latency, no matter how small the request or response is. Payload size costs you a delay that scales with how much data actually has to cross the wire, dictated by available bandwidth. A design decision that trades one for the other — fetching everything in one larger call instead of many small ones, or the reverse — is making a real, quantifiable tradeoff, and this lesson is about reasoning through that tradeoff deliberately instead of by instinct.
The single most common, most fixable version of this problem has a name: N+1. One call to fetch a list, then one additional call per item in that list to fetch something related to it, is a pattern that creeps into REST endpoints, GraphQL resolvers, and ORM-backed code equally easily, and it is almost always invisible in a backend profiler that measures each of those N+1 calls as individually fast, because no single one of them is slow — there are just far too many of them.