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

+1 on both ideas (server timing and extra information).

At LinkedIn, right now we use a hack
<http://engineering.linkedin.com/performance/how-linkedin-used-pops-and-rum-make-dynamic-content-download-25-faster>
to know the data center, so cleaner solutions are always useful.

On Fri, Nov 7, 2014 at 3:23 PM, Ilya Grigorik <igrigorik@google.com> wrote:

>
>
> 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
>>
>>
>