ServiceWorker in Chrome causing delays, serialized requests

Web Performance Discuss Test Results
1

Testing: Serviceworker test 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:

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: WebPageTest - Running web page performance and optimization tests...

[attachment=923]

[attachment=922]

2

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 (WebPageTest - Running web page performance and optimization tests...) has the staggered waterfall on repeat view, but the Cable (WebPageTest - Running web page performance and optimization tests...) one doesn’t

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

3

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.