[Feature] Align server timing bars by relative start time (only when present)

[Ateş Göral]

Summary:

When "start" parameters are present for metrics, align the left edge of metric bars based on the *relative* values of start parameters, similar to how Timing bars are rendered above the Server Timing section.

Motivation / concrete example:

We return a Server-Timing header from server-side rendering where some operations are performed in a waterfall fashion. While seeing how much time is spent in each operation in a vertical stack is already very useful, it would be *tremendously* useful to see the waterfall relationship.

Spec:

https://www.w3.org/TR/server-timing/ allows for custom parameters and makes mention of "startTime" with the warning:

> Because there can be no guarantee of clock synchronization between client, server, and intermediaries, it is impossible to map a meaningful startTime onto the clients timeline.

Fair. But it would be very useful to support this as an optional feature for environments that have clock sync guarantees i.e. all Server-Timing emitters are in clock-sync, or e.g. Server-Timing comes from a single server.

Proposal:

1. Use "start" (keep it short).

2. Server-Timing emitters make the value be 0 (ms) for the earliest metric and make the start values of other metrics relative to the earliest metric.

3. During rendering, align the left edge of metric bars to the relative start values.

4. Add an option in DevTools to opt into this feature, for developers to turn it on only when they know they can rely on start parameters.

The ask:

Would this fly? Testing the waters before I spend the effort for a local prototype / PR. (Worst case, I can write a Chrome extension to add a new tab to DevTools to do this.)

Cheers,

Ates

[Paul Irish]

The full thread about this integration includes a similar discussion 

https://bugs.chromium.org/p/chromium/issues/detail?id=594800

You'll spot Ilya's replies about startTime and total. He was the spec editor then.

Also note the spec issue threads about this: 

• add total to distinguish between calendar time and effort time · #44 · w3c/server-timing 
• add start time to distinguish between cached and active entries · #43 · w3c/server-timing
  

Of course, Network Panel could interpret the ST payload with meaning that the spec doesn't denote... And I think many people would be happy to see that. But... it's tricky. +Noam who may have thoughts.

--
You received this message because you are subscribed to the Google Groups "Chrome DevTools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/12704d4f-2f9e-44bf-b6e5-36fdaa04d5a0n%40googlegroups.com.

[Noam Rosenthal]

On Tuesday, August 16, 2022 at 2:23:48 AM UTC+3 Paul Irish wrote:

The full thread about this integration includes a similar discussion 

https://bugs.chromium.org/p/chromium/issues/detail?id=594800

You'll spot Ilya's replies about startTime and total. He was the spec editor then.

Also note the spec issue threads about this: 

• add total to distinguish between calendar time and effort time · #44 · w3c/server-timing 

I've added some notes to this one.

 

• add start time to distinguish between cached and active entries · #43 · w3c/server-timing

Also this one about defining the unit of the durations: https://github.com/w3c/server-timing/issues/86 

• 
  

Of course, Network Panel could interpret the ST payload with meaning that the spec doesn't denote... And I think many people would be happy to see that. But... it's tricky. +Noam who may have thoughts.

It's tricky to start giving startTime meaning to ServerTiming entries now that they're in the wild. Especially since this startTime is approximate at best as it comes from different clocks from each other and from the user, the latter being more significant. In many cases it can give a false sense of accuracy.

However, I see how services would like to give DevTools users a waterfall approximation. If we can find a balance where this info is available but not expected to be accurate I'm fine with it. Perhaps call this approxStartTime to emphasize that it's inaccurate? 

On Sat, Aug 13, 2022 at 9:28 AM 'Ateş Göral' via Chrome DevTools <google-chrome-...@googlegroups.com> wrote:

Summary:

When "start" parameters are present for metrics, align the left edge of metric bars based on the *relative* values of start parameters, similar to how Timing bars are rendered above the Server Timing section.

Motivation / concrete example:

We return a Server-Timing header from server-side rendering where some operations are performed in a waterfall fashion. While seeing how much time is spent in each operation in a vertical stack is already very useful, it would be *tremendously* useful to see the waterfall relationship.

Spec:

https://www.w3.org/TR/server-timing/ allows for custom parameters and makes mention of "startTime" with the warning:

> Because there can be no guarantee of clock synchronization between client, server, and intermediaries, it is impossible to map a meaningful startTime onto the clients timeline.

Fair. But it would be very useful to support this as an optional feature for environments that have clock sync guarantees i.e. all Server-Timing emitters are in clock-sync, or e.g. Server-Timing comes from a single server.

Proposal:

1. Use "start" (keep it short).

2. Server-Timing emitters make the value be 0 (ms) for the earliest metric and make the start values of other metrics relative to the earliest metric.

Many times those emitters are separate and not always connected to each other, and those timings could be parallel to each other. Making this into some sort of a linked-list would not fly :)

 

3. During rendering, align the left edge of metric bars to the relative start values.

4. Add an option in DevTools to opt into this feature, for developers to turn it on only when they know they can rely on start parameters.

Can't they just ignore it if they can't rely on them?

 

The ask:

Would this fly? Testing the waters before I spend the effort for a local prototype / PR. (Worst case, I can write a Chrome extension to add a new tab to DevTools to do this.)

I'd love to see this in the spec and not just in DevTools. would be happy to help.