1363399 - (BackButton_Amazon) Amazon back start: page navigation using back button is slow (dupe?)

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Filip Andrei]

Name: Firefox
Version: 55.0a1
Windows 10 64 bit
buildID: 20170508030204

Steps to reproduce:
1. Launch browser.
2. Fill amazon.com in Navigation Start, then press enter.
3. Search "Lord of the rings"
4. Scroll down and access a non add results
5. Play  movie Trailer
6. Record with Gecko Profile:
7. Click back button
8. Capture profile.
9. Share the profile.

Gecko profile:
https://perfht.ml/2pZSnyc

Comment 1

[Ionut Budeanu]

This Profile was recorded with the Acer hardware.

Name: Firefox
Version: 55.0a1
Windows 10 64 bit
buildID: 20170518030213


Steps to reproduce:
1. Launch browser.
2. Fill amazon.com in Navigation Start, then press enter.
3. Search "Lord of the rings"
4. Scroll down and access a non add results
5. Play  movie Trailer
6. Record with Gecko Profile:
7. Click back button
8. Capture profile.
9. Share the profile.

Gecko profile: https://perfht.ml/2q0vxDP

Comment 2

[Chris Peterson [:cpeterson]]

Dear profile-analyzing engineer:

These profiles are from the same STR as bug 1362625. Please double check whether these profiles show any new hot spots that weren't seen in bug 1362625. If not, we can resolve this bug as a duplicate of bug 1362625.

Comment 3

[Jean Gong :jgong]

Jeff,  Please read comment 2 before you start analyzing the profiles from comment 1.  Thanks!

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Here are my findings:
- Bit of Layout thrashing from Amazon scripts when loading the search result page out of network (we appear to be skipping bfcache for some reason), blocking initial paint of the search result page when going back
- Also note the beforeunload running in the Lord of the Rings page with the trailer that’s spending time trying to shut down the video for some reason
- A bunch of timers are firing immediately after painting the search result page, which is blocking interactivity.
Things that are within our power to fix:
- We could attempt to space out those timer runnables more and service user input events with higher priority? Quantum DOM work will help with this, actually. Input events are Tier 1!
- Our Web Compat team could reach out about the beforeunload and using requestIdleCallback instead of setTimeout
- Reflow markers in perf.html are suspect
  - Filed https://github.com/devtools-html/perf.html/issues/426

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

Probably need to file bugs for the suggestions at the end of comment 4 for DOM and webcompat.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

It's worth noting that the bulk of the time in this profile is either in style or reflow so I'm moving it to layout.

Comment 7

[Chris Peterson [:cpeterson]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #4)
> Here are my findings:
> - Bit of Layout thrashing from Amazon scripts when loading the search result
> page out of network (we appear to be skipping bfcache for some reason),
> blocking initial paint of the search result page when going back
> - Also note the beforeunload running in the Lord of the Rings page with the
> trailer that’s spending time trying to shut down the video for some reason
> - A bunch of timers are firing immediately after painting the search result
> page, which is blocking interactivity.
...
> - Our Web Compat team could reach out about the beforeunload and using
> requestIdleCallback instead of setTimeout

Mike, Jeff has identified some perf problems on amazon.com that Amazon may be able to avoid in their code. How would you like to track reaching out to Amazon?

Comment 8

[Mike Taylor [:miketaylr]]

Hey Chris, normally I'd ask Adam to handle that. But he's on PTO this week. If it's not urgent, we can wait, otherwise I'm happy to start conversations.

Comment 9

[Mike Taylor [:miketaylr]]

Given this is QF related... waiting a week doesn't seem great. ni? myself to start a thread on our ML.

Comment 11

[Mike Taylor [:miketaylr]]

Sent a message on our partner mailing list today.

Comment 12

[Ben Kelly [:bkelly, not reviewing]]

> We could attempt to space out those timer runnables more and service user input events with higher priority?

We already force yielding between setTimeout() callbacks.  In FF54 and earlier the yield is forced after 5 callbacks are allowed to run consecutively.  In FF55+ we allow consecutive callbacks to run for up to 4ms and then force a yield after that.

Note, the 4ms yield threshold landed in bug 1343912 2 days after comment 1 profile was taken.  We may want to re-profile if that is significant here.

Also note, Quantum DOM will not really help here.  That is more about separating out different windows within the same process instead of relative priorities of different runnables within a single window.

Comment 13

[Bobby Chien]

[qf] per comment 9.

Comment 14

[Wayne Mery (:wsmwk)]

No slowness here - macbook pro + FIrefox 98.0b6

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to Wayne Mery (:wsmwk) from comment #14)

No slowness here - macbook pro + FIrefox 98.0b6

Yeah, me either (ThinkPad laptop, Linux, Firefox Nightly 99).

Likely a lot has changed on Amazon's end -- as well as our end -- in the 5 years since this bug was filed. (And it looks like this bug and its dupes weren't for a specific issue -- note we don't have expected-results/actual-results in comment 0 -- but more as part of a "fishing for perf bugs" kind of approach, where we had some sites that were identified as priorities, where we were capturing performance profiles and seeing what we could find that was taking-up-time in those profiles & might be avoidable. Given that, it's hard to say what the issues were here, or whether they are "fixed".)

In any case: if anyone does see issues here where we're slower than the competition, let's track that in a new bug, ideally with a clear description of the issues and an up-do-date profile.