github web-platform-tests/wpt merge_pr_46060

latest releases: merge_pr_49470, epochs/three_hourly/2024-12-03_06H, epochs/six_hourly/2024-12-03_06H...
16 months ago

Correct responseStart and similar timestamp for prefetches which blocked on head

In early revisions, prefetches could not be served until the response
head had arrived, and any navigation before that time would not wait for
the prefetch but issue a new request. Consequently, it sufficed to allow
these values to duplicate the previous timestamp, since these always
logically occur before navigation.

Since Chromium's PerformanceResourceTiming and
PerformanceNavigationTiming implementations do this automatically in the
absence of valid timestamps, this was accomplished by preventing load
timing information from being included with a prefetched response.

Instead, we should pass along the essential timestamps for computing
typical metrics, but simply adjust those that occur before fetchStart to
occur at the same time as it, as though they had completed
instantaneously (since, from the perspective of the user experience,
it's as though they had).

A feature param is included to allow effectively reverting to the old
behavior in case of emergency.

See this doc for more info:
https://docs.google.com/document/d/1oESLkgpXysbl_FQMZ5Ahj3xtHW6d_UTcB-StJrS7a1U/edit

Bug: 337199386,1382255
Change-Id: I8cdde8465f87c4893780c835222bfd303b05dfc1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5502156
Commit-Queue: Jeremy Roman jbroman@chromium.org
Reviewed-by: William Liu liuwilliam@chromium.org
Reviewed-by: Adithya Srinivasan adithyas@chromium.org
Cr-Commit-Position: refs/heads/main@{#1297011}

Don't miss a new wpt release

NewReleases is sending notifications on new releases.