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

Status: RESOLVED WORKSFORME

(Core :: Performance, enhancement, P2)

Description

[Denis Palmeiro [:denispal]]

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.

Comment 1

[Kannan Vijayan [:djvj]]

Fresh profile captured on nighly without devtools loaded: https://perfht.ml/2PNx1xE

Comment 2

[:Harald Kirschner :digitarald]

Profile with screenshots and JIT optimizations tracked from OSX: https://perfht.ml/2xuvea5

Comment 3

[Will Hawkins]

(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.

Comment 4

[Will Hawkins]

(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.

Comment 5

[Denis Palmeiro [:denispal]]

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.

Comment 6

[Will Hawkins]

(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.

Comment 7

[Will Hawkins]

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.

Comment 8

[Kannan Vijayan [:djvj]]

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.

Comment 9

[Mike Conley (:mconley) (:⚙️)]

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

Comment 10

[Ajay Gupta]

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

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

I can't reproduce in Europe. Chrome is ~4800ms and Nightly (without tracking protection) ~4400ms