I’ve been thinking about this since I took on the task of integrating server-side information into timing spec per our TPAC discussion.
One concern is that it has the potential to add significant weight to the headers. I’m not necessarily opposed because the actual document is allowed to add as much weight as it wants as well. And further, I would expect that some of this information might not be sent unless the developer had opened up dev tools. However, I would suspect that analytics packages might be picking this data up, and then beaconing it back. It seems strange to send data to the client just to send it back to the server again. But again, those are choices left up to the developer. While working on the user timing spec this past week, I too was heading toward a per-resource header that would better fit in resource timing. So, in general, I’m not opposed to writing this into its own spec instead of integrating it into user timing. Just let me know if you’d like me to continue working or if you’d like to take this. Regardless, I think we should be clear on the scenarios that we see this being used in (developer tools, analytics packages) and really nail the implementation based on those scenarios otherwise we have a potential for scope problems. tt From: Ilya Grigorik [mailto:[email protected]] Sent: Monday, November 10, 2014 12:16 PM To: Aaron Heady (BING AVAILABILITY) Cc: Ben Maurer; public-web-perf Subject: Re: communicating server timing data to the client.. Server Timing? On Mon, Nov 10, 2014 at 10:44 AM, Aaron Heady (BING AVAILABILITY) <[email protected]<mailto:[email protected]>> wrote: What’s the case that this solves that requires it to be built in? You're right, if you control the server and client code, you could instrument most of this already.. However: a) every implementation is custom; UA can't surface this data in developer tools - e.g. I'd like to see server marks and annotations in my network waterfall and/or other timelines. Instead, developers have to build custom toolbar overlays for their pages, etc. b) analytics / monitoring vendors can't automatically gather this data without custom hooks - e.g. Google Analytics has a mechanism for reporting user timing metrics, but the developer must provide manual plumbing to extract metrics they care about and beacon them to the server.. as a result, it's an infrequently used mechanism. c) CDNs / proxies would have a standard mechanism to inject timing and other meta-data. d) this may be a good way to address ServiceWorker use cases (extension of c) where SW could annotate fetches with additional data, like local cache lookup times, time to fetch from remote destination, etc. In short, the main value here is standardizing the HTTP header + browser interface, which would enable interop for a variety of existing tools and use cases. ig
