1446072 - Rightmove is very slow to load on both Firefox Desktop

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P2)

Description

[Mark]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180206200532

Steps to reproduce:

Navigate to 
http://www.rightmove.co.uk/property-for-sale/find.html?locationIdentifier=POSTCODE^1616007&radius=0.5&includeSSTC=true

Firefox Desktop (60 or 62) takes ~5 seconds on my MacBook Pro. Safari and Chrome take ~1.5 seconds.

A similar story on my Android phone:- Firefox takes many seconds, Chrome just one or two.

I started to look at Performance capture stuff but it's beyond me. I tried turning Servo off but no difference.

On most other pages I look at, Firefox speed seems similar to Chrome on both desktop and phone.

Comment 1

[Mark]

PS those times are all with uBlock Origin enabled at default settings,

Comment 2

[Emil Pasca [:emilpasca]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0

I have tested this issue on Mac 10.13 and Windows 10 x64 with the latest Firefox release (59.0.1) and the latest Nightly (61.0a1-20180319220116) and haven't managed to reproduce it.

After navigating to the provided URL, the webpage is loaded in ~1.5 second or less. I had also tried this after enabling the uBlock Origin addon with its default settings.

Can you please retest this using the latest Firefox release and latest Nightly build and report back the results?  (You can download the latest Nightly build from here https://goo.gl/57dpxn).
When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/AR5o9d).

Also if the issue still occurs could you please share a performance profile, using the gecko profiler addon from https://perf-html.io/?

Comment 3

[Mark]

On my "main" Retina MacBook Pro running 10.13.3 I tried latest Firefox Nightly and refreshed it and made sure all add-ons were disabled. I saw very much the same effect, about 4 seconds before page content would scroll nicely. I also saw the same effect on my "spare" MacBook Pro which is an older machine running 10.11.

Actually Safari struggles a bit with this page as well. 

But Chrome is lightning fast, it paints within a second and I can scroll albeit without the JS images firing. I can see the load spinner is still working, Chrome is loading content for ~4 seconds, but the page works and scrolls within ~1 second.

I took a FF profile

MacBook Pro 11,1; MacOS 10.13.3; Firefox Nightly 2018-03-19; 1440x900 resolution; Firefox window full screen

https://perfht.ml/2ptpEQp

On my (reasonably fast) Android phone it's truly horrible, it takes many seconds to load the same page until I can scroll.

On a Performance capture on both Mac and Android I see, about 2 seconds into the load, a "script tag" which takes 1400 ms; then a function call for 550 ms, and later a "promise callback" which takes 2150 ms.

I have no idea what I am talking about, but is Firefox waiting for these before I can scroll? Does Chrome not have to wait?

Perhaps I should have filed this as a Firefox Android bug because that's where it seems worst to me.

cheers now

Comment 4

[Emil Pasca [:emilpasca]]

Mike can you please have a look at the performance report from comment 3? In order to see if there's anything actionable here.

Comment 5

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

Hey Mark,

If you go to about:config, and set layout.frame_rate to 15, and then restart the browser, do you find that the page loads more quickly?

Comment 6

[Mark]

No difference. If you're referring to bug 1422090 & the throbber I know about that and have tried low resolution mode. I think my CPU is not throttling.

Effect most pronounced on Android so perhaps bug should be filed as such?

On Chrome Android the images pop in and the page is usable within a fraction of a second even though content loading is still going on in the background for several seconds. 

On Firefox Nightly Android the images don't pop in until ~7 seconds, very near the end of the page load progress bar. 

(Sony Xperia X Compact so reasonable CPU but not flagship)

On MacOS I see the same effect but a more powerful CPU means numbers are smaller: on Chrome page is usable within a fraction of a second; on Firefox usable within ~3 seconds.

cheers now

Comment 7

[Mark]

It's stupid fast on Firefox Focus as well, under a second to scrollable with images. Vs ~7 seconds on Nightly for Android.

Comment 8

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

I'm going to tentatively redirect this to jesup who, I think, is more in tune with mobile performance these days.

Comment 9

[Ciprian Muresan [:cmuresan], Formerly of Ecosystem QA - please needinfo @mcoman for things regarding the team]

Given that this issue has had comments for both the Desktop and Android, I've created a clone of it (bug 1454643) where we can look into the Android side. We'll keep this bug for the Desktop side of things.

@Mike, do you know which component would be suitable for the performance issue on Desktop?

Comment 10

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

(In reply to Ciprian Muresan [:cmuresan], Desktop Engineering QA, :steve from comment #9)
> @Mike, do you know which component would be suitable for the performance
> issue on Desktop?

It's unclear, because I've been unable to reproduce this on Desktop. Are you?

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

So this profile shows a TON of time in the site's js, and doing a lot there, and big chunks in more scripts kicked by a mutation event.  Compositor is busy (video?), and styling takes a long while - but mostly this looks like the JS having bugs and/or making assumptions about the platform that cause it to do a ton of extra work.

It doesn't help the minified script has everything i() or s() (etc) on line 2...

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

I think looking at this in devtools and in chrome's devtools will be far more illustrative of what the difference is.

Trying this in Nightly with devtools:

One thing that stands out to me is that the initial images are all memory-cached for Chrome (on reload); for Firefox none are.  Most took me ~50ms to load (and they're all in parallel), but a few took 400-500ms.  The map (_generate....) took my 1.7s, which was basically all DNS resolution (?? -- it's the same domain as the other requests!)  Chrome marked it as cached, and took 480ms, almost all of it reception time.

Quite a few of our initial requests are blocked, or spend considerable time in DNS, neither of which chrome does.  The second round of image requests (smaller ones) are again not cached, but are marked as spending their time "Waiting", with reception being very fast.

Even the CSS stylesheets are "blocked" after the initial URL load (on "reload") for 55-75ms before receiving data.  Chrome took longer to receive the main page (460ms vs 400) but kicks off the CSS loads much earlier (100's of ms) while still receiving the html, and satisfies them out of disk cache (in ~7ms) versus 55-75ms blocking and 80-100ms reception time for Firefox.

So there seem to be some serious differences in caching and network loads (both), and also how early we kick CSS loads.

NI'ing various network people.  Also, is there a bug on how early we kick CSS loads, options there? NI dbaron on that one, who should know where the bones are buried.

Comment 13

[Patrick McManus [:mcmanus]]

there are some cases where chrome decides to not revalidate things it really ought to.

reload performance doesn't seem to be at the heart of the OP's report - so maybe best not to look at that?

Comment 14

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Patrick McManus [:mcmanus] from comment #13)
> there are some cases where chrome decides to not revalidate things it really
> ought to.
> 
> reload performance doesn't seem to be at the heart of the OP's report - so
> maybe best not to look at that?

Good point - though I suspect he's loaded the page before, and so it's cached where possible already.  I'll clear caches or use a new profile and re-run profiles.  Still, though, there are some major differences and it'd be interesting if we're hitting a bug.

Comment 15

[Ciprian Muresan [:cmuresan], Formerly of Ecosystem QA - please needinfo @mcoman for things regarding the team]

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

I think I was able to reproduce what Mark reported on a MacBook Pro (Retina, 13-inch, Early 2015), on OS 10.12 it took ~10s for the site to load the first time, ~5s second time and Chrome took ~3s the first time. https://perfht.ml/2HbcIX4
On OS 10.13 however I've had worse results: ~11s the first time, much more on subsequent loads (~20-40s), while Chrome took 10s first time and ~6-7s on subsequent loads. https://perfht.ml/2HewvFh

I've also tried to reproduce on an iMac (21.5-inch, Late 2009), on OS 10.13 and it took about ~7s to load the first time as well as subsequent times https://perfht.ml/2HgO1bC. Chrome took ~13s the first time and ~5s on subsequent loads. 


The measurements I've taken could be off by a second... I've started counting once I pressed the right arrow with the url in a new tab and stopped only when the tab loading animation stopped.

Comment 16

[Mark]

I was really timing "time until site scrolls correctly" which is not exact. I think Chrome is sneaky, the load animation stops but the page is still loading in the background. Maybe the page load animation stops when the page scrolls correctly??????

Anyway I cleared caches on both browsers and I see on first load...

- Chrome              ~1 sec to correct scrolling
- Nightly 2018-04-18  ~5 sec to correct scrolling

On subsequent reloads (without clearing cache)

- Chrome              fraction of a second to correct scrolling
- Nightly 2018-04-18  ~5 secs to correct scrolling

Scrolling is always choppy on Firefox even when loading is complete, a fling from top to bottom of the page shows blank and maybe 1/2 second pause before repaint.

Comment 17

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

(In reply to Mark from comment #16)

Hey Mark, just so we're clear - are these latest timings from Android? I ask, because you used the term "fling".

Comment 18

[Mark]

comment 16 is about Mac Desktop on ageing Core i5

Android is worse, for me anyway.

M

Comment 19

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

Thanks, Mark. Sorry about the delay.

So looking at the profiles from comment 15, the problems here are pretty varied. I'm seeing a bit of layout thrashing (the page is dirtying the DOM and then querying layout stuff a few times in a row), and I see a ton of script execution...

Inverting the callstack on the content process main thread that has the page loaded, and getting rid of the idle samples, I _think_ it's safest to put this somewhere under JS. We should see if anybody from the JS team sees anything actionable here.

Comment 20

[Jason Orendorff [:jorendorff]]

Matthew, would you please take a look at this? nbp and I stared at it for a while and there's plenty of interesting stuff to look at but we didn't find one specific thing to improve. (?)

Comment 21

[Matthew Gaudet (he/him) [:mgaudet]]

This may no longer be actionable without help re-reproducing. For me, new profiles however don't seem to show same issue on the same site. This could well be due to code changes on their end. 

* Nightly: https://perfht.ml/2BQOPpz
* 58: https://perfht.ml/2BNlYlY 

My experience is that loads in Chrome and Firefox feel essentially the same today, even on 58. 

Now, looking at the profiles in Comment 15, one thing that does stand out to me is that in all the profiles during the script markers, in inverted callstack mode, you can see the top function is js::jit::ObjectHasGetterSetter, which is used in the megamorphic path for the getter and setter ICs. 

This suggests that what was happening on the site was that it was blowing the specialized Setter and Getter ICs, and ending up in megamorphic mode (see Bug 1328140). It's difficult to provide a good argument for remediation without being able to reproduce, however, this does perhaps hint that there could be circumstances where our megamorphic fallback heuristics are worse than Chrome's.

Comment 22

[mark.j.fisher]

It's 2021 and I am finding that Rightmove is much much slower in FF than Chrome (about 5s compared with <1s).

Comment 23

[Matthew Gaudet (he/him) [:mgaudet]]

Hi Mfishe,

If you'd be willing to grab a new performance profile with our profiler (https://profiler.firefox.com/) it would be worth opening a new bug (and mentioning this one).

For my take, local testing on the URL in the first comment has the three browsers I have quickly to hand (FF Nightly, Microsoft Edge Beta, and Safari) all feel subjectively very similar, with Chrome feeling perhaps a touch snappier than the other two, but certainly not a 5x speed difference; like perhaps 10-20% faster if that.