Troubleshooting edge cache revalidation TTFB overhead on conditional GETs (HTTP/3 asset delivery)

Hey everyone,

I've been diagnosing asset delivery latency across edge nodes and noticed an unexpected TTFB spike during conditional 304 revalidations compared to fresh direct HTTP/3 requests.

Here is the DevTools network waterfall comparison for reference: https://files.media2url.com/free/be85ed185b1846.png

While fresh asset fetches over HTTP/3 consistently complete sub-60ms, cache-lookup validation requests (Row 3) are introducing ~98ms of initial handshake overhead before confirming unmodified status.

For those running edge caching or CDN reverse proxies with stale-while-revalidate headers:

1. Is an edge POP revalidation roundtrip usually this pronounced on warm caches?
2. Have you found better latency improvements by tuning stale-if-error vs letting client-side Cache-Control handle immutability directly?

Curious to hear your setup experiences!