Understanding Server Timing: Measuring Server‑Side Performance Directly from the Browser

Server Timing provides a way for browsers to report how long each step of the server’s response took, allowing front‑end developers to pinpoint back‑end bottlenecks without manual server logs.

The author, a front‑end engineer from 360 Qihoo and W3C Performance Working Group member, introduces the concept, noting that typical performance investigations start with rendering checks and network timing, but often require back‑end cooperation.

What Server Timing Looks Like

The server includes a Server-Timing header in the HTTP response, for example:

GET /resource HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Server-Timing: db;dur=53

In this header, db is the metric name and dur=53 indicates the server spent 53 ms on the database query.

Header Structure

A Server‑Timing header consists of one or more server‑timing‑metric entries, each formed as metric-name[; param=value] . The metric name identifies the operation (e.g., db ), while parameters such as dur convey numeric values.

Example breakdown:

server‑timing‑metric = db;dur=53

metric‑name = db

server‑timing‑param = dur=53

server‑timing‑param‑name = dur

server‑timing‑param‑value = 53

Thus the header tells us the database query took 53 ms.

Browser Processing

The W3C Performance Working Group defines the PerformanceServerTiming interface. For each Server‑Timing entry, a PerformanceServerTiming object is created, its name set to the metric name, and its duration or description properties populated based on the parameter name ( dur or desc ).

These objects are added to the entryList of a PerformanceEntry (e.g., from Resource Timing or Navigation Timing).

How Front‑End Engineers Can Use It

// Set a duration threshold (ms)
const limit = 200;
["navigation", "resource"].forEach(type => {
  performance.getEntriesByType(type).forEach(({ name: url, serverTiming }) => {
    serverTiming.forEach(({ name, duration, description }) => {
      if (duration < limit) return;
      console.log("find slow server-timing");
      console.log(JSON.stringify({ url, entryType: type, name, duration, description }, null, 2));
    });
  });
});

This script filters navigation and resource entries, iterates over their serverTiming data, and logs any metric whose duration exceeds the defined limit.

Privacy and Security

Because PerformanceServerTiming can expose internal server behavior, it is subject to same‑origin restrictions. Servers may relax this via the Timing-Allow-Origin response header, or selectively expose metrics.

Browser Support

As of September 2018, only Chrome 65+ and Firefox 61+ implement Server Timing, making it a relatively new “black‑tech” feature.

Conclusion

Server Timing equips front‑end developers with direct insight into server‑side performance, but it requires server cooperation to emit the appropriate headers; without that, the performance.getEntriesByType(...).serverTiming array will be empty. Collaboration between front‑end and back‑end teams is essential for effective performance optimization.