962735 - Slow pageload bits on HTML5 spec due to downloadable fonts

Status: NEW

(Core :: Layout: Text and Fonts, defect)

Description

[Boris Zbarsky [:bzbarsky]]

I was profiling the pageload for http://www.whatwg.org/specs/web-apps/current-work/ a bit, and here's what I'm seeing in my profile:

  11% (400ms) is RebuildAllStyleData off a refresh driver tick.
  82% (2700ms) is reflow from the flush before we fire onload.

the latter is clearly triggered by downloadable fonts; otherwise we just flush style but not layout at that point.  The former is presumably also triggered by downloadable fonts...

We should probably file bugs blocking this one on whatever ideas we have for making these better.  The one though I've had so far is that instead of doing a noninterruptible layout flush there we could do an interruptible one, and if it's interrupted don't fire onload until we manage to complete a layout pass.  Does that seem reasonable?

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, that would be OK.

However it looks to me like that font is only used in one place in the document. So an approach which would work here to fire the load event earlier is to provide a way to trigger textrun construction just for elements with downloadable fonts and not do a full reflow of the document. Or do even less work and just do font selection. Or we could just eagerly load fonts!

I mean, in this case, we have an element with "font-family:Essays1743". We might as well eagerly load a font that's first in the family name list, since it seems unlikely it won't be used for any of the text in the element. In this case there are four variants (bold, italic, bold-italic) but we can determine just from the style data which variants should be eagerly loaded and which will definitely not be needed. There is no need to do any font selection to figure out which fonts to load. We can keep track of how many fonts we haven't started loading but might be needed, and only force font selection or reflow if the load event is ready to fire and that number is nonzero. In this testcase that number is always zero.