WebPagetest Forums

Testing: https://jpeg.speedcf.com/swtest.html with and without ServiceWorker gives very different results in Chrome.

Without SW all images are requested immediately and received in parallel.

On the second run, when ServiceWorker kicks in, "waiting" state appears all over the waterfall. Image requests are significantly delayed, and responses arrive one by one, instead of being streamed in parallel.

ServiceWorker in this case is intentionally the most basic one:

Code:

self.addEventListener('fetch', event => {

    return event.respondWith(fetch(event.request));

});

I'm seeing the delays only in Chrome. In Firefox runs with and without ServiceWorker are identical.

Is that some quirk of WebPageTest, e.g. related to simulation of slow connections? Can this be a Chrome bug?

Here's an example run: https://www.webpagetest.org/result/19111...6e3e632bf/

[attachment=923]

[attachment=922]

I think it's the result of Chrome's network stack using different prioritisation mechanisms for different network qualities.

AFAIK at low speeds Chrome reverts to an approach similar to the one it used for HTTP/1.x

Comparing 3GSlow and Cable profile tests, the 3GSlow (https://www.webpagetest.org/result/19111...33b0ba0e5/) has the staggered waterfall on repeat view, but the Cable (https://www.webpagetest.org/result/19111...caf12f4e1/) one doesn't

That said not sure why the profile only applies in the SW case

On further testing I think it is the loading of the ServiceWorker js which stops Chrome from requesting the images with same priority until the ServiceWorker is loaded. Then the images are requested in parallel. WPT appears to display information about the request to the SW rather than the SW fetch to the origin. I'm not entirely sure where the HTTP/1.1 protocol and Priority LOWEST.

Kornel

andydavies

AndrewG