1544951 - ECMAScript spec website takes several seconds to load

Status: RESOLVED FIXED

(Core :: Performance, defect)

Description

[Ted Campbell [:tcampbell]]

URL: https://tc39.github.io/ecma262/
Profile: https://perfht.ml/2ZflRY5

In Firefox, we get a white page for several seconds until network is done and profile shows a lot of time in layout. Comparatively in Chrome, we get a real paint almost immediately while the page continues to load.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The bot thinks this bug is a task, but please change it back in case of error.

Comment 2

[Ted Campbell [:tcampbell]]

This is probably Bug 1552719 (which is has patches up)

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Does this happen on release? If it's only on Nightly it's plausible, but otherwise it seems unlikely. Also, I see no nsBulletFrame::Ordinal at all in your profile.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

If it is a regression from bug 288704 I'd be interested in knowing, since I can think of a couple extra optimizations.

Comment 5

[Ted Campbell [:tcampbell]]

Good point. I had seen nsBulletFrame in the profile (and BulletFrame go by on IRC), but it is BulletFrame::GetMiniSize instead of Ordinal.

I tried to get a regression range and it seems like you are right about Bug 288704.

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5dc0652cd024fef30217ac3e6087b7a32f16967f&tochange=7ed792328e9fc95b95fbdcc879f5c0562296004e

The 'good' revs took about 3s to load as measured by network tab of devtools, and the 'bad' took about 6s.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Proposed optimization is to reflow the bullet only if the counter-style depends on the ordinal:

m = {}; for (const style of Array.from(document.querySelectorAll("li")).map(li => getComputedStyle(li).listStyleType)) { m[style] = (m[style] || 0) + 1; }

says:

circle: 59
decimal: 7698
disc: 1175
"lower-alpha": 1963
"lower-roman": 782
none: 2495
square: 13

But actually chances are that my patch actually helps here after all, since 95% of the time is spent in nsBulletFrame::GetDesiredSize and most of it is self-time, so I suspect nsBulletFrame::Ordinal is getting inlined. Will check tomorrow.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Can you confirm that a build from https://treeherder.mozilla.org/#/jobs?repo=autoland&fromchange=60bf0ae446ce30b797a928d8f7961aadb00662b4 (which has my patch) is "good" again? I took a profile and it seems the nsBulletFrame time is mostly gone.

Comment 8

[Ted Campbell [:tcampbell]]

Confirmed that [1] on autoland now falls into the 'fast' bucket. I will look again tomorrow at the subjective experience vs chrome (which paints really fast, but profile is still quite busy).

[1] https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=f023603f7e7265c5602fb6e9c871b19a3c7f3a92

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Ok, I'll hold off on marking this as a dupe for now then. I'll land the bullet optimizations somewhere else :-)

Comment 10

[Ted Campbell [:tcampbell]]

The current nightly with Emilio's fixes shows makes this much faster. Chrome still gets first paint slightly faster, but our complete load is about a 1/3 of the time for chrome (like 4 seconds faster for me). I'll close this bug as resolved since the major user-perceived issue is gone.