Troubleshooting Slow Response Times: Find the Bottleneck, Then Fix It

A product you own has a latency problem: it takes too long to respond to users. How would you go about solving it? ```hint Find where the time goes Before suggesting any fix, work out which step of a single user request is taking the time, and for which users it is slow. ``` ### Clarifying Questions - Is the slowness new, for example since a recent release, or has the product always been slow? How is latency measured today? - Which part of the experience is slow: the first load of the app or page, one action such as search or checkout, or everything? - Is it slow for everyone, or for a slice of users such as one region, one platform or people on slow mobile networks? - What speed are we aiming for, and how much engineering time or infrastructure cost can the fix take? ### What a Strong Answer Covers - A precise definition of the problem: which operation, which percentiles, which users, and the target to reach. - A systematic, data-driven breakdown of where the time is spent along the request path, from the device to the back end and back. - Fixes matched to the bottleneck actually found, with their cost and trade-offs, ordered by impact and effort. - Immediate mitigation versus a lasting fix, how the improvement is verified, and how regressions are prevented. - The product manager's part: judging how much the delay hurts users and the business, and coordinating the teams that own each layer. ### Follow-up Questions - The median response time looks fine, but the slowest 1% of requests take several seconds. Where would you look first, and why does that tail matter? - Engineering estimates a full quarter of work to fix the problem properly. How do you decide whether that beats the feature work it would delay? - How would you show that making the product faster actually changed how people use it?