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

On Fri, Nov 7, 2014 at 3:07 PM, Steve Souders <steve@souders.org> wrote:

> Fastly is interested in this. We would use it to convey backend times (eg,
> time to origin, time from cache, etc) to the client. On the client we or
> our customers would then combine these backend times with Nav and Resource
> times into a single beacon.
>

Nice.


> I can see the desire to convey other info that is not timing like which
> data center was used, whether it was a cache hit, etc. So having a way to
> pass on non-timing params would be helpful. (Is this addressed in User
> Timing? Seems like there would be a similar need.)
>

<probably a terrible idea>
You could encode this data in same key-value pairs.. e.g. c=1, dc=23 -->
cache hit = 1 (true); datacenter = 23, where 23 is something meaningful to
you. The server controls the names and values, what data it emits, and to
whom... so it's a fairly flexible scheme.

ig

>
> On Nov 7, 2014, at 2:00 PM, Ilya Grigorik <igrigorik@google.com> wrote:
>
> https://gist.github.com/igrigorik/97dfe5ea9b4a85162e25
>
> We had a brief discussion around this at TPAC, but in the context of
> extending User Timing. However, having thought about it some more, I'm
> thinking this could/should be an extension for Nav and Resource Timing
> interfaces... perhaps even a standalone spec?
>
> That said, I'm getting ahead of myself... Curious to hear everyone's
> thoughts? Is it worth pursuing further? Am I overlooking any major problems
> or gotchas?
>
> ig
>
>