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

Hmm, so the data center use case is fairly common. Interesting.

It's not clear to me what the best route is to tackle non-timing data...
currently, all of our specs are surfacing timing events. A couple of routes:

1) Record non-timing data as timing events - e.g. pop=22 would be surfaced
as a timing event with duration of 22ms... but, in reality, you'd be
communicating that you used pop #22, which is something your application
could know an process accordingly. Pro: simple, no spec or UA changes
required. Con: we're polluting the timeline, which would become a problem
once UA's start surfacing these events in their devtools, etc.

2) We extend timing events with some form of annotations [1]. Assuming that
exists, you could annotate existing timing event(s) with relevant meta-data
- e.g. cache=23;nyc --> { name: 'cache', duration: 23.0, meta: 'nyc' },
where 'nyc' is an arbitrary string that could, for example, be used to
indicate the data center.

If we go down the route of adding annotations, it seems like it's something
that should be available on all timing events. That said, I'd love to hear
more use cases for it.

Thoughts / comments?

[1] https://github.com/w3c/performance-timeline/issues/2

On Mon, Nov 10, 2014 at 8:05 AM, Ben Maurer <ben.maurer@gmail.com> wrote:

> How would this handle pages that are rendered incrementally where full
> timing data isn't available with headers?
>

You'd have to use trailer headers - stream the page, then emit the
Server-Timing header at the end.

ig