Closed Bug 1300939 Opened 5 years ago Closed 3 years ago

Lodash documentation hangs for a second or three on load in layout code


(Core :: Layout, defect)

Not set



Tracking Status
firefox51 --- affected


(Reporter: bzbarsky, Unassigned)


(Blocks 2 open bugs, )



(4 files, 1 obsolete file)


I did some profiling and we're doing layout for a while on pageload, as far as I can tell.  Also as far as I can tell this depends somehow on both the fontawesome stylesheet being included _and_ on the flex styles being used.  Removing either one makes things much faster.

I expect that we're reflowing multiple times because of the flex thing; not sure why the fontawesome stuff comes in, but maybe something about its generated content stuff?

Daniel, do you have time to look into this?  I'll attach what I think is a self-contained version that shows the problem (and in particular doesn't have any of the scripts from the original page).
Flags: needinfo?(dholbert)
Attached file fontawesome css
Attached file main.css (obsolete) —
Attached file main.css
Attachment #8788712 - Attachment is obsolete: true
Attached file Testcase page
Note that Bugzilla is being really slow, at least for me, so you may need to download those locally and edit them to point to file:// URLs to get useful timings not affected by the server and network....
I've got a backlog of stuff I'm working through right now, but I'll try to take a look at some point next week. [leaving needinfo open]

With the currently attached testcase, I noticed that Chrome gives large measurements on the first load (in the 1800ms range) and then smaller measurements thereafter (in the 200ms range) -- and they show the alert before the page has rendered.

So I'm suspicious that they might be firing onload before the first render, which might not make the current testcase an effective measurement of time-to-finish-the-layout.

Here's a modified version with a more explicit layout flush before the alert.

Sorry for not circling back on this for a while!

Good news, though... It seems to have improved since this was filed.

Using the attached "testcase 2", here's the range of measurements I'm seeing from various browser versions (performing 3 attempts with each):

Nightly from 2016-09-01: 5680-6000
Nightly from today: 1100-1350
Chrome: 700-1000

And using the original page ( ), both Firefox and Chrome seem to react near-instantly when I change the documentation version in the dropdown now.

So I think this is largely WORKSFORME. Chrome is slightly faster, but not extremely perceptibly so, and not by an order of magnitude like before.

Flags: needinfo?(dholbert)

I'm closing out this bug since we've mostly closed the gap (per comment 8), and I filed bug 1523432 on the remaining small performance difference between us & chrome here.

Closed: 3 years ago
Resolution: --- → WORKSFORME

Thank you!

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