Panos Astithas (he/him) [:past] (please ni?) Reporter
	Description • 6 years ago

Our partners at Wikimedia discovered that past a certain threshold of image weight on their page (around 1MB), Firefox starts displaying significant randomness in its effective visual progress performance.

When driven by WebPageTest or Browsertime, they see that metrics like "start render" on such web pages vary by as much as 900ms from one run to the next under the same networking conditions:

https://phabricator.wikimedia.org/T190926#4107746

Chrome doesn't display that behavior and has consistent stability on those metrics between runs regardless of the amount and weight of images on the page.

According to the HTTP archive, having that much image weight on pages isn't that unusual: https://httparchive.org/reports/state-of-images

Ben Kelly profiled the roman empire url from the phabricator issue.  On a ctrl-shift-r he got:

https://perfht.ml/2qf5aLU

He said: "AFAICT, we are spending 800ms doing a sync reflow during load because of a MouseMoveEvent.  I don't see a js handler in the stack, though, so I think this is gecko internally triggering the reflow."

	Xidorn Quan [:xidorn] UTC+11
	Comment 1 • 6 years ago

Is that 800ms reflow something happens only sometimes, or does it happen consistently, but just triggered at different point which causes the variance in rendering time? I don't see how that is related to images anyway.

It seems to me the majority of time is spent in reflowing column set frame probably because of the long reference list. I guess given its length it probably shouldn't take that long, but I have no idea.

	Daniel Holbert [:dholbert]
	Comment 2 • 6 years ago

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #1)
> It seems to me the majority of time is spent in reflowing column set frame
> probably because of the long reference list.

This is bug 575614, BTW.  Really, I'm guessing this is all a version of bug 575614, but I'll leave this open in case there's any hackarounds we can come up with.

(I would guess that maybe the "image weight" connection is simply that with more images, it becomes harder to coalesce image-size-available-triggered incremental reflows together (because they're more numerous / spread out over time), and so we end up reflowing more times.  And in light of bug 575614, those reflows can be expensive when there's a long multicol at the bottom of the page, as there is in some wikipedia pages)

	Daniel Holbert [:dholbert]
	Comment 3 • 6 years ago

FWIW, the Roman Empire url (the one from comment 0's profile) is:
  https://en.wikipedia.org/wiki/Roman_Empire

It has 660 citations followed by ~60 Cited sources (in 2 separate multicol elements)