LinkedIn loads 2+ sec slower on Firefox compared to Chrome




a year ago
8 months ago


(Reporter: Harald, Unassigned, NeedInfo)


(Blocks: 1 bug, {perf})


Firefox Tracking Flags

(firefox53- wontfix, firefox54 wontfix, firefox55+ fix-optional, firefox56 affected)


(Whiteboard: [qf:investigate][platform-rel-LinkedIn], URL)



a year ago

- Log in
- Open (or

Pages load massively slower, over 2-3sec. This is confirmed by LinkedIn contacts.

Profile on Mac/Nightly collected while navigating around the page:

Comment 1

a year ago
The initial thought was that bug 1331680 causes most of the issue as LinkedIn read cookies 60+ times during page load. They fixed that and the cookie is read only once now but page load did not improve.

naveed, can we confirm that 2sec+ slowness is just JS issues with Ember?
Flags: needinfo?(nihsanullah)

Comment 2

a year ago
[Tracking Requested - why for this release]:
Slow page load reported by users and confirmed by LinkedIn.
status-firefox53: --- → affected
tracking-firefox53: --- → ?
I can see the slowness, but I couldn't tell much from the profile. Although some of the JS function names were kind of weird -- i.prototype.compile(), e.prototype.compileStatement(), t.prototype.evaluate(). Seems like there must be some processing engine running within JS?

evilpie, does your CacheIR dumper show anything interesting?
Blocks: 1299643
Flags: needinfo?(evilpies)
:sfink does TraceLogger give any other insight?
Flags: needinfo?(nihsanullah) → needinfo?(sphink)
I don't see anything super bad and I also don't get 2s load times. Actually because we fallback to the generic stub now, it's not necessarily easy to tell. I really need to fix bug 1348821, but I don't have a good approach for it.

Some things that stood out to me: hasOwnProperty where the base is a primitive, in on an arguments object (both indexes and length) and SetElem with an index.

Btw: Running CacheIR is really simple now, just start Nightly with CACHEIR_LOGS=1.
Flags: needinfo?(evilpies)
Can you test with 55 or 54 rather than 53? I can also ask for QE help here. 

It seems unlikely we'll be fixing this for 53, though if you disagree, please let me know.
status-firefox53: affected → wontfix
status-firefox54: --- → affected
status-firefox55: --- → affected
tracking-firefox53: ? → -
Tracking for 55 to make sure this doesn't get lost in the shuffle.
tracking-firefox55: --- → +
This did get lost. Andrei can your team have a look to see if this is still true? 
sfink, can you still see the perf issues at all?
status-firefox54: affected → wontfix
status-firefox55: affected → fix-optional
status-firefox56: --- → affected
Flags: needinfo?(andrei.vaida)

Comment 9

11 months ago
I did a layman test on my win10 laptop and it is indeed 2-3 seconds slower to load on Nightly56 as compared to Chrome v59
I could also see this in latest Nightly 56 compared with Chrome 59, Windows 10 64bit. So this is definitely still here. Please let me know if there is something I can help with here.
Flags: needinfo?(andrei.vaida)
You need to log in before you can comment on or make changes to this bug.