Investigate Server-Timing for passing back response headers

[AloisReitbauer]

Started a thread with the web performance working group [1]. It would be great if we can start a trace context already in the browser. This would massively reduce the effort for implementing real user monitoring in browsers.

[1] w3c/web-performance#22

[jorgheymans]

+1000 Op za 24 feb. 2018 11:33 schreef Alois Reitbauer <[email protected]>:

…

Started a thread with the web performance working group [1]. It would be great if we can start a trace context already in the browser. This would massively reduce the effort for implementing real user monitoring in browsers. [1] w3c/web-performance#22 <w3c/web-performance#22> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#69>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAL1AMfj0y8LDhqILQOHFjyHwUA_SVwNks5tX-V5gaJpZM4SR2CD> .

[wu-sheng]

+1 This will be helpful for the monitoring system knowing the request from browser.

[jkowall]

I agree completely, there is also a new spec I've seen some early POCs of "server timing": https://www.w3.org/TR/server-timing/ It would be great to take this one step further with adding the context. Good thinking Alois.

On Sat, Feb 24, 2018 at 8:16 AM 吴晟 Wu Sheng ***@***.***> wrote: +1 This will be helpful for the monitoring system knowing the request from browser. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#69 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABxhbCoDyAW07QqO_YGRWNVsbYiPGpyxks5tYAuQgaJpZM4SR2CD> .

-- -Jonah Kowall twitter : @jkowall Ph : +1-617-500-3575

[yoavweiss]

Hey tracing folks!

I'm interested to hear your thoughts about how Server Timing can be used to help with your efforts.

The main thing that comes to mind is that Server timing can be used to share a "transaction ID" that will be collected and traced along the different components of the application delivery as well as the browser and can enable keeping track of a request's lifecycle through the different components all the way to the browser.

The main advantage of ST in that context is the "all the way to the browser" part. I guess that any other header could be used to communicate an ID between the different components, but ST is required if you want to correlate those measurements with ResourceTiming data.

Do you agree with the above? Are there other use-cases that you folks had in mind?

We're starting to plan the WebPerfWG meeting sessions at TPAC and would be happy to reserve some time to discuss collaboration. Let me know if you're interested.

/cc @cvazac @igrigorik

[AloisReitbauer]

Passing a TraceParent header from the browser all the way down to backend systems would add massive value for end-to-end tracing. The team will be at TPAC and what I have heard we are meeting the same days as you guys. We should set aside an hour or two to discuss how to work together.

As we also have working implementations we can also show you a real-world use case.

[yoavweiss]

Sounds good. Let's coordinate meeting times.

[dcreager]

This would be great for Network Error Logging, too! NEL reports would provide information about the end-to-end reliability of the original request; if we could add a browser-assigned trace ID to those reports, then you could easily join those reports with all of the detailed information coming out of your tracing system.

[plehegar]

(unassigned myself on this one since it seems to be moving along without my help so far)

[cvazac]

Should we schedule a F2F at TPAC?
cc @AloisReitbauer @yoavweiss

[yoavweiss]

Submitted a breakout session: https://www.w3.org/wiki/TPAC/2018/SessionIdeas#Server_Timing.2C_Network_Error_Logging_and_Distributed_Tracing

[yoavweiss]

Discussed during TPAC. Minutes

[danielkhan]

Decided that we want to use our own header

[jpkrohling]

I realize this is almost four years old, but what was the reason for using a different header? I understand that Server-Timing is the perfect header for traceresponse, given that traceresponse is indeed related to the timings spent on the server and is already part of safe-lists everywhere. Looking at the minutes, I could guess that the reason is related to this comment:

Yoav: This should be opt in, with the bare minimum number of resources that you need.

If that's the concern, isn't the server side already opting in by adding the response metric to this header? Like:

Server-Timing: traceresponse;desc=00-{trace-id}-{child-id}-01