1730852 - Service Worker slows down resource load times (may involve tracking protection)

Status: VERIFIED FIXED

(Core :: Networking, defect, P2)

Description

[Petras]

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).

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 3

[Andrew Creskey [:acreskey]]

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

Comment 4

[Andrew Creskey [:acreskey]]

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

Comment 5

[Andrew Creskey [:acreskey]]

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?

Comment 6

[Markus Stange [:mstange]]

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

Comment 7

[Tim Huang[:timhuang]]

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?

Comment 8

[Dragana Damjanovic [:dragana]]

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.

Comment 9

[Patricia Lawless]

moving to Core::Networking (see comment 7)

Comment 10

[Kershaw Chang [:kershaw]]

Attachment: log.txt-main.61182.moz_log

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.

Comment 11

[Kershaw Chang [:kershaw]]

I'll have a look.

Comment 12

[Kershaw Chang [:kershaw]]

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.

Comment 13

[Manuel Bucher [:manuel]]

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

Comment 14

[Manuel Bucher [:manuel]]

Attachment: Bug 1730852 - Fix classOfService information being lost when redirecting to InterceptedHttpChannel r=#necko

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.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3ed55e55a478
Fix classOfService information being lost when redirecting to InterceptedHttpChannel r=necko-reviewers,valentin

Comment 16

[Iulian Moraru]

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

Comment 17

[Catalin Sasca, Desktop QA [:csasca]]

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.