The endpoint took about three seconds, and for months that got filed as a backend problem.
It was the product page payload on a cross-border shopping platform. One field held a shipping estimate, and the estimate was honest: it asked several carriers for a live rate, waited for all of them, then returned the cheapest. Nothing on the page could render until the slowest carrier answered. The timing of my own code did not matter: the floor came from whichever integration was having a bad morning.
I didn't make the carrier calls faster. I asked who actually reads that field at that point in the funnel. Almost nobody: the number buyers cared about sits at checkout, and checkout recalculated it anyway.
So the page started serving a precomputed estimate from a rate snapshot, and the live multi-carrier call moved behind the checkout step, where the wait is both expected and worth it. The response came back in a couple hundred milliseconds.
The cost was real, not free: an estimate can now drift from the final price, so it has to be labelled as an estimate and watched for drift.
What I do differently now: before profiling anything, I list every field in the response and mark the ones that depend on a third party. A field that reaches outside your process is a latency promise you don't control.
Worth knowing where your slowest endpoint actually spends its time: in your code, or in someone else's API you call synchronously...