ECMAScript spec website takes several seconds to load
Categories
(Core :: Performance, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox67 | --- | unaffected |
firefox68 | --- | fixed |
firefox69 | --- | fixed |
People
(Reporter: tcampbell, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
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•5 years ago
|
||
The bot thinks this bug is a task, but please change it back in case of error.
Updated•5 years ago
|
Reporter | ||
Comment 2•5 years ago
|
||
This is probably Bug 1552719 (which is has patches up)
Assignee | ||
Comment 3•5 years ago
|
||
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.
Assignee | ||
Comment 4•5 years ago
|
||
If it is a regression from bug 288704 I'd be interested in knowing, since I can think of a couple extra optimizations.
Reporter | ||
Comment 5•5 years ago
|
||
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.
The 'good' revs took about 3s to load as measured by network tab of devtools, and the 'bad' took about 6s.
Assignee | ||
Comment 6•5 years ago
|
||
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.
Assignee | ||
Comment 7•5 years ago
|
||
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.
Reporter | ||
Comment 8•5 years ago
|
||
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).
Assignee | ||
Comment 9•5 years ago
|
||
Ok, I'll hold off on marking this as a dupe for now then. I'll land the bullet optimizations somewhere else :-)
Updated•5 years ago
|
Reporter | ||
Comment 10•5 years ago
|
||
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.
Updated•5 years ago
|
Updated•2 years ago
|
Description
•