Closed Bug 1519497 Opened 6 years ago Closed 5 years ago

Firefox slows down and freezes when Linkedin fetches new jobs to view (churning in flexbox layout)

Categories

(Core :: Layout: Flexbox, defect, P2)

Product:
Core
Component:
Layout: Flexbox
Version:
64 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Project Flags:
Performance Impact high

People

(Reporter: dmjr.work+ff, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Keywords: perf:responsiveness, Whiteboard: [layout:backlog:quality])

Attachments

(1 file)

firefox - a website is slowing down your browser.PNG
(deleted), image/png
Details

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

Steps to reproduce:

STR:

  1. Log in to Linkedin and go to Jobs (https://www.linkedin.com/jobs/)

  2. After the first batch of jobs, click "Search for more jobs."

  3. Almost every time I get the attached message about a site slowing down my browser.

Note: I was not able to reproduce this issue, with similar tabs open and the same site in question, in the most current version of Chrome.

Actual results:

Firefox throws a message saying a site is slowing down my browser.

Performance log: https://perfht.ml/2H74rYH

Expected results:

The site should load more quickly and not get bogged down/throw this message.

Component: Untriaged → Performance
Product: Firefox → Core
Whiteboard: [qf]
Whiteboard: [qf] → [qf:p1:responsiveness]

Looks like there's some flexbox layout slowness in the profile. Tagging myself as needinfo to investigate.

[also marked comment 1 as 'obsolete' just to trigger the magic bugzilla autocollapse behavior, since it's quite tall; but it's still there if we end up needing it.]

Flags: needinfo?(dholbert)

I didn't get the "slowing down your browser" message, but I do see a few seconds of jank from waht seems to be synchronous JS-triggered reflows. Here's the profile I captured, zoomed to the "Event processing delay" region after the click:

https://perfht.ml/2W14Hfg

The first ~half of the delay is running JS, and the second ~half seems to be a bunch of synchronous layouts (that are forced by JS).

In my profile, here's how the ~1s long layout-heavy section breaks down:

  1. The first 392ms is inside of many calls to a JS function called "didInsertElement", which calls into a function called "calculateTargetWidth", which causes a layout flush. So, this is the canonical painful "modify the dom and then immediately flush layout" thrashing behavior. This section of the profile includes ~46 layout flushes, which are each between 4ms and 11ms long. Each reflow's "First invalidated" tooltip seems to show it's from new content being appended ("ContentAppended" is in the stack).

  2. Then we have a fairly long (40ms) restyle.

  3. After that, we spend 404ms in many calls to a function called "_getEllipsisWidth" which also flushes layout. (I'm guessing the "ellipsis" here is a "..." menu-icon in the top right of each job-tile, which is <li-icon ... type="ellipsis-horizontal-icon"> in their DOM. This triggers another ~46 layout flushes, which are each between 4ms and 15ms long. Most of these reflows' "First invalidated" tooltips seem to show that layout was dirty in part due to a node removal ("ContentRemoved" and "Node.removeChild" in the backtrace)

Anway - in all likelihood, we're probably dirtying/reflowing much more of the frametree than we need to for these content insertions/removals.

Blocks: flexbox-perf-issues
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Performance → Layout: Flexbox
Flags: needinfo?(dholbert)
Priority: -- → P2
Summary: Firefox slows down and freezes when Linkedin fetches new jobs to view → Firefox slows down and freezes when Linkedin fetches new jobs to view (churning in flexbox layout)

Their jobs "grid" here is actually a multi-line flex container, and each child is itself a several-layers-deep flexbox. And I'll bet "see more" probably throws new "cards" in there one-by-one, and flushes layout -- and since our flex layout is a bit greedy, that flush will reflow every previous card (perhaps not exhaustively but at least partway into each card), even though nothing about the previous cards have changed.

A few ideas here:

  • The approach in bug 1492538 might help -- it'd presumably help us avoid reflowing previous "job cards" here when we insert a new one at the end.

  • We also might consider retaining flex lines between layouts, and skip flex layout and reflow entirely in any lines before the first one that's been changed. That'd be a more complex & invasive (and would involve a bit of risk from keeping lines up to date when frames inside them are destroyed, etc)., but it might be worth it. We do something like this for inline layout.

Whiteboard: [qf:p1:responsiveness] → [qf:p1:responsiveness][layout:backlog:2019q3]
Whiteboard: [qf:p1:responsiveness][layout:backlog:2019q3] → [qf:p1:responsiveness][layout:backlog:quality]
Depends on: 1492538

Donald, would you mind retesting and seeing if you can still reproduce this bug?

I just retested, and I'm noticing the page is different than it was a year ago -- among other things, it refreshes automatically when you scroll to the bottom now (no need to manually click "Search for more jobs", at least not until you've gotten through many many pages' worth).

Some notes from my testing, for my own reference (& other Firefox developers):

  • here's a profile of me hitting "End" key five times on (logged-in) https://www.linkedin.com/jobs/ in current Firefox Nightly: https://perfht.ml/2Wjxu1i
  • If I filter that for "::Reflow", it shows that I spent ~100ms doing reflow (split across the 5 scroll-to-end events -- and it's pretty evenly distributed, with the first operation having 17ms of samples in reflow, and the last one showing 23ms of samples in reflow. So it's not hugely multiplying as the content grows or anything like that.
  • The "hot" JS functions _getEllipsisWidth and calculateTargetWidth from comment 4 don't seem to show up in the backtrace at all now -- so I think they've rewritten their JS to some extent. I do still see didInsertElement, but we're only spending 13ms inside of it (2.6ms per scroll-to-end), vs. 392ms in comment 4.

So I suspect we can close this as WORSKFORME via the site being changed. (though I am also making progress in bug 1492538 which I think would've helped with the original site if they hadn't changed)

Flags: needinfo?(dmjr.work+ff)

I'll go ahead and call this WORKSFORME for now, since I think the page has been rewritten such that this isn't an issue anymore, per comment 7.

But please reopen if you can still reproduce. Thanks!

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Performance Impact: --- → P1
Keywords: perf:responsiveness
Whiteboard: [qf:p1:responsiveness][layout:backlog:quality] → [layout:backlog:quality]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: