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

In WebPagetest I'll probably expose the times when you drill-down into a
waterfall request.  Probably as both a list of the raw times and a pie
chart or something like that.  I'll also expose them through the API so CI
tools can look at the timings as part of their performance testing.

A straight-up list is probably going to be the easiest and only reliable
way to present it because there's not really any conventions about the
times that are being reported (specifically, no guarantee that the times
won't be overlapping).  Reporting the times of a bunch of async operations
(or top-level and lower level timings) are going to be really valuable but
there's no way for the generic tooling to know if the operations are
blocking on the back-end or overlapped.

On Sun, Nov 23, 2014 at 9:37 PM, Nottingham, Mark <mnotting@akamai.com>
wrote:

> LGTM.
>
> One thing that's going to be interesting is to see how developer tools
> visualise this, since that's usually a timeline, and as you say this isn't
> relative to the client's view of time.
>
> I suspect they might just show it in the server-side portion of things,
> and clarify (how) that it's showing a proportion of the server time, not an
> implicit ordering. That may be a big ask, though.
>
> Tell me if you need help with specifying the header ABNF, etc.
>
> Cheers,
>
>
> > On 20 Nov 2014, at 2:08 am, Ilya Grigorik <igrigorik@google.com> wrote:
> >
> > A (really) rough draft:
> https://cdn.rawgit.com/igrigorik/f940a4705a83f6ec2225/raw/0533e5809606abe2ee9c514a95ca6e7da02975be/server-timing.html
> >
> > Does the general shape and functionality feel about right? I've tried to
> capture the use cases we've discussed on this thread and map those to
> existing HTTP syntax for parameters and modifiers.
> >
> > - I've omitted timestamps, because we can't reasonably map those into
> the client's timeline.
> > - Metrics can have an optional value, description, or both... i.e. you
> can report a [name], [name, duration], [name, duration, description],
> [name, description]. I think that covers all the necessary cases?
> >
> > For now, I've also intentionally omitted the plumbing to expose the
> metrics... I think we have two options:
> > 1) Extend NavTiming / ResourceTiming entries to contain a
> "serverMetrics" (or some such), which would be an array of above server
> metrics.
> > 2) Expose server metrics as own type alongside other existing metrics.
> >
> > Thoughts, feedback?
> >
> > ig
> >
> > On Wed, Nov 12, 2014 at 8:18 PM, Ilya Grigorik <igrigorik@google.com>
> wrote:
> >
> > 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
> >
> >
>
> --
> Mark Nottingham    mnot@akamai.com    https://www.mnot.net/
>
>
>
>
>
>