Server-TimingServer-Timing carries server-measured performance metrics (per-stage durations, etc.) in the response, exposing them to browser dev tools and client scripts. It lets you see server-side latency alongside front-end performance data in one place.
Each metric is `name;dur=ms;desc="text"`, comma-listed for several (e.g. `Server-Timing: db;dur=53.2;desc="Database query", cache;dur=1.5`).
Traditionally server processing time lived only in logs and APM, invisible to the front end. Server-Timing puts these values into the response in a standardized form, so the browser DevTools Network tab's Timing section shows 'server processing breakdown.' You can inspect per-stage times like DB query, cache lookup, and template render for a single request.
It is powerful combined with Real User Monitoring (RUM). The client's `PerformanceObserver`/`PerformanceServerTiming` API reads these values in JavaScript, so you can collect and aggregate server latency from real user environments — tracking backend bottlenecks on genuine traffic rather than synthetic monitoring.
Mind the cross-origin restriction: to read a cross-origin resource's Server-Timing from script, that response must permit access via a `Timing-Allow-Origin` header. Also, putting internal structure (table names, service names, paths) in desc/name can leak information, so in externally exposed environments anonymize the metrics or trim them in production.
Server-Timing: <name>[;dur=<ms>][;desc="<text>"][, ...]e.g. Server-Timing: db;dur=53.2;desc="Database query", cache;dur=1.5
<name> | An identifier for the metric (e.g. db, cache, app), shown by this name in dev tools and RUM. |
dur=<ms> | The duration of the operation in milliseconds, expressing per-stage server latency. |
desc=<text> | A human-readable description of the metric (quote if it contains spaces). |