W3C home > Mailing lists > Public > public-web-perf@w3.org > November 2014

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

From: Ilya Grigorik <igrigorik@google.com>
Date: Wed, 12 Nov 2014 09:15:22 -0800
Message-ID: <CADXXVKpdJfCDTBzzz9MEFoRLVftmHHgh+C+gK2BK7CfSYMrKXw@mail.gmail.com>
To: Eli Perelman <eperelman@mozilla.com>
Cc: "Aaron Heady (BING AVAILABILITY)" <aheady@microsoft.com>, Edmund Huber <edmund.pgh@gmail.com>, Ben Maurer <ben.maurer@gmail.com>, public-web-perf <public-web-perf@w3.org>
On Wed, Nov 12, 2014 at 7:10 AM, Eli Perelman <eperelman@mozilla.com> wrote:

> I really like this proposal, but I do find keeping the values as durations
> to be somewhat limiting. Just as we have performance marks and measures, I
> feel that being able to provide both durations and timestamps to the client
> would be useful.
> A specific use case: On Firefox OS, it would be valuable to specify in
> this header when the user initiated to open an application. The "home
> screen" (acting as the server in this proposal) could specify in the header
> that at a certain timestamp, the user tapped on an icon, and the
> application (acting as the client) would then be able to make a more
> deterministic evaluation for how long it actually took load. Drawback: not
> sure of the implications of introducing timestamps or possible negative
> values into the timeline of an application, but that is something we could
> discuss.
> Thoughts?

The problem is that server and client have completely different clocks..
- they're not synchronized, nor can we expect or make them be synchronized
- 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.

Received on Wednesday, 12 November 2014 17:16:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:26 UTC