Below are the browsertime results for Gmail login page.

Chrome 78
[2019-11-18 12:13:07] INFO: https://mail.google.com/mail/u/0/\#inbox 0, backEndTime: 185ms (±6.57ms), firstPaint: 629ms (±21.85ms), firstVisualChange: 267ms (±11.80ms), DOMContentLoaded: 772ms (±21.67ms), Load: 1.12s (±17.72ms), speedIndex: 673 (±35.14), perceptualSpeedIndex: 456 (±15.47), contentfulSpeedIndex: 373 (±21.11), visualComplete85: 962ms (±31.40ms), lastVisualChange: 971ms (±26.60ms), rumSpeedIndex: 629 (±21.85) (8 runs)

Firefox Nightly (UA overrides to "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36")

[2019-11-18 13:24:22] INFO: https://mail.google.com/mail/u/0/\#inbox 0, backEndTime: 298ms (±11.88ms), firstPaint: 722ms (±22.52ms), firstVisualChange: 765ms (±22.84ms), DOMContentLoaded: 741ms (±22.11ms), Load: 815ms (±24.42ms), speedIndex: 865 (±18.21), perceptualSpeedIndex: 779 (±22.96), contentfulSpeedIndex: 936 (±29.61), visualComplete85: 1.09s (±41.19ms), lastVisualChange: 8.86s (±232.48ms), rumSpeedIndex: 298 (±11.83) (8 runs)

The latest visual metrics shows Chrome is better than us at pretty much everything. Chrome is significant better than us at firstVsiualChange, perceptualSpeedIndex, contentfulSpeedIndex and lastVisualChange.

Profile : http://bit.ly/2KAeUer

We spent about 80ms in JSScript* CompileSourceBuffer, this feels a lot of time to me, especially at the beginning of a pageload.

Hi Sean- - it looks like your profile is missing sample data for a good chunk of the pageload. (here's a zoomed in view: https://perfht.ml/35mXSby )

Could you capture a new profile (and maybe give the profiler a few seconds of head-start to start capturing samples, in the hopes of avoiding this issue)?

Sorry for the late reply Daniel, updated profile https://perfht.ml/36ipYVZ

The differences are also noticeable by looking at the video

Below are the visual metrics for the video. FirstVisualChange might be something that can be ignored because video shows that Chrome painted a blank grey page very early before painting anything else, however we were still slower than Chrome to paint the actual page content.

Chrome: backEndTime: 261ms, firstPaint: 599ms, firstVisualChange: 334ms, DOMContentLoaded: 679ms, Load: 1.03s, speedIndex: 978, perceptualSpeedIndex: 511, contentfulSpeedIndex: 863, visualComplete85: 834ms, lastVisualChange: 11.20s, rumSpeedIndex: 599

Firefox: backEndTime: 572ms, firstPaint: 978ms, firstVisualChange: 1s, DOMContentLoaded: 988ms, Load: 1.28s, speedIndex: 1116, perceptualSpeedIndex: 1018, contentfulSpeedIndex: 1863, visualComplete85: 1.32s, lastVisualChange: 9.64s, rumSpeedIndex: 57

Seeing a 61ms spent in nsresult nsJSUtils::ExecutionContext::InternalCompile https://perfht.ml/2RBsLFy from the above profile.
Kannan, do you think this is normal?

@sefeng - looking at it in isolation, there's nothing that stands out as abnormal. The stack trace seems to indicate a full-parse (generating bytecode) for some underlying script. 61ms is not an undue amount of time for a full parse, compile-to-bytecode, environment creation, etc.

Here is a more recent profile for loading gmail's login screen: https://share.firefox.dev/3xmBHBn

I disabled http cache and ublock origin before capturing the profile (but didn't change the UA). Please tell me if there's anything useful.

At a first glance, I mostly see a lot of javascript...

It seems like we run quite a bit JS before the relevant paint, and it is taking more time than in Chrome.

For once this isn't React code. The hot spot here seems to be delazification; depending on which janky segments I look at, we're spending between 10-40% of our time delazifying.

For what is worth, with Stencil we would be looking at handling delazification off-main-thread, as part of Bug 1662110.
As nobody is actively working on this bug, this should probably be a P2, and P1 is reserved for assigned bugs.

The Performance Priority Calculator has determined this bug's performance priority to be P1.

Platforms: [x] Windows [x] macOS [x] Linux
Page load impact: Some
[x] Affects major website

This bug was filed based on performance metrics that we gathered 3 years ago.

sefeng, maybe it'd be worth updating your measurements here, given that this bug report is resurfacing/getting-attention per comment 9?

Sean, can a new profile be collected to determine if this is still an issue?

In AWFY (Win) Google Mail gets very similar numbers in FF and Chrome (cold recorded page load). In cold live, FF is better.
Warm loads look good too.
Are we not getting reasonable numbers in AWFY, or is the behavior rather good.
(Some of the scheduling changes did affect gmail quite a bit, but can't recall which one. It was long ago.)

(In reply to Olli Pettay [:smaug] from comment #12)

In AWFY (Win) Google Mail gets very similar numbers in FF and Chrome (cold recorded page load). In cold live, FF is better.
Warm loads look good too.
Are we not getting reasonable numbers in AWFY, or is the behavior rather good.
(Some of the scheduling changes did affect gmail quite a bit, but can't recall which one. It was long ago.)

Based on this comment, is this still an issue?

Jan do you have any thoughts to Frank's question?

I think we can close this. If there are other issues please file a new bug.

A lot has improved over the past years, especially Warp/TI-removal and Stencil work have been good for page load performance.