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

On Wed, Nov 12, 2014 at 9:40 AM, Eli Perelman <eperelman@mozilla.com> wrote:

> I agree with this, and so I believe that any timestamps sent through this
> proposal should probably not be displayed in a timeline. If you want to do
> calculations between any of the existing timings and the "server" timings,
> it should be manual.
>

This breaks one of the primary use cases for this proposal - i.e. to
surface additional request timing data in developer tools. That's a -1 for
me.


> So it appears that Server Timing may be a bit of a misnomer to get at what
> I'm trying to achieve here, which is to get meaningful timestamps generated
> externally from the client to the client. If we were only handling the use
> case of a server communicating information about itself to the client then
> I could understand, but I believe this API could be more powerful and
> extensible if we don't limit it with the server-to-browser standard model.
> I guess what I am getting at is let's make this less about the server, and
> more about external timing which would include the server. External Timing,
> Supplemental Timing, I digress...
>

Just because it's not a remote server doesn't make this any easier. For
example, request gets routed to ServiceWorker, which then goes on to do
some arbitrary amount of work (check cache, update cache, <whatever>), and
then returns a response... Any timestamp that it generates is not directly
relatable to the timeline of the document that initiated the request -- the
only thing we can communicate safely is the duration of one or more events.

I'm still of the mind that we should stay away from timestamps... That
said, if you *really* wanted them, and if we add some form of annotations,
you could communicate your timestamps as annotation and implement your app
logic to process them accordingly.

ig