1435947 - Firefox page loading time is too high on testbook.com

Status: RESOLVED WORKSFORME

(Core :: Performance, defect, P3)

Description

[Veeranna Konda]

Attachment: loading_slower.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180131005949

Steps to reproduce:

1)open www.testbook.com on firefox web.
2)Check the page load time and compare to chrome.


Actual results:

page is loading very slow.
Usually it took 3.73 seconds on mozilla  and it took 2.21 seconds on chrome.
Still the loader is displaying after reload the page also.


Expected results:

It should be faster and should stop loader after loading page.

Comment 1

[Cristina Badescu [:cbadescu], Experiments QA]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180206200532


Hello,

I've tested this issue using latest Firefox release 58.0.2, latest Nightly build 60.0a1 (2018-02-09) and managed to reproduce it. Indeed, there seems to be a delay while loading this page. I've also reproduced this issue on Windows 10x64. 

Here are the performance profiles for both:
Ubuntu 14.04 x64- https://perfht.ml/2EdigyW
Windows 10 x64- https://perfht.ml/2Ef8ZWW

Mike, can you please have a look at these performance profiles and see if there is something that might have caused this issue?

I think the suitable component for this is Core: DOM: Content Processes.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

It's hard for me to derive much that's immediately useful from these profiles. What I see is that we complete the load, and immediately execute a bunch of JS. A bunch of YouTube videos and ads are loaded, and we spend a good chunk of time running their JS and then painting things.

We're painting a lot, but painting isn't taking too long.

I also notice in both profiles a number of main thread IO samples like here: https://perfht.ml/2ooiMTU - this is a problem that should have been fixed in bug 888784, which landed in Nightly a few weeks back.

Are you certain those profiles are from a Nightly build from 2018-02-09? Those samples shouldn't be showing up in builds after 2018-01-23...

Comment 3

[Cristina Badescu [:cbadescu], Experiments QA]

Hello Mike,

I've retested on both OS'es, using the Mozregression tool, I've launched Nightly build 60.0a1 (Build ID: 20180206220102) and still encountered the issue. Here are the results:

Ubuntu 14.04 x64: https://perfht.ml/2BNjFxx
Windows 10 x64: https://perfht.ml/2oszEci

Please let me know if there is anything else that I can do in order to help debugging this issue.

Thanks.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Thanks Cristina,

Okay, a few things I see:

1) The main thread of the content process loading testbook.com is blocked for about 70ms waiting to "flush async paints": https://perfht.ml/2t1eE1Y

2) There are a number of style and layout flushes (not caused by JS, but caused by the refresh driver) for a total of 72ms: https://perfht.ml/2t0BqGS

3) There's this bug chunk of time spent running JIT'd JS on the page in reaction to the DOMContentLoaded and load events: https://perfht.ml/2sUBzMj

The biggest chunk is the JS, so I'm going to tentatively point this djvj's way to see if there's anything in the profile that I've missed in that last bit.

Comment 5

[Kannan Vijayan [:djvj]]

20% of the JS time is spent in the Ion compiler.  The rest of it just seems to be regular JS execution.  I suspect in case that the heavyweight compile is the best target.  My guess is any perf hits in other places is death by a thousand cuts.

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

Still the loader is displaying after reload the page also.

This part is still true.

Changing the component as this is performance related.

Comment 7

[Denis Palmeiro [:denispal]]

I cannot reproduce this problem any longer. Please reopen if the problem persists.