Server-Timing: server side metrics in the response
Server-Timing carries named metrics from the server to the browser, where they appear alongside network timings, so slow backend work is visible in the same place as slow transfers.
At a glance
- Direction
- Response only.
- Defined in
- Server Timing (W3C)
- When absent
- The browser sees only total response time, with no breakdown of what the server spent it on.
- Syntax
- name;dur=milliseconds;desc="label", comma separated for several metrics
- Read by
- The performance timeline in the browser, and developer tools
- Cross-origin
- Requires Timing-Allow-Origin before another origin can read the values
- Disclosure
- Metric names and durations describe your internals, so choose them deliberately.
In detail
Real user monitoring is good at telling you a request took two seconds and bad at telling you why. This header closes that gap by letting the server attach its own measurements, so a slow database query and a slow network appear side by side in one timeline rather than in two systems nobody correlates.
Each metric is a name with an optional duration in milliseconds and an optional human readable description. A metric with no duration is still useful as a marker: many sites emit a cache hit or miss indicator this way, which turns a question about edge behaviour into something you can measure from the client rather than infer from headers.
It is visible to anyone who opens developer tools, so the names and values are public. That is an argument for deliberate naming rather than for avoiding the header: emit the handful of phases that matter and skip anything that would reveal internal service names or query shapes you would rather not publish.
For a resource on another origin the values are hidden unless that origin also sends Timing-Allow-Origin, in the same way detailed network timings are. An asset host that wants its customers to measure it needs both headers, or the metrics arrive empty and look like a bug in the monitoring script.
Examples
Server-Timing: db;dur=42.1;desc="query", render;dur=8.7, total;dur=61.4Server-Timing: cache;desc="hit", edge;dur=3.2performance.getEntriesByType('navigation')[0].serverTimingThings that catch people out
- The values are visible to every visitor, so metric names that leak internal service names are a small disclosure you cannot take back.
- Cross-origin resources report empty metrics unless Timing-Allow-Origin is also sent, which looks like the header was never set.
- Timings must be added before the response headers are flushed, so a metric covering work that happens while streaming the body cannot be reported here.
Try it: HTTP Headers Checker
Check a live URL or paste headers you already have. It grades six security headers from A+ to F and lists every other header the response returned.
HTTP Headers Checker
LOCAL · Browser-OnlyView HTTP response headers for any URL
Enter any website URL to fetch and analyze its HTTP response headers. We'll automatically add https:// if needed.
Why Check Security Headers?
Security headers protect your website against common attacks like XSS, clickjacking, and MIME sniffing. They're set by your web server and cost nothing to implement. Missing security headers are one of the most common findings in security audits.
Related HTTP headers
All http headers →Timing-Allow-Origin: exposing detailed resource timings
Why cross-origin resources show zeroed timings, what Timing-Allow-Origin unlocks in the Resource Timing API, and how it differs from a CORS allow header.
Server: what software answered the request
What the Server header conveys, why exposing a version number helps attackers narrow their targets, and what to put there instead of removing it entirely.
Age: how long a cached response has been sitting there
What the Age header counts, how it combines with max-age to give remaining freshness, and how to use it to tell a cache hit from a miss at the edge.
Link: relationships expressed in a header
How the Link header carries relationships that markup cannot, its use for preload with early hints, and the pagination pattern that APIs build on it.
Early-Data: requests sent before the handshake finished
What TLS early data is, why a request sent in it can be replayed, what the Early-Data header signals, and when a server should answer 425 Too Early.
X-Powered-By: a header worth removing
What X-Powered-By discloses, why frameworks add it by default, what removing it actually buys you, and which related headers leak the same information.
Tools for this
- HTTP Headers Checker Free online HTTP headers checker - view HTTP response headers for any URL
- HTTP Request Builder Free online HTTP request builder - build and test HTTP requests with custom headers and body