Server-Timing Header
Server-Timing is an HTTP response header that communicates backend performance metrics to clients, such as cache lookup time, database duration, or upstream API latency. Browser DevTools display these values, making it easy to see where server-side time is spent.
Technical Architecture & Deep-Dive
When an aggregated endpoint is slow, developers need to know which upstream call caused it. Server-Timing lets the gateway annotate responses with per-step durations, like `stripe;dur=120, cache;desc="HIT"`.
Because the header is visible in DevTools, frontend developers can diagnose performance without access to backend logs. Sensitive internal details should be omitted or restricted in production.
Key Architectural Benefits
Per-Step Timing Annotation
Server-Timing: cache;desc="MISS", stripe;dur=118.4, supabase;dur=42.7, total;dur=124.9Implement Server-Timing Header at the Edge
Deploy lightweight API aggregation, edge caching, and secret injection in minutes without Docker containers or complex servers.
Frequently Asked Questions
Q:Can Server-Timing leak sensitive information?
It can reveal internal architecture. Use generic metric names in production or only emit the header for authenticated debugging requests.
Related Architecture Concepts
P99 latency is the response time below which 99 percent of requests complete, so only the slowest 1 percent take longer. Percentile metrics like p50, p95, and p99 reveal tail latency, the slow outliers that averages hide but users still experience.
Time to First Byte (TTFB) measures the time between a client sending an HTTP request and receiving the first byte of the response. It includes DNS lookup, connection setup, TLS negotiation, network travel, and server processing time, making it a core indicator of backend and network responsiveness.
Upstream Fan-out is an execution strategy where an edge gateway dispatches multiple HTTP subrequests to separate origin services concurrently rather than sequentially. The total latency is bound by the single slowest subrequest (max time) rather than the cumulative sum of all subrequests.