RE: communicating server timing data to the client.. Server Timing?

Concur with: I would prefer if server timing values could be alphanumerics, rather than having to encode datacenters as numbers as discussed earlier.

On the points that Ilya brought up, all very reasonable examples. Thanks.

Aaron


From: Edmund Huber [mailto:edmund.pgh@gmail.com]
Sent: Monday, November 10, 2014 1:34 PM
To: Ilya Grigorik
Cc: Aaron Heady (BING AVAILABILITY); Ben Maurer; public-web-perf
Subject: Re: communicating server timing data to the client.. Server Timing?

I would prefer if server timing values could be alphanumerics, rather than having to encode datacenters as numbers as discussed earlier.

This header might be more useful if these values were available for every resource on a page (subject to Timing-Allow-Origin).

And, suppose this scenario: a page is loaded from cache. Should Javascript beacon back the server timing values? It seems like the server receiving the beacons would also like to know if the page was from cache or not, which as far as I know there are only heuristics to ascertain.

On Mon, Nov 10, 2014 at 12:15 PM, Ilya Grigorik <igrigorik@google.com<mailto:igrigorik@google.com>> wrote:

On Mon, Nov 10, 2014 at 10:44 AM, Aaron Heady (BING AVAILABILITY) <aheady@microsoft.com<mailto:aheady@microsoft.com>> 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