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

On Wed, Nov 12, 2014 at 11:15 AM, Ilya Grigorik <igrigorik@google.com>
wrote:

>
> The problem is that server and client have completely different clocks..
>

Agreed that this is typically the scenario, but who is to say that the
actions of one page load do not have important timestamps for a subsequent
page load? This can be true even on a single client loading a particular
page. Example:

User loads web site page A, sends timestamp to server for some action,
makes request for page B, server sends timestamp in header which can be
accessible from proposed API.


> - they're not synchronized, nor can we expect or make them be synchronized
>

If we are only speaking about server-generated timestamps, I would agree
with you, but there are a couple scenarios in which web technologies are
used outside of the standard client-server model. It may be the case that
we should not display the "server" marks by default in a devtools timeline,
but still have the data available through the API. Just because the data is
coming from the "server" does not mean that the methods used to collect the
timestamp were not done in a synchronized manner as is the case when client
and server are on the same device.


> - client uses hr-time and its timestamps are with respect to
> navigationStart
>
We can't meaningfully map server generated timestamps into the timeline, I
> think we should stick to duration only.
>
> ig
>

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.

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

Does any of this make sense? :)