Open Bug 1507868 Opened 6 years ago Updated 7 months ago

[meta] Gmail is slow to initialize (slow to load emails)

Categories

(Core :: Performance, defect, P2)

Product:
Core
Component:
Performance
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox65 --- affected

People

(Reporter: aosmond, Unassigned)

References

Details

(Keywords: meta)

Attachments

(1 file)

Screenshot 2024-02-27 130749.png
205.82 KB, image/png
Details
The loading time of the new gmail is several seconds for me. It displayed the progress bar for several seconds before finishing the load and bringing me to the actual emails. https://perfht.ml/2TjS51i Chrome is almost imperceptible in comparison. Both attempts were after a fresh restart of the browser (no update applied).
Profile looks like it's running a lot of JS from gmail. Kannan/Bas, thoughts?
Flags: needinfo?(kvijayan)
Flags: needinfo?(bas)
Whiteboard: [qf:p1:pageload]
Priority: -- → P1
The first 1.5s jank in the profile deconstructs almost entirely into: interpreter and baseline compilation. I can manually attribute about 50% (by sample volume) of the top leaf nodes to either compiler-related activity (stub compilation, script compilation, baseline compiler, memprotect, memcopy, etc.), or interpreter/slowpath stuff (shape lookups, some parsing, property lookups of various sorts, etc.) The second big 1.5s jank has some contribution from DOM and Reflow activity, but the bulk of it is still JS execution. Here, the inverse profile tree is not dominated by any one thing: there is some interpreter execution, some baseline JIT compilation, quite a bit of Ion compilation, some IC stub compilation, some parsing, etc. There's likely no single problem with the JS execution here - rather an array of things to be tightened up. Interpreter speedups would help on that side. Parser improvements (integration of utf8 parsing) will help somewhat. Compiler tuning - mostly to make Ion compilation more lightweight would also help reduce the load. Other than that, we should also ensure that we are getting the same JS as Chrome is. Andrew, are you using spoofed UA to request this?
Flags: needinfo?(kvijayan) → needinfo?(aosmond)

Profile with UA set to Chrome https://perfht.ml/2IjkXFo

I was running Ubuntu 18.10 and it was indeed that Chrome was faster.

Is this any better using today's Nightly?

Chrome (Version 76.0.3809.62 (Official Build) beta (64-bit))
[2019-07-11 10:22:34] INFO: https://mail.google.com/mail/u/0/#inbox 0, backEndTime: 326ms (±7.77ms), firstPaint: 403ms (±7.45ms), firstVisualChange: 63ms (±3.13ms), DOMContentLoaded: 1.88s (±26.99ms), Load: 3.86s (±100.99ms), speedIndex: 2440 (±24.39), perceptualSpeedIndex: 821 (±9.42), contentfulSpeedIndex: 2174 (±26.54), visualComplete85: 2.68s (±31.00ms), lastVisualChange: 3.71s (±44.95ms), rumSpeedIndex: 682 (±7.35) (10 runs)

Firefox Nightly
[2019-07-11 10:29:28] INFO: https://mail.google.com/mail/u/0/#inbox 0, backEndTime: 308ms (±6.79ms), firstPaint: 369ms (±26.39ms), firstVisualChange: 40ms (±0.00ms), DOMContentLoaded: 915ms (±43.61ms), Load: 1.12s (±231.23ms), speedIndex: 2326 (±52.37), perceptualSpeedIndex: 1310 (±31.87), contentfulSpeedIndex: 2281 (±55.68), visualComplete85: 2.83s (±71.12ms), lastVisualChange: 5.46s (±105.10ms), rumSpeedIndex: 597 (±11.81) (10 runs)

I used browsertime to do a comparison between us and Chrome, we are better at firstVisualChange, speedIndex, DOMContentLoaded, Load and rumSpeedIndex. We are worse at perceptualSpeedIndex, contentfulSpeedIndex (very close to Chrome), visualComplete85 (very close to Chrome), lastVisualChange. Overall, I think we are much better than before.

Hi Andrew,
Would you mind taking another look at this to see if you still have the same issue? (from comment 7, it sounds like we've made improvements since you opened this 9 months ago, I just want to verify whether we can close this).

Thanks!

sean - can you get some visual metrics runs on this so we can see where we are? Thanks

Flags: needinfo?(sefeng)

Check comment 12 please, this comment is irrelevant to this bug.

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 : https://perfht.ml/37g7Qxl

I still see we spent about 80ms in JSScript* CompileSourceBuffer, this feels a lot of time to me, especially at the beginning of a pageload. I think Kannan's original analysis is still valid.

Flags: needinfo?(sefeng)

https://perfht.ml/37g7Qxl won't open for me....

Flags: needinfo?(sefeng)

Republished....try http://bit.ly/2KAeUer ?

Flags: needinfo?(sefeng)

I just found something wrong I did in comment 10. The runs didn't login to Gmail, so the measurement was about loading the login page, not listing all emails.

Update test results.

Chrome 78:
[2019-11-18 16:22:42] INFO: https://mail.google.com/mail/u/0/#inbox 0, backEndTime: 375ms (±9.90ms), firstPaint: 506ms (±10.85ms), firstVisualChange: 46ms (±5.76ms), DOMContentLoaded: 3.08s (±132.49ms), Load: 5.84s (±172.52ms), speedIndex: 3041 (±101.77), perceptualSpeedIndex: 1088 (±40.71), contentfulSpeedIndex: 2951 (±114.79), visualComplete85: 3.56s (±142.25ms), lastVisualChange: 5.17s (±178.92ms), rumSpeedIndex: 941 (±26.95) (8 runs)

Firefox Nightly:
[2019-11-18 16:14:49] INFO: https://mail.google.com/mail/u/0/#inbox 0, backEndTime: 349ms (±7.01ms), firstPaint: 447ms (±30.61ms), firstVisualChange: 85ms (±20.54ms), DOMContentLoaded: 904ms (±27.96ms), Load: 904ms (±27.92ms), speedIndex: 2609 (±31.70), perceptualSpeedIndex: 1603 (±33.71), contentfulSpeedIndex: 2741 (±40.15), visualComplete85: 3.06s (±42.43ms), lastVisualChange: 6.32s (±217.42ms), rumSpeedIndex: 681 (±9.31) (8 runs)

Chrome beats us at firstVisualChange, perceptualSpeedIndex and lastVisualChange.

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

Summary: Gmail is slow to initialize → Gmail is slow to initialize (slow to load emails)

(Created Bug 1597522 for the login page issue)

Priority: P1 → P2

Making this a meta to track future gmail issues.

Keywords: meta
Summary: Gmail is slow to initialize (slow to load emails) → [meta] Gmail is slow to initialize (slow to load emails)
Depends on: 1597522
Flags: needinfo?(aosmond)
Whiteboard: [qf:p1:pageload]

I can't repro this myself.

Flags: needinfo?(bas)
Severity: normal → S3

it now loads emails faster than before

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: