1243659 - Dragging rows in Netflix DVD queue is very laggy

Status: NEW

(Core :: Layout, defect)

Description

[Chris Peterson [:cpeterson]]

STR:
1. Load Netflix DVD queue (not the "Watch Instantly" queue for streaming movies): https://dvd.netflix.com/Queue
2. Click and drag a DVD row to a new position in the queue.

RESULT:
In Firefox, the delay from dragging the row to the row actually moving is about 3–5 seconds! In Chrome, the delay is less than about 200 ms.

I have a Gecko Profiler report I can share. It looks like jQuery is triggering a lot of block frame reflows. My Netflix DVD queue is pretty long (about 400 DVDs), if that matters.

Comment 1

[Chris Peterson [:cpeterson]]

Netflix's DVD queue page is still much slower in Firefox 53 than Chrome.

Comment 2

[Mike Taylor [:miketaylr]]

Chris, can you share a link to the profile?

Comment 3

[Chris Peterson [:cpeterson]]

(In reply to Mike Taylor [:miketaylr] from comment #2)
> Chris, can you share a link to the profile?

I'll send you the login info for a test account. Note that the drag lag only happens with the DVD queue, not the "Watch Instantly" queue. The lag only becomes noticeable after I add 100+ DVDs to the queue.

https://dvd.netflix.com/Queue?qtype=DD

Comment 4

[Mike Taylor [:miketaylr]]

Tom, can you take a closer look? I'll forward the test credentials via email.

Comment 5

[Thomas Wisniewski]

I do see a jarring 750ms delay when starting a drag on any DVD on that page, but not much stands out to me in a Cleopatra profile other than it being JS-related (Firefox 50): https://cleopatra.io/#report=e478afed8e241978542429dc0c1a9c1e918d67fd

A devtools performance profile shows that the delay happens in a mousemove listener, as jQuery UI creates the shadow image of what's being dragged (to follow the mouse). Unfortunately, by tinkering with mitmproxy, I've found that the problem is spread out in the code. For instance;

>select lines in the function: _mouseStart: function(event, overrideHandle, noActivation)
>   this.refreshPositions(); // 180ms
>   this.cssPosition = this.helper.css("position"); // 100ms
>   this.originalPosition = this._generatePosition(event); // 50ms
>   if (o.containment) { this._setContainment() } // 170ms

And that's not accounting for a good chunk of the 750ms, either.

At this point I'm not sure if I ought to continue digging on each specific issue, so I thought I'd wait for some feedback first.

Comment 6

[Chris Peterson [:cpeterson]]

Thanks, Tom. Very interesting analysis! It sounds like there is no silver bullet for this 750ms delay.

Do you know why the delay appears to increase linearly with the length of the DVD queue? I had to add 100+ DVDs to the queue before the delay because very obvious.

If you have any JS questions or suggestions for Netflix, I can pass them along to our Netflix contacts.

Comment 7

[Thomas Wisniewski]

>Do you know why the delay appears to increase linearly

Yes, there does seem to be code in there which is at O(n) (or perhaps higher), so it does make sense that the delay would increase in kind. I would need to study the code more to give a definitive answer, however.

>If you have any JS questions or suggestions for Netflix

Perhaps the easiest thing to do would be to avoid using jQuery UI's dragging support altogether, and use the HTML drag-and-drop APIs instead. I think it would be feasible for their use-case, and it should improve performance across the board, but it's not immediately clear how much engineering effort it would require.

Comment 8

[Thomas Wisniewski]

Alright, I've taken a second look at this and think I was on a wild goose chase last time. A devtools performance profile shows that the time spent in the initial mousemove event is mostly in layouts and style-recalculations, as one might expect (since they are measuring various elements in preparation of a drag operation, including the dimensions of each row).

However, it's oddly slow compared to Chrome. For instance, on my system it takes over 100ms to find out if the parent container _isFloating, over 150ms more to getClientBoundingBox of all the rows, another 100ms to get the CSS position property of a helper object, anohter 50ms to determine some scrollTops, another 160ms to get the offset of a container, and then another 100ms to apparently get the window's height and document's scroll position.

Chrome seems to do what Firefox requires almost a second to do in under 100ms, with layout and style recalculation and other related browser tasks allegedly requiring only around 30ms of that time.

I'm not sure where to go from here.

Comment 9

[Mike Taylor [:miketaylr]]

Ideally someone who works on layout can dig in deeper. This issue is a tracking platform-rel issue, so in theory that should happen at some point. ^__^

Comment 10

[Mike Hicks]

Note that a Netflix queue can have a maximum of approximately 500 discs. I currently have 3 discs at home, 471 in the main part of the queue (the part that has the 500-disc limit), and 45 in the "Saved" section (discs that are not in stock or not quite released yet). On my Dell XPS 13 (9350) w/ i7-6560U CPU running Ubuntu, it takes about 35 seconds for Firefox to load the page, including two clicks of the "Warning: Unresponsive Script" dialog. chromium-browser takes about 17 seconds to load, and does not lock up to the same extent.

Comment 11

[Timothy Nikkel (:tnikkel)]

Is there a way to use this page without being a netflix member? Does saving a local copy work?

Comment 12

[Chris Peterson [:cpeterson]]

(In reply to Timothy Nikkel (:tnikkel) from comment #11)
> Is there a way to use this page without being a netflix member? Does saving
> a local copy work?

Unfortunately, the page doesn't work from a local copy. It loads a bunch of resources dynamically. However, Mozilla has a test account. I'll send you details in email.