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
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/
<rdar://problem/89960336>
Created attachment 454185 [details] Patch
(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.
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?
Firefox (97, 98) and Chrome 99 (MacOS) always return a responseStart value.
(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.
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.
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..
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
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.
It looks like we're missing requestStart, responseStart, and responseEnd. Chrome and Firefox have them. And it needs a test...
Created attachment 454927 [details] Patch
Created attachment 454994 [details] Patch
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.
Created attachment 455001 [details] Patch
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].
Thanks for the report!