Today I saw a LinkedIn post from Matt Zeunert stating that DebugBear had “improved support for server timing header”.
Knowing Matt, I knew this was a good thing.
But having no idea what Server-Timing Headers were, I wasn’t sure how good…
Turns out, pretty freaking good!
The HTTP
Server-Timingresponse header communicates one or more performance metrics about the request-response cycle to the user agent. It is used to surface backend server timing metrics (for example, database read/write, CPU time, file system access, etc.) in the developer tools in the user’s browser or in thePerformanceServerTiminginterface.
— https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Server-Timing
The PerformanceServerTiming API has three properties, that map as follows:
- “name” ->
PerformanceServerTiming.name - “dur” ->
PerformanceServerTiming.duration - “desc” ->
PerformanceServerTiming.description
Note that only the name property is required.
An example for a custom metric called “db-query” might be:
Server-Timing: db-query; dur=86ms; desc="Duration of the database query"
Note that the properties are separated by a ; (spaces not required, added for readability).
You can also send multiple timings in a single header; appending another custom metric called “from-cache”, which does not need a dur or desc:
Server-Timing: db-query; dur=86ms; desc="Duration of the database query", from-cache
Note that each timing is separated by a , (spaces not required, added for readability).
This seems like a great way to help share backend metrics with your RUM or Synthetic monitoring!
Thanks for the share, Matt!
Happy timing,
Atg