1342781 - More network wait & blocked time than in Chrome

Status: NEW

(Core :: Networking: HTTP, defect, P3)

Description

[Creak]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

Install an instance of Nextcloud 11 on an HTTP1 instance, set it up and go to the main page with a cleared cache.


Actual results:

Each time you clear your cache and go to the main page, it takes 30 seconds.


Expected results:

On Chrome it "only" take 5 seconds.

The problem is that there are way too much loading requests (~240) and they are loaded synchronously in Firefox while it seems that they are loaded asynchronously on Chrome. A workaround has been found by using "defer", but we would like to have the insights of a Firefox dev on what is real the problem here.

Please read this Nextcloud issue starting from this comment to understand the details:
https://github.com/nextcloud/server/issues/2272#issuecomment-280913134

PS: We know that HTTP2 is the future, but some Nextcloud admins don't have access to it yet, so we have to deal with that for the time being.

Comment 1

[Andrew Overholt [:overholt]]

Maybe Henri can take a look and see if we're doing something incorrect here.

Comment 2

[Henri Sivonen (:hsivonen)]

> Install an instance of Nextcloud 11 on an HTTP1 instance, set it up and go to the main page with a cleared cache.

Is there a public URL that demonstrates the problem without having to install something?

Comment 3

[Creak]

Nope, but it's really easy to install one (just use a Debian stable, it doesn't have HTTP2 yet).

Comment 4

[xdmx]

You can create a demo account at this page: https://demo.nextcloud.com through the second link (Instant trial)

I've just created one and I can somehow confirm that Firefox is much slower than Chromium to load (15.89s vs 1.81s): http://i.imgur.com/os86ujU.png

Comment 5

[xdmx]

Attachment: Loading time under Chromium 56 and Firefox 52

Comment 6

[Creak]

See @xdmx comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1342781#c4

Comment 7

[Andrew Overholt [:overholt]]

Henri, can you take a look?

Comment 8

[Henri Sivonen (:hsivonen)]

I'll take a look after bug 1354989. Keeping myself needinfoed to remember.

Comment 9

[Henri Sivonen (:hsivonen)]

I do see overall slowness but not slowness obviously attributable to the HTML parser.

I see the fetch for the HTML file itself spending more time waiting for the first byte in Firefox than in Chrome. (I don't know how that could be the browser's fault.) Then I see a bunch of SVG asset fetches spending more time blocked in Firefox than in Chrome. Analyzing those waits/blocks is outside my area of expertise, so sending this over to networking.

Comment 10

[Michal Novotny [:michal]]

Honza, is this something you could investigate with backtrack?

Comment 11

[Honza Bambas (:mayhemer)]

(In reply to Michal Novotny (:michal) from comment #10)
> Honza, is this something you could investigate with backtrack?

Likely yes, if we had it :D  

Before that someone should simply look at the devtools waterfall in chrome and firefox.  I suspect they are limiting parallelism more then we do, but this depends on how many hosts there are (240 means definitely at least 40 hosts).  Some top-view PCAP compare might tell something too.

Comment 12

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 13

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258