Server Timing

Privacy and security

The Server-Timing header can reveal sensitive information about the application and infrastructure. It is important to choose carefully which metrics to send, when to send them, and who has access, depending on your use case. For example, you might decide to restrict metrics visibility to authenticated users only, with no data exposed on public responses.

PerformanceServerTiming interface

The Server-Timing header metrics appear in browser developer tools, and the PerformanceServerTiming interface allows tools to automatically gather and analyze these metrics via JavaScript. This interface is limited to the same origin, but you can specify permitted domains using the Timing-Allow-Origin header. Note that this interface is only available in secure contexts (HTTPS) in some browsers.

The Server-Timing header components correspond to the PerformanceServerTiming properties as follows:

• “name” maps to PerformanceServerTiming.name
• “dur” maps to PerformanceServerTiming.duration
• “desc” maps to PerformanceServerTiming.description

Sending a metric using the Server-Timing header

The example below demonstrates a response that includes a custom metric custom-metric with a duration of 123.45 milliseconds and a description:

Server-Timing: custom-metric;dur=123.45;desc="My custom metric"

Server-Timing as HTTP trailer

In this example, the Trailer header indicates that a Server-Timing header will follow the response body. A metric custom-metric with a duration of 123.4 milliseconds is included:

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Trailer: Server-Timing

--- response body ---
Server-Timing: custom-metric;dur=123.4

Note:
Only browsers’ DevTools can display Server-Timing headers as HTTP trailers in the Network → Timings tab. The Fetch API cannot access HTTP trailers. For more details, see browser compatibility.