Open Bug 1349177 Opened 7 years ago Updated 1 year ago

Experiment with fonts loaded as unblocked resources

Categories

(Core :: Layout: Text and Fonts, enhancement, P5)

Product:
Core
Component:
Layout: Text and Fonts
Type:
enhancement

Tracking

()

Tracking Flags:
Tracking Status
firefox55 --- affected

People

(Reporter: mayhemer, Unassigned)

References

Details

Attachments

(1 file)

v1
1.80 KB, patch
Details | Diff | Splinter Review 
Chromium does that.
We need to find the spot(s) where loading channel for a font is created and set Leader class on it (nsIClassOfService) when the font is render-blocking (i.e. it's not for print or preload only, or so).
In practice, what does it mean for them to be made "head-blocking"?
(In reply to Jonathan Kew (:jfkthame) from comment #2)
> In practice, what does it mean for them to be made "head-blocking"?

it means they are loaded with the precedence we give to js and css from the <head> block (ahead of images and whatnot in <body>)
Priority: -- → P3
Moving to P2 since we may need to get this some evaluation on m-c,a,b.
Priority: P3 → P2
I actually find this a little surprising.  Images are often more critical than fonts to get the layout of the page "mostly right", although there's usually jitter when either of them load (although it is avoidable for many images).  Is there evidence that treating fonts as higher priority than images produces better user perception of speed or better usability?  (I might have guessed the opposite.)
when I last looked at this, admittedly a while ago, nothing was drawn without either the fonts or a big timeout (to avoid a big redraw) - they were a defacto blocker. is that not true anymore?
I base this on what Chrome is doing nearly a year.  There were also rumors we might want to do this in the past.  

The timeout to draw with a fallback font is pretty long.  My personal experience with Safari on iPhone on a very slow network (2G/3G) and google hosted fonts was not seeing any text for several seconds.

Not sure if lowering the timeout or putting fonts to the front of the queue would fix this.

The code change suggested here is IMO very simple, could be put under a pref relatively easily and could be tested in the wild for a time.
Thinking of this more, we might rather try to load the fonts as 'unblocked'.  It means to load them at the same time we are loading <head> css and js, but not let the rest of the sub-resources from <body> wait for the fonts to finish loading.

The overall goal is to shorten the time to the first non-blank paint.  Hence, turning this to only an experiment bug.  Loading fonts sooner may prolong the time to the first non-blank paint.
Summary: Load fonts as head-blocking resources → Experiment with fonts loaded as unblocked resources
Priority: P2 → P3
See Also: → 1390223
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED
Priority: P3 → P1
Attached patch v1 — — Splinter Review 
Tested only with 3 sites using fonts and I don't see much difference.  This doesn't break anything but also seems like it doesn't provide significant improvement.  Hence, rather leave it past the 57 point.
Priority: P1 → P4
Might end up WONTFIX (tho, worth some discussion/deeper analyzes first)
Assignee: honzab.moz → nobody
Status: ASSIGNED → NEW
Priority: P4 → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: