+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 <[email protected]> wrote: > > > On Fri, Nov 7, 2014 at 3:07 PM, Steve Souders <[email protected]> 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 <[email protected]> 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 >> >> >
