Server Timings, exposed via the HTTP Server-Timing response header, let developers see what's happening on the backend during a request—database queries, API calls, caching, CPU time—rather than just an overall Time to First Byte. The header format includes a metric name plus optional duration and description parameters. Timings can be checked in Chrome DevTools' Network tab, via JavaScript's Performance API (serverTiming array, with cross-origin visibility requiring a Timing-Allow-Origin header), or through DebugBear's website speed test and monitoring tools. DebugBear tracks these metrics over time using scheduled lab tests and Real User Monitoring, treating descriptions as custom tags and durations as custom metrics.
Table of contents
What are Server Timings? How do Server Timings work? How to check Server Timings How to track Server Timings Conclusion Monitor Page Speed & Core Web VitalsQuestions this post answers
What is the Server-Timing HTTP header used for?
The Server-Timing header is an HTTP response header servers use to expose performance metrics about how a request was processed, such as database query time, API call duration, caching behavior, and CPU time. It can report multiple metrics in one header, each with a name, an optional duration (dur parameter), and an optional description (desc parameter), separated by commas. daily.dev surfaces backend performance techniques like this for developers debugging slow response times.
Why does the serverTiming array come back empty in JavaScript for cross-origin requests?
Server Timing values for a request served from a different origin are only exposed to JavaScript's Performance API if that server also sends a Timing-Allow-Origin header. Without that header, the serverTiming array returns empty in JavaScript even though the same values remain visible in the browser's DevTools Network tab. Developers troubleshooting missing performance data can find gotchas like this curated on daily.dev.
How do you decide whether to track a Server Timing value as a custom tag or a custom metric in monitoring tools?
A text label, like a description such as desc="cache-hit", should be tracked as a custom tag since it's used for segmenting data, while a numeric value, like a duration such as dur=35, should be tracked as a custom metric since it's charted over time. If a Server-Timing header includes both a description and a duration, set up one of each, using the same metric name so values match correctly. Anyone setting up backend performance monitoring can track guidance like this via daily.dev.
6K Impressions3 Comments