--- title: Server Timing: Measure And Track Backend Performance description: 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... canonical: https://daily.dev/posts/server-timing-measure-and-track-backend-performance-m1j2axzux twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Server Timing: Measure And Track Backend Performance | daily.dev og:description: 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... og:url: https://daily.dev/posts/server-timing-measure-and-track-backend-performance-m1j2axzux og:image: https://api.daily.dev/og/posts/M1j2AXzUx.png og:image:alt: Server Timing: Measure And Track Backend Performance og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Server Timing: Measure And Track Backend Performance **[DebugBear](https://daily.dev/sources/debugbear)** · 5 min read · 6 upvotes · 3 comments ## Summary 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. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How do I read Server-Timing header values using JavaScript? Server-Timing values are exposed through the Performance API, where each performance entry includes a serverTiming array containing the metrics reported for that request. You can inspect this array for the page's own HTML document entry or for any other resource entry. Note that timings for a different-origin request only appear in this array if that server also sends a Timing-Allow-Origin header; otherwise the array is empty even though the values still show in DevTools. _daily.dev surfaces practical guides like this for developers instrumenting backend performance monitoring._ ### What are the three parts of a Server-Timing header value? A Server-Timing entry is made up of a name, an optional duration, and an optional description, with only the name required. The duration uses a dur parameter (for example dur=35 for 35 milliseconds) and the description uses a desc parameter (for example desc="response"), separated from the name by semicolons. Multiple metrics can be sent in one header separated by commas. _Developers debugging backend latency can find header-format references like this through daily.dev._ ### Should a Server-Timing description be tracked as a custom tag or a custom metric? A description value, such as desc="cache-hit", should be tracked as a custom tag since it is a label used for segmenting data, while a duration value, such as dur=35, should be tracked as a custom metric since it is a number meant to be 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. _Teams setting up backend performance monitoring rely on daily.dev to find this kind of hands-on configuration detail._ ## Community discussion Top comments from developers on daily.dev. **@agustinbarrientos** · 2 upvotes > Good use of Server-Timing turns a vague TTFB regression into something actionable. The cross-origin caveat matters though. Without Timing-Allow-Origin, RUM silently loses the breakdown even while DevTools still shows it. **@pdfopsdev** · 2 upvotes > the Timing-Allow-Origin trap gets people every time. works fine in devtools, then someone wonders why their RUM script reports zero server timing entries in prod because the request is cross-origin. easy to forget when your CDN and origin live on different subdomains. **@allinonetools** · 2 upvotes > This is one of those small performance details that’s easy to overlook. Being able to see where backend time is actually going makes debugging much easier. ## Similar posts on daily.dev - [Server-Timing response headers will pass through to the client](https://daily.dev/posts/server-timing-response-headers-will-pass-through-to-the-client-jbqr98qhj) · Vercel · 0 upvotes · 0 comments - [TTFB doesn't mean what you think it means](https://daily.dev/posts/ttfb-doesn-t-mean-what-you-think-it-means-ezukhof9j) · Web Performance Calendar · 0 upvotes · 0 comments - [How an HTTP header caused time.gov to skew from UTC](https://daily.dev/posts/how-an-http-header-caused-time-gov-to-skew-from-utc-bx8wwerln) · Lobsters · 3 upvotes · 1 comments - [A Guide to Browser DevTools – The Network Monitor](https://daily.dev/posts/a-guide-to-browser-devtools-the-network-monitor-spzq4aamm) · Atomic Spin · 0 upvotes · 0 comments - [The Blind Spot Between Back‐End Metrics and User Experience](https://daily.dev/posts/the-blind-spot-between-back-end-metrics-and-user-experience-h907tu8hy) · DevOps.com · 0 upvotes · 0 comments --- Tags: [#webdev](https://daily.dev/tags/webdev), [#google-chrome](https://daily.dev/tags/google-chrome) [View this post on daily.dev](https://daily.dev/posts/server-timing-measure-and-track-backend-performance-m1j2axzux) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Server Timing: Measure And Track Backend Performance","url":"https://daily.dev/posts/server-timing-measure-and-track-backend-performance-m1j2axzux","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/server-timing-measure-and-track-backend-performance-m1j2axzux"},"datePublished":"2026-08-20T11:53:43.580Z","dateModified":"2026-09-14T06:42:25.395Z","description":"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...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/e1f7be88963f9c4d42b49672dceb7a49?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/e1f7be88963f9c4d42b49672dceb7a49?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"DebugBear","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"DebugBear","logo":"https://media.daily.dev/image/upload/s--LFz7F9sP--/f_auto,q_auto/v1780213580/logos/debugbear?_a=BAMAMiWQ0","url":"https://daily.dev/sources/debugbear"},"commentCount":3,"discussionUrl":"https://daily.dev/posts/server-timing-measure-and-track-backend-performance-m1j2axzux","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":6},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":3}],"keywords":"webdev,google-chrome","timeRequired":"PT5M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"DebugBear","item":"https://daily.dev/sources/debugbear"},{"@type":"ListItem","position":3,"name":"Server Timing: Measure And Track Backend Performance"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/server-timing-measure-and-track-backend-performance-m1j2axzux","comment":[{"@type":"Comment","text":"Good use of Server-Timing turns a vague TTFB regression into something actionable. The cross-origin caveat matters though. Without Timing-Allow-Origin, RUM silently loses the breakdown even while DevTools still shows it.","datePublished":"2026-08-21T19:36:58.729Z","url":"https://daily.dev/posts/M1j2AXzUx#c-oYjAblaP3","author":{"@type":"Person","name":"Agustin Barrientos","url":"https://daily.dev/agustinbarrientos","image":"https://media.daily.dev/image/upload/s--5ayxQnqn--/f_auto/v1788281802/avatars/avatar_wQYYVe5Tbj0NJ7C7qPoa8?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"the Timing-Allow-Origin trap gets people every time. works fine in devtools, then someone wonders why their RUM script reports zero server timing entries in prod because the request is cross-origin. easy to forget when your CDN and origin live on different subdomains.","datePublished":"2026-08-22T18:05:39.034Z","url":"https://daily.dev/posts/M1j2AXzUx#c-ulDHMkbXI","author":{"@type":"Person","name":"PDFops","url":"https://daily.dev/pdfopsdev","image":"https://media.daily.dev/image/upload/s---8isRBKc--/f_auto/v1782922291/avatars/avatar_orjMeK8QKaaVZwGq7ScPz?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"This is one of those small performance details that’s easy to overlook. Being able to see where backend time is actually going makes debugging much easier.","datePublished":"2026-08-24T03:03:09.002Z","url":"https://daily.dev/posts/M1j2AXzUx#c-28az3xNQU","author":{"@type":"Person","name":"AllInOneTools","url":"https://daily.dev/allinonetools","image":"https://media.daily.dev/image/upload/s--4ZT8QlF0--/f_auto/v1769790028/avatars/avatar_igzBsWloJeaegzm9bQltZ?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/server-timing-measure-and-track-backend-performance-m1j2axzux#faq","mainEntity":[{"@type":"Question","name":"How do I read Server-Timing header values using JavaScript?","acceptedAnswer":{"@type":"Answer","text":"Server-Timing values are exposed through the Performance API, where each performance entry includes a serverTiming array containing the metrics reported for that request. You can inspect this array for the page's own HTML document entry or for any other resource entry. Note that timings for a different-origin request only appear in this array if that server also sends a Timing-Allow-Origin header; otherwise the array is empty even though the values still show in DevTools. daily.dev surfaces practical guides like this for developers instrumenting backend performance monitoring."}},{"@type":"Question","name":"What are the three parts of a Server-Timing header value?","acceptedAnswer":{"@type":"Answer","text":"A Server-Timing entry is made up of a name, an optional duration, and an optional description, with only the name required. The duration uses a dur parameter (for example dur=35 for 35 milliseconds) and the description uses a desc parameter (for example desc=\"response\"), separated from the name by semicolons. Multiple metrics can be sent in one header separated by commas. Developers debugging backend latency can find header-format references like this through daily.dev."}},{"@type":"Question","name":"Should a Server-Timing description be tracked as a custom tag or a custom metric?","acceptedAnswer":{"@type":"Answer","text":"A description value, such as desc=\"cache-hit\", should be tracked as a custom tag since it is a label used for segmenting data, while a duration value, such as dur=35, should be tracked as a custom metric since it is a number meant to be 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. Teams setting up backend performance monitoring rely on daily.dev to find this kind of hands-on configuration detail."}}]} ```