Server-Timing is a part of the Performance API and allows servers to communicate metrics about the request-response cycle to the user agent. You can collect this information and act on server-side metrics in the same way as all the other metrics processed with the Performance API.

Sending server metrics

TheServer-Timing HTTP header is used to surface any backend server timing metrics. For example, you might want to send database read/write operation times, CPU time, and file system access.

You can send metrics with or without values. The metrics can optionally contain a description. It is advised to keep names, descriptions, and data as short as possible to minimize the HTTP overhead.

Examples ofServer-Timing headers:

// Single metric without valueServer-Timing: missedCache// Single metric with valueServer-Timing: cpu;dur=2.4// Single metric with description and valueServer-Timing: cache;desc="Cache Read";dur=23.2// Two metrics with valuesServer-Timing: db;dur=53, app;dur=47.2// Server-Timing as trailerTrailer: Server-Timing--- response body ---Server-Timing: total;dur=123.4

To calculate real server-side metrics, consult the documentation of your server-side CMS, framework, or programming language for how to measure performance within the backend application. If your server uses Node.js, the performance measurement APIs will look very familiar to the Performance API in browsers. This is because the Node.js performance module is a subset of the W3C Web Performance APIs as well as additional APIs for Node.js-specific performance measurements. See theNode.js performance documentation for more information.

Note that there is no clock synchronization between the server, the client, and any intermediate proxies. This means that if your server sends timestamps or astartTime, the value might not meaningfully map to thestartTime of the client's timeline.

Once you have calculated your desired metrics, the server needs to send theServer-Timing header in its response. See theServer-Timing reference page for an example of how to send the header in Node.js.

Retrieving server metrics

The server timing metrics usually appear in the developer tools of the browser, but they are also stored asPerformanceServerTiming performance entries that you can access like otherperformance data. However, there are no"server-timing" entries on their own. ThePerformanceServerTiming objects are observable from"navigation" and"resource" performance entries. You access the server metrics from thePerformanceResourceTiming.serverTiming property, which is an array ofPerformanceServerTiming objects.

Given aServer-Timing like this:

Server-Timing: cache;desc="Cache Read";dur=23.2,db;dur=53,app;dur=47.2

APerformanceObserver can log the entries on the client side with the following code:

const observer = new PerformanceObserver((list) => {  list.getEntries().forEach((entry) => {    entry.serverTiming.forEach((serverEntry) => {      console.log(        `${serverEntry.name} (${serverEntry.description}) duration: ${serverEntry.duration}`,      );      // Logs "cache (Cache Read) duration: 23.2"      // Logs "db () duration: 53"      // Logs "app () duration: 47.2"    });  });});["navigation", "resource"].forEach((type) =>  observer.observe({ type, buffered: true }),);

Privacy and security considerations

TheServer-Timing header may expose potentially sensitive application and infrastructure information. Therefore, you need to control when the metrics are returned and to whom on the server side. For example, you could show metrics only to authenticated users and nothing to the public.

ThePerformanceServerTiming interface is restricted to the same origin, but you can use theTiming-Allow-Origin header to specify the domains that are allowed to access the server metrics. Also, note that this interface is only available in secure contexts (HTTPS) in some browsers.