I am investigating request latency in a protected Next.js preview. The app uses the Node runtime in Frankfurt. I have matched native-browser timing, API-wrapper logs and actual provider response-root spans.

In one successful request, the browser received the complete body after 680.57ms. The provider response root took 376.58ms: 213ms from root arrival to middleware entry, 3ms of middleware execution, 23ms from middleware completion to route entry, a 133ms API wrapper, and about 4.58ms from wrapper completion to response-root end. About 303.99ms remains outside that root, including client/transport work.

Resolve Deployment starts 154ms after root arrival and lasts 20.35ms. Resolve Route starts at 175ms and lasts 47.42ms. In a separate 20-request session-traced diagnostic, root-to-middleware ranged 61–249ms and middleware-completion-to-route ranged 20–53ms. I keep traced diagnostics separate from untraced percentile acceptance and do not infer arrival from request-ID timestamps.

What does the provider response-root boundary include before Resolve Deployment? Is there a supported way to distinguish ingress/transit, deployment-protection evaluation and tracing overhead within that interval, while leaving protection enabled? Which additional timing evidence would help separate those stages from client/network work outside the root?

The database lookup bottleneck has already been measured and corrected. I am seeking attribution of the remaining boundary rather than assuming a cold start or changing authorization checks. Background waitUntil children can extend beyond the response root and are kept separate.