Bug 237317 – PerformanceNavigationTiming Response Start unavailable when using Service Worker Cache

• Status: RESOLVED
• Resolution: FIXED
• Component: Service Workers

[Daniel Schulz]

Created attachment 453487 [details]
A Document, Script and Service Worker that exhibit the described bug

When The document is being served from a Service Worker Cache, the PerofrmanceNavigationTiming API returns always 0 for its responseStart value.
When the document comes from the Network instead of the Service Worker Cache, it responds the correct value.

I expect the responseStart value to always be reported correctly, even if it's being served from Cache.

Tested in Safari 15.2 and 15.4TP on MacOS 12.1 on a MacBook Pro M1 2020.

Steps to reproduce:
- Serve the files from the attached zip
- Open the index.html in Safari
- Reload the page

[Daniel Schulz]

Amendment: Apparently the responseStart Value is missing for all request that go through the service worker, not only cached ones.

I also uploaded a demo on our server for your convenience: https://sw-lifecycle-test.app.baqend.com/safari-timing-sw/

[Radar WebKit Bug Importer]

<rdar://problem/89960336>

[Alex Christensen]

Created attachment 454185 [details]
Patch

[youenn fablet]

(In reply to Daniel Schulz from comment #1)
> Amendment: Apparently the responseStart Value is missing for all request
> that go through the service worker, not only cached ones.

The non-cached service worker loads might be fixed in https://bugs.webkit.org/show_bug.cgi?id=235179.

[youenn fablet]

Comment on attachment 454185 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=454185&action=review

> Source/WebCore/ChangeLog:6
> +        Reviewed by NOBODY (OOPS!).

Can we add a test?

> Source/WebCore/Modules/cache/DOMCache.cpp:89
> +    resourceResponse.setDeprecatedNetworkLoadMetrics(WTFMove(metrics));

NetworkResourceLoader does not fill the network load metrics in the same way in case of a matching cache entry.
Should we be consistent?
Also, is this consistent with what other browsers are doing?

[Daniel Schulz]

Firefox (97, 98) and Chrome 99 (MacOS) always return a responseStart value.

[youenn fablet]

(In reply to Daniel Schulz from comment #6)
> Firefox (97, 98) and Chrome 99 (MacOS) always return a responseStart value.

Sure, the question is what other values they are providing.
For instance, is the timing info from load served from service worker cache similar to   loads served from network cache.

[Daniel Schulz]

Chrome and Firefox treat SW response time as the responseStart value. 
In my tests it's consistently marginally faster than the TTFB from network cache responses. Those two are treated the same way, both in the Network diagram and in the responseStart value from the performanceNavigation API.

[Chris Dumez]

Comment on attachment 454185 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=454185&action=review

> Source/WebCore/platform/network/NetworkLoadMetrics.h:97
> +    bool complete : 1 { false };

FYI, I tried this recently since it is supposed to work in C++20. However, our Windows bots don't like it still..

[Alex Christensen]

Comment on attachment 454185 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=454185&action=review

I was hoping there was a web platform test for this already and it would start passing.  Looks like we'll need to write one.

>> Source/WebCore/Modules/cache/DOMCache.cpp:89
>> +    resourceResponse.setDeprecatedNetworkLoadMetrics(WTFMove(metrics));
> 
> NetworkResourceLoader does not fill the network load metrics in the same way in case of a matching cache entry.
> Should we be consistent?
> Also, is this consistent with what other browsers are doing?

This is consistent with what other browsers are doing, but we still need to look into what happens with the disk cache and with the other metrics

[Braden O'Guinn]

Our company is seeing this same issue. Webkit running on iOS/OSX 15.X consistently returns 0 values for PerformanceNavigationTiming entries, whereas these numbers are populated via the deprecated window.performance.timing (minus redirectEnd, redirectStart, and secureConnectionStart) with correct timestamps. See below:

PerformanceNavigationTiming:

connectEnd: 0
connectStart: 0
domComplete: 4308
domContentLoadedEventEnd: 2202
domContentLoadedEventStart: 2030.0000000000002
domInteractive: 2030.0000000000002
domainLookupEnd: 0
domainLookupStart: 0
duration: 4311
entryType: "navigation"
fetchStart: 0
initiatorType: "navigation"
loadEventEnd: 4311
loadEventStart: 4309
name: "https://www.etsy.com/market/citrine"
nextHopProtocol: ""
redirectCount: 0
redirectEnd: 0
redirectStart: 0
requestStart: 0
responseEnd: 0
responseStart: 0
secureConnectionStart: 0
startTime: 0
type: "navigate"
unloadEventEnd: 1020
unloadEventStart: 1019.0000000000001
workerStart: 0

window.performance.timing:

connectEnd: 1647455955426
connectStart: 1647455955426
domComplete: 1647455959163
domContentLoadedEventEnd: 1647455956101
domContentLoadedEventStart: 1647455956081
domInteractive: 1647455956081
domLoading: 1647455955735
domainLookupEnd: 1647455955426
domainLookupStart: 1647455955426
fetchStart: 1647455955426
loadEventEnd: 1647455959168
loadEventStart: 1647455959165
navigationStart: 1647455955411
redirectEnd: 0
redirectStart: 0
requestStart: 1647455955426
responseEnd: 1647455955715
responseStart: 1647455955715
secureConnectionStart: 0
unloadEventEnd: 1647455955734
unloadEventStart: 1647455955734

This is a navigation request with an empty service worker serving the page request from-network. We would expect to see this populated fully, as it is in Firefox, Chrome, Opera, etc.

[Alex Christensen]

It looks like we're missing requestStart, responseStart, and responseEnd.  Chrome and Firefox have them.  And it needs a test...

[Alex Christensen]

Created attachment 454927 [details]
Patch

[Alex Christensen]

Created attachment 454994 [details]
Patch

[youenn fablet]

Comment on attachment 454994 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=454994&action=review

> LayoutTests/http/wpt/service-workers/resources/navigation-timing-part-2.html:9
> +    let navTiming = performance.getEntries()[0];

Maybe add a test to check that navigator.serviceWorker.controller is not null.

> LayoutTests/http/wpt/service-workers/resources/navigation-timing-part-2.html:10
> +    let navTimingResult = (navTiming.requestStart > 0

Could be const.

[Alex Christensen]

Created attachment 455001 [details]
Patch

[EWS]

Committed r291441 (248565@main): <https://commits.webkit.org/248565@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 455001 [details].

[Alex Christensen]

Thanks for the report!