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

On Mon, Nov 10, 2014 at 1:25 PM, Tobin Titus <tobint@microsoft.com> wrote:

> I’ve been thinking about this since I took on the task of integrating
> server-side information into timing spec per our TPAC discussion.
>
>
>
> One concern is that it has the potential to add significant weight to the
> headers. I’m not necessarily opposed because the actual document is allowed
> to add as much weight as it wants as well. And further, I would expect that
> some of this information might not be sent unless the developer had opened
> up dev tools.
>

Right, I would expect the general case to be very light - you probably
don't want to expose sensitive data (e.g. database time, etc) to every
visitor. However, if some auth / debug cookie is present, you could emit
more detailed data. As long as we keep the data model simple - i.e. flat,
with no nesting, etc - I think we're in good shape.


> However, I would suspect that analytics packages might be picking this
> data up, and then beaconing it back.  It seems strange to send data to the
> client just to send it back to the server again. But again, those are
> choices left up to the developer.
>

Not entirely, since you may not be sending this data to the same server :)


>  While working on the user timing spec this past week, I too was heading
> toward a per-resource header that would better fit in resource timing. So,
> in general, I’m not opposed to writing this into its own spec instead of
> integrating it into user timing.  Just let me know if you’d like me to
> continue working or if you’d like to take this.
>

Yep, let's discuss on the conf call tomorrow.

On Mon, Nov 10, 2014 at 1:51 PM, Aaron Heady (BING AVAILABILITY) <
aheady@microsoft.com> wrote:

>  Concur with: I would prefer if server timing values could be
> alphanumerics, rather than having to encode datacenters as numbers as
> discussed earlier.
>

Yeah, I think we should seriously consider the annotations proposal, I
think it solves this particular problem in a much nicer way.

ig