Specify the behaviors of requestStart and responseStart for Prefetch

[liuwilliam-gh]

For speculation-rule based prefetch, the resource-fetching occurs before the navigation, resulting in negative values for requestStart and responseStart (measured w.r.t startTime, see below).

Exposing the negative values allows us the capture the full metrics; the down side is the potential security/privacy leak; and can skew existing measurements.

Alternatively we can set requestStart to connectEnd and responseStart to requestStart. This way the order of the events are fully respected, resembling the events timeline of a navigation hitting a HTTP cache (no revalidation). However this way we lose some measurements.

What do folks think?

P.s, I also think we should have the same negative behaviors for all the golden fields (domainLookupStart, domainLookupEnd, connectStart, secureConnectionStart and connectEnd); but at least for Chromium they are all zeros, for not only prefetch but for normal navigation from the landing page to the designated URL. Is this expected?

[yoavweiss]

Thanks for filing this issue!

As you noticed, we've traditionally set events that happened before the timeOrigin as 0, and resisted the temptation of reporting negative times. I'd prefer to stick with that, unless there are strong arguments as to why when these timestamps happened in the past matters.

Alternatively we can set requestStart to connectEnd and responseStart to requestStart.

Wouldn't connectEnd be 0 in this case?

[jeremyroman]

It seems to me there are basically two ways to reflect a prefetch request:

Like a cache hit. In this view, the prefetch buffer looks similar to the HTTP cache. I would expect most of the timestamps (at least up to responseStart) to be zero or quite close to it. This means that it looks to unaware code like a request that was pretty fast. (This, to my mind, matches the user's subjective experience.)

Like an uncached response which started before T=0. In this view, we're seeing the prefetch as a request which started before the navigation itself did (at a negative timestamp). This gives more visibility into the underlying timing of the actual events as they happened (though this visibility would be missing for responses cached in other ways anyhow), but may make the request seem slow (since prefetch requests may be initially low priority), especially if you compare events which are blocked by the user navigation (like domComplete).

I think my preference is the former, but I think at least one participant (I can't seem to find who in my notes, but I believe it was someone representing Akamai mPulse?) suggested the additional information of the latter approach would be helpful.

Note that deliveryType (proposed) would allow distinguishing prefetched from non-prefetched responses in any event.

[liuwilliam-gh]

Wouldn't connectEnd be 0 in this case?

In Blink, the zero value of connectEnd is set to connectStart(link), and this seems to be the convention for many timing fields. I think the purpose is to respect the event ordering to avoid any upset on the existing metrics, and to avoid any confusion. The negative value on PerformanceNavigationTiming in Blink is disallowed, i think, for the same reason.

The attempt in crrev.com/c/4009904 was to follow the existing convention.