User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36

Steps to reproduce:

We found a performance issue for resources coming from specific domains when the service worker is present and has a fetch handler (even if it's just an empty function). To reproduce this you can open this page (make sure to disable Cache in Network tab and refresh once SW is installed):

https://ultimate-fairy-77.app.baqend.com

You will see printed resource timings of two scripts. One is affected by the bug (dev.visualwebsiteoptimizer), the other one (cdn.jsdelivr) is not.

By default, the SW is enabled. To disable the Worker, add ?sw=false to URL and refresh twice to see effects. They are roughly the same speed when SW is not present.

We found several scripts that have this issue, all of them seem to be detected as a tracker in the Network tab, but disabling Tracking Protection did not help.

We also tested this on Nightly and Beta with no success.

Actual results:

The affected request often takes over 1 second with SW, and under 100ms without.

Expected results:

We would expect the request not to be affected by the Worker (~100ms).

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Service Workers' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

The severity field is not set for this bug.
:asuth, could you have a look please?

For more information, please visit auto_nag documentation.

Hi Petras,
Thank you for filing this and providing the clear test case.

I've reproduced your findings and captured a profile but I'm not seeing what is the root cause of the delay.
https://share.firefox.dev/3nwA8g0

I can also see that the slower resources is flagged as a tracker.
So let me find someone more familiar with the area.

Tim, would you be able to find someone with tracking-protection understanding to help discern if that is the root cause of this performance issue?

Setting qf:p1:pageload because a 10x slowdown from a no-op service worker sounds quite bad.

I think the performance issue lives in the SW intercept code in Necko. I've tried adding the tracking resource to the tracking annotation skip list and the loading time became normal. And I also tried disabling ETP protection, but it doesn't really help. So, the issue has nothing to do with the content blocking, but is more likely in SW intercepting tracking resources.

Seeing here, we mark the channel with nsIClassOfService:Tail when the channel is a third-party tracking resource. IIUC, this would delay the loading of the tracking resource until other loads are finished. Maybe this can explain the reason why the loading is so slow.

Dragana, I believe this is intended behavior. What do you think?

nsIClassOfService:Tail was exactly made for the hird-party tracking resource.

We may revisit this decision if needed, but I need to understand more here.

moving to Core::Networking (see comment 7)

I've tried to reproduce this locally and the log is uploaded.
The log really shows that the tracking resource was delayed because of tailing, but it's unclear why this didn't happen when service worker is not used.

I'll have a look.

Hi Manuel,
I think I know what's the problem here and if you want, I can guide you to fix this bug.
Feel free to say no if you are not interested.
Thanks.

Thanks, I'm interested to look at this with your guidance.

nsCOMPtr<nsIClassOfService> cos(do_QueryInterface(newChannel));1 was
previously returning a nullptr for objects of the class InterceptedHttpChannel.
Therefore the classOfService flags weren't set after the redirect to the
InterceptedChannel2.

https://hg.mozilla.org/mozilla-central/rev/3ed55e55a478

Reproduced the issue on Firefox 94.0a1 (2021-09-15) under macOS 11.6.4 by following the STR from Comment 0.

The issue is fixed on Firefox 98.0. Tests were performed on macOS 11.6.4, Ubuntu 20.04 and Windows 11.