We (Bing) also do data center and server time via the client through a couple of different methods. Adds all of the relevant timestamps to the single callback with navigation timing info. Reduces the need to merge logs, improves real-time issue diagnosis, etc.
I’m sure having it as a standardized method would be nice, but I also know that we routinely change what information needs to be passed around as needs shift, new problems arise, etc. I’m trying to understand how having this as a standard would improve the situation over how we currently do things. To compare it with Nav Timing, in the old way the timers got in the way, there were events only the browser was aware of, not the page, etc. So Nav had to be built into the browser to work. This (server timing) doesn’t, as best I can tell. What’s the case that this solves that requires it to be built in? Aaron From: Ilya Grigorik [mailto:[email protected]] Sent: Monday, November 10, 2014 10:18 AM To: Ben Maurer Cc: public-web-perf Subject: Re: communicating server timing data to the client.. Server Timing? Hmm, so the data center use case is fairly common. Interesting. It's not clear to me what the best route is to tackle non-timing data... currently, all of our specs are surfacing timing events. A couple of routes: 1) Record non-timing data as timing events - e.g. pop=22 would be surfaced as a timing event with duration of 22ms... but, in reality, you'd be communicating that you used pop #22, which is something your application could know an process accordingly. Pro: simple, no spec or UA changes required. Con: we're polluting the timeline, which would become a problem once UA's start surfacing these events in their devtools, etc. 2) We extend timing events with some form of annotations [1]. Assuming that exists, you could annotate existing timing event(s) with relevant meta-data - e.g. cache=23;nyc --> { name: 'cache', duration: 23.0, meta: 'nyc' }, where 'nyc' is an arbitrary string that could, for example, be used to indicate the data center. If we go down the route of adding annotations, it seems like it's something that should be available on all timing events. That said, I'd love to hear more use cases for it. Thoughts / comments? [1] https://github.com/w3c/performance-timeline/issues/2 On Mon, Nov 10, 2014 at 8:05 AM, Ben Maurer <[email protected]<mailto:[email protected]>> wrote: How would this handle pages that are rendered incrementally where full timing data isn't available with headers? You'd have to use trailer headers - stream the page, then emit the Server-Timing header at the end. ig
