Re: [css-fonts] font prefetch hints

Yoav Weiss wrote:

> Fair enough. I agree that there are cases where an opt-in would be
> required. So, as you suggest, we could have an opt-in signal for
> "guarantied" preloading, and do our best effort to figure out if a
> preload is needed in its absence.

I think you need to keep in mind that fonts are matched via styles
*and* content. The intersection of the cmap of a font with the set
of characters used in a document is what ultimately determines
whether a font is downloaded *and* used. The CSS Fonts spec contains
very specific rules about when fonts are loaded with the intent of
making it so that user agents *don't* simply greedily load any font
they find, as old versions of IE would always do with EOT fonts. So
whatever preloading you're using *without* explicit hints needs to
follow those rules.

In practice, I think this would boil down to using common sense.
Don't load a font that's never referenced in a font-family list for
a given page. But if a font is the first font in a fontlist for an
element that contains visible text, preloading would make sense
(*if* the unicode-range descriptor is not explicitly defined). Not
sure how much bang you'd get, since you basically already would be
pretty close to the point at which actual font matching takes place,
but in some situations it might make a difference.

Requirements for determining font loads:

  1. set of fonts (i.e. @font-face rules)
  2. resolution of font properties (map family name ==> face)
  3. textual content of an element

I would be happy to be proved wrong but I'm skeptical that
optimizations to guess which fonts to preload without preload hints
would buy much performance wise since you'd need to almost be at the
layout stage anyways to determine which loads to start.

All of which is a verbose way of saying "prefetch hints" are creamy goodness. :)

Cheers,

John Daggett
Mozilla Japan

Received on Friday, 14 November 2014 01:19:41 UTC