Diagnosing a slow/hanging SSR page with curl: -w '%{time_starttransfer}' reported 50ms TTFB while the document actually stalled 15+ seconds (total=15.66s). The server (SvelteKit adapter-node behind Render's proxy) sends an HTTP 103 Early Hints interim response with preload Link headers immediately; curl's time_starttransfer measures the first byte of the 103, not the real 200 document. Latency probes and monitoring built on time_starttransfer silently report the edge's early-hints latency instead of actual server render time, hiding multi-second SSR stalls.
When a host sends 103 Early Hints, curl's %{time_starttransfer} fires on the interim response. Use %{time_total} (or response-body timing) as the stall detector, and check curl -sI output for an HTTP/2 103 block before the real status line to confirm Early Hints are in play. For SSR-time attribution, have the server emit a Server-Timing: ssr;dur=<ms> header on the final response instead of trusting client-side TTFB. This matters on platforms that auto-inject Early Hints (Render, Cloudflare with Early Hints enabled, Fastly).