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