Server-Timing API

The Server-Timing API lets a server expose backend performance metrics through the HTTP `Server-Timing` response header. Browsers can surface those metrics through `PerformanceServerTiming` entries, allowing frontend code and developer tools to correlate server work with page performance.

A server sends one or more metrics in the `Server-Timing` response header. Each metric can have a name and optionally a duration and description, for example `Server-Timing: db;dur=18, cache;desc="HIT"`. The browser associates these metrics with the relevant resource's performance entry.

Frontend JavaScript can read server-timing information from supported performance entries through `PerformanceServerTiming`, including properties such as `name`, `duration`, and `description`. For resource timing, these entries can be inspected from the browser's Performance Timeline.

This is useful when frontend performance data alone cannot explain latency. A request might take 150 ms overall while the server reports 40 ms for database work and 20 ms for rendering, giving engineers more context about where time was spent.

Server-Timing is primarily an observability mechanism; it does not itself optimize a request or change browser scheduling. Because the values are sent to clients, teams should avoid exposing sensitive implementation details or internal data in metric names and descriptions.

For cross-origin resources, access to performance timing information is governed by the browser's resource-timing and CORS-related policies. Server-Timing therefore works best when the server, response headers, and browser observability rules are considered together.

Key points

• Servers expose metrics with the HTTP `Server-Timing` response header.
• Browser performance entries can expose metrics through `PerformanceServerTiming`.
• Metrics may include a name, duration, and description.
• Server-Timing helps connect client-observed latency with backend work.
• Do not put secrets or sensitive internal information into exposed timing metadata.

Interview questions

What problem does the Server-Timing API solve?

It lets a backend send performance measurements to the browser as part of an HTTP response. The browser can associate those measurements with performance entries for the corresponding resource. This gives frontend engineers visibility into backend operations such as database access or cache activity. It is especially useful when total request latency needs to be explained using server-side information.

How does a server provide a Server-Timing metric?

The server includes a `Server-Timing` HTTP response header. A metric can specify a name and can also include parameters such as `dur` for a duration or `desc` for a description. Multiple metrics can be included in the same header. The browser parses these values and makes them available through supported performance entries.

How would you read Server-Timing data in browser JavaScript?

For a relevant performance entry, JavaScript can inspect its `serverTiming` collection. Each `PerformanceServerTiming` object exposes information such as its `name`, `duration`, and `description`. For resource requests, this can be combined with Resource Timing data to identify which request produced the server metrics. The exact entries available depend on the browser's performance-timing policies and the resource involved.

How is Server-Timing different from the User Timing API?

User Timing is generated by JavaScript running in the browser, using concepts such as marks and measures. Server-Timing instead transports server-generated performance information through an HTTP response header. They can complement each other: client-side measurements describe browser work while server timing describes backend work. Together they can help decompose end-to-end latency.

What security or privacy considerations matter when using Server-Timing?

Server-Timing values are sent to clients, so they should be treated as externally observable metadata. Metric names or descriptions should not reveal secrets, credentials, sensitive identifiers, or unnecessary internal architecture details. Cross-origin exposure also needs to follow the browser's applicable resource-timing and CORS rules. Teams should deliberately choose which diagnostic information is safe to expose in production.