Add support for server-timing header

[timneutkens]

Feature request

Is your feature request related to a problem? Please describe.

The Server-Timing header allows for showing time traces in the browser devtools for what happened when a page was rendering, this can be useful to show the time it took to run getStaticProps/getStaticPaths for example.

Some references:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server-Timing
https://twitter.com/paul_irish/status/829090506084749312

Describe the solution you'd like

Ideally we'd enable this automatically in development. In production it should probably be under a flag.

Additional context

Reference issue: #7035

[cwohlman]

Has anyone taken this issue yet?

[asci]

that might be quite handy for debugging long TTFB

[roelandmoors]

this can be useful to show the time it took to run getStaticProps/getStaticPaths for example

Do you mean getServerSideProps ? Maybe I understand it wrong but this is just an extra header in the response. Not sure how this could work for getStaticProps?

[timneutkens]

@roelandmoors during development each request triggers getStaticPaths/getStaticProps to be run so it can be measured there and surfaced.

[jasonwilliams]

When I was using React with express, one of the things I was able to do was wrap renderToString in a performance timer then measure how long react was taking to render pages. With Next I’m unable to do this now as that isn’t exposed.

i already use the server-timing headers in my app so as long as next doesn’t conflict with that it should be ok. I wonder if instead they could use the performance API and expose the results some how.

[mohsen1]

So I have implemented this in user space for our Next.js deployment internally. This is totally useful to measure what's slow in prop generating server side functions like getServerSideProps.

What's sad about this is that the headers do not have time stamps and they are just durations. So you don't get a nice waterfall or flamechart of what has happened. I feel this standard needs a few additional features to be perfectly informative. The headers need to also have offset time so we can see the waterfall. There should be a way of telling which span is within another span to build flamecharts.

Example server response headers in our case

server-timing: query.GetViewer;dur=198
server-timing: query.Page_home;dur=88
server-timing: React.render;dur=114
server-timing: Document.getInitialProps;dur=68

P.S. Almost got scammed getting to here!

[jasonwilliams]

@mohsen1 I agree with you it would be nice to have server timing show a waterfall chart (similar to what is seen above in request/response). I guess it would take reaching out to whoever worked on Server Timings API (@igrigorik ?) to see if its possible to add on timestamps to each timing.

I don't know if there's future work to have Server Timing use Entry Types which do use start-time and duration. It seems the effort may have been abandoned but that would have helped map PerformanceEntry directly to a ServerTiming entry.

[steve-marmalade]

I came here looking for this exact feature. As we move more and more of the business logic to the server, having improved server-side telemetry will increasingly help us understand our applications and debug performance issues.

[igorgatis]

It would be even cooler if could easily connect it with something like https://github.com/wallet77/v8-inspector-api#cpu-profiling

[galaxynova1999]

really need this feature

[jodosha]

Any news?

[FranCarstens]

We also have this need. Any word from Vercel on this would be appreciated.

[Svish]

Would be really awesome if this was just a config I could enable in my next.config.js, and get useful Server-Timing of whatever would make sense from Next.js rendering my pages.

Should probably be always on by default in development, and opt-in for production via config in next.config.js.

[viktorbezdek]

We'd love to have this feature too.

[lforst]

This would be incredibly useful for monitoring services to be able to associate SSR requests with frontend timings.

[sadeghmohebbi]

also web.dev google mentioned in this article: https://web.dev/articles/optimize-ttfb#understanding_high_ttfb_with_server-timing

[samcx]

Hi everyone!

Since this is a feature request, I will be moving this over to discussions.

[SilentImp]

Any updates on this feature?

[meetmatt]

++

[lforst]

It's not exactly the same as server-timing support, but I opened a PR that should pretty much cover all the use-cases since you could propagate arbitrary metadata to the client (similar to a header) which is readable through JS: #64256

[HananoshikaYomaru]

so Server-Timing response headers is completely removed from vercel deployment? I tried deploy a boilerplate to vercel but server timing is not working.

[tony13tv]

I have a prototype using AsyncLocalStorage. It allows calling metrics() to obtain a map inside server actions to insert metrics with the correspondent duration and description. Automatically being assigned to the response header 'Server-Timing' during the action phase of the requestStore.

"use server";
import { metrics } from "next/server";
import { db } from "./drizzle"

export async function getUsers(search?: string) {
  const m = metrics(); // <- type here would be Map<string, { dur?: string, desc?: string }> adhering to reference. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Server-Timing#directives
  const time = performance.now();
  const data = await db.query.user.findMany();
  m.set("db(getUsers)", { dur: performance.now() - time, desc: "time spent retrieving all the users"})
  return data;
}

If anyone thinks this is useful let me now to open a PR.

[tony13tv]

You can check the PR out here

[tony13tv]

For anyone looking for a solution can checkout this library. It has been tested with the latest version of next.

[shogunsea]

it's so ridiculous 5 years later the most popular frontend hosting provider still has no support for this standard performance debug header, not even disclosing the reason why vercel didn't plan to add support for this.