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

Akamai would definitely be interested in this as well.  Like LinkedIn, we
use a sufficient, but less-than-ideal solution to communicate this data to
our RUM system.

A few years back I'd proposed something toughly similar, and browser
vendors seemed hesitant to go down the path of dealing with new, special
headers.  Curious to know if that sentiment has changed.

Mike

On 11/7/14, 9:41 PM, "Ritesh Maheshwari" <riteshm@gmail.com> wrote:

>+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-ru
>m-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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Received on Monday, 10 November 2014 15:37:25 UTC