- From: Ben Kelly <notifications@github.com>
- Date: Fri, 19 Oct 2018 08:19:36 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1361@github.com>
Sites using navigation preload may wish to measure when the preload starts relative to other events. Currently this information is exposed in the service worker context as a PerformanceResourceTiming entry. For example, this demo logs the navigation preload start time: https://sw-pass-through.glitch.me/ It basically is doing this: ```javascript let r = await evt.preloadResponse; if (r) { // Log the performance data for the last entry matching this URL initiated for // navigation. Probably the preloadResponse... let list = performance.getEntriesByName(evt.request.url); let entry = list.length ? list[list.length - 1] : null; if (entry && entry.initiatorType === 'navigation') { console.log("==> navigationPreload started at: " + entry.startTime); preloadStartList.push(entry.startTime); } return r; } ``` This works in both chrome and edge. I don't see where in the spec this behavior is defined, though. In theory the navigation preload may start before the service worker browsing context is created, so it seems a bit extraordinary that the preload request shows up in its performance entry buffer. Another quirk I noticed. When the service worker needs to be started chrome will report a negative startTime for the preload, but edge does not (at least in my limited testing). This may not matter much in practice since it seems they are all still correctly relative to performance.timeOrigin, but its a small difference. To be clear, I think we should support measuring the preload request. I just want to make sure its spec'd somewhere so we're all on the same page. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/1361
Received on Friday, 19 October 2018 15:20:01 UTC