Open Bug 1492667 Opened 4 years ago Updated 2 months ago

Investigate long load time of https://www.wsj.com

Categories

(Core :: Performance, enhancement, P2)

62 Branch
enhancement

Tracking

()

Tracking Status
firefox64 --- affected

People

(Reporter: denispal, Unassigned, NeedInfo)

Details

Loading https://www.wsj.com/ is around 3-4x longer than Chrome.  For firefox, I see around 6-8s to reach the load event.  On Chrome, this is consistently 2s.  

You can measure this by opening up devtools, switching to the network tab and clicking "disable cache". On each page load the load event time should be shown in the network panel.  

Profile:  https://perfht.ml/2MNFqiH

I'm putting it under JS for now because I see a lot of bailouts (1.4s-2.0s) and a number of fallbacks (between 2.4-2.6s).  Also see about a large amount of time calling free at 1.4s-2.0s.
Version: Trunk → 62 Branch
Fresh profile captured on nighly without devtools loaded: https://perfht.ml/2PNx1xE
Profile with screenshots and JIT optimizations tracked from OSX: https://perfht.ml/2xuvea5
Component: JavaScript Engine → Performance
Priority: -- → P1

(In reply to Denis Palmeiro [:denispal] from comment #0)

Loading https://www.wsj.com/ is around 3-4x longer than Chrome. For
firefox, I see around 6-8s to reach the load event. On Chrome, this is
consistently 2s.

I am testing this on FF nightly vs Chrome (on Ubuntu, standard .deb installation) and just reran denispal's tests.

For FF nightly, the load event takes 14.10s. For Chrome, the event takes 3.35s. Seems like this is still a problem?

You can measure this by opening up devtools, switching to the network tab
and clicking "disable cache". On each page load the load event time should
be shown in the network panel.

Profile: https://perfht.ml/2MNFqiH

I'm putting it under JS for now because I see a lot of bailouts (1.4s-2.0s)
and a number of fallbacks (between 2.4-2.6s). Also see about a large amount
of time calling free at 1.4s-2.0s.

(In reply to Will Hawkins from comment #3)

(In reply to Denis Palmeiro [:denispal] from comment #0)

Loading https://www.wsj.com/ is around 3-4x longer than Chrome. For
firefox, I see around 6-8s to reach the load event. On Chrome, this is
consistently 2s.

I am testing this on FF nightly vs Chrome (on Ubuntu, standard .deb installation) and just reran denispal's tests.

For FF nightly, the load event takes 14.10s. For Chrome, the event takes 3.35s. Seems like this is still a problem?

These numbers were gathered with developer tools open on both browsers. According to :denispal, that is not the best way to capture statistics.

Here's how I am now capturing statistics:

In FF:

  1. Set about:config to turn off memory and disk cache
  2. Load the page.
  3. Open web console and print
    window.performance.timing.loadEventEnd-window.performance.timing.navigationStart

In Chrome,

  1. Open browser with
    ./google-chrome-stable --disk-cache-size=1 --media-cache-size=1 --disable-application-cache
  2. Load the page
  3. Open the developer tools and print
    window.performance.timing.loadEventEnd-window.performance.timing.navigationStart

Just want to double check that this is reasonable. I would also like to experiment with writing a "test" that will automate this process so I can gather averages to decrease the noise.

Are the steps for both browsers reasonable?

You can measure this by opening up devtools, switching to the network tab
and clicking "disable cache". On each page load the load event time should
be shown in the network panel.

Profile: https://perfht.ml/2MNFqiH

I'm putting it under JS for now because I see a lot of bailouts (1.4s-2.0s)
and a number of fallbacks (between 2.4-2.6s). Also see about a large amount
of time calling free at 1.4s-2.0s.

Flags: needinfo?(dpalmeiro)

Looks reasonable to me! If you want to automate the process, I would look into some 3rd party tools like browsertime so you don't need to reinvent the wheel.

Flags: needinfo?(dpalmeiro)

(In reply to Will Hawkins from comment #4)

(In reply to Will Hawkins from comment #3)

(In reply to Denis Palmeiro [:denispal] from comment #0)

Loading https://www.wsj.com/ is around 3-4x longer than Chrome. For
firefox, I see around 6-8s to reach the load event. On Chrome, this is
consistently 2s.

I am testing this on FF nightly vs Chrome (on Ubuntu, standard .deb installation) and just reran denispal's tests.

For FF nightly, the load event takes 14.10s. For Chrome, the event takes 3.35s. Seems like this is still a problem?

These numbers were gathered with developer tools open on both browsers. According to :denispal, that is not the best way to capture statistics.

Here's how I am now capturing statistics:

In FF:

  1. Set about:config to turn off memory and disk cache
  2. Load the page.
  3. Open web console and print
    window.performance.timing.loadEventEnd-window.performance.timing.navigationStart

Results with FF nightly:
window.performance.timing.loadEventEnd-window.performance.timing.navigationStart
4981

window.performance.timing.loadEventEnd-window.performance.timing.navigationStart
5276

window.performance.timing.loadEventEnd-window.performance.timing.navigationStart
5082

In Chrome,

  1. Open browser with
    ./google-chrome-stable --disk-cache-size=1 --media-cache-size=1 --disable-application-cache
  2. Load the page
  3. Open the developer tools and print
    window.performance.timing.loadEventEnd-window.performance.timing.navigationStart

Results with latest Ubuntu release:

window.performance.timing.loadEventEnd-window.performance.timing.navigationStart
2522

window.performance.timing.loadEventEnd-window.performance.timing.navigationStart
4385

window.performance.timing.loadEventEnd-window.performance.timing.navigationStart
2512

These numbers look much more reasonable than the original numbers before jesup's work. I have looked into profiles of Chrome and FF loading this site and they both seem very similar (although I have very naive eyes at this point!). If someone wanted to pair debug with me, that'd be great. I can also automate tests on both browsers to get some numbers that are less noisy. Otherwise, it seems like there might no longer be a problem here.

Will

Just want to double check that this is reasonable. I would also like to experiment with writing a "test" that will automate this process so I can gather averages to decrease the noise.

Are the steps for both browsers reasonable?

You can measure this by opening up devtools, switching to the network tab
and clicking "disable cache". On each page load the load event time should
be shown in the network panel.

Profile: https://perfht.ml/2MNFqiH

I'm putting it under JS for now because I see a lot of bailouts (1.4s-2.0s)
and a number of fallbacks (between 2.4-2.6s). Also see about a large amount
of time calling free at 1.4s-2.0s.

Flags: needinfo?(dpalmeiro)

Just FYI: This is not resolved as I previous suggested. I have narrowed down the problem to the first load of wsj.com with a new profile. Once the user has visited the page at least once, the page loads in approximately the same amount of time as Chrome.

Priority: P1 → P2
Summary: Long load time of https://www.wsj.com → Investigate long load time of https://www.wsj.com

Will - just want you to be aware that when measuring load-event related metrics, that we tend to schedule and execute more JS on average before load-event is emitted, compared to Chrome. Olli (smaug)'s work on scheduling should be of relevant interest here.

Flags: needinfo?(dpalmeiro)

This bug appears to have stalled out, but also Firefox performance has changed a lot in 7 months. Is this still reproducible?

Flags: needinfo?(dpalmeiro)

This website shows no content on Nightly (72.0a1 build 20191030050308). NIghtly is running with all add-ons disabled.

Assignee: nobody → whawkins
Assignee: whawkins → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.