The catalog page would not show a delivery price until every carrier I was integrated with had answered.
That was the three seconds. Not a slow query: a chain of rate calls, each one honest, each one answering a question nobody had asked yet. Someone browsing a product does not need a quotable rate. They want a rough idea of what shipping costs before they care.
So I stopped optimizing the calls and split the endpoint by how exact the answer had to be.
Browsing gets a precomputed table: zone, weight bracket, carrier, refreshed on a schedule. Checkout keeps the live calls, where the number turns into a commitment. Same data, two different promises.
The browse path landed around 200 milliseconds because it stopped talking to anyone. The checkout path is still slow, and that is fine: by then the user is entering an address, not comparing products.
The piece I would not skip: precomputed estimates go stale quietly. I log the estimate against the live quote and watch the gap, because a fast wrong number is worse than a slow right one.
What I do differently now: before profiling anything, I ask what accuracy the response actually needs. A lot of latency is just answering a harder question than the screen requires.
I am curious where you put that line: one endpoint with a freshness flag, or two endpoints with two contracts.