Re: [css-fonts] font prefetch hints

On Thu, Oct 30, 2014 at 3:07 PM, Tab Atkins Jr. <> wrote:
> On Thu, Oct 30, 2014 at 11:56 AM, Zack Weinberg <> wrote:
>> On Thu, Oct 30, 2014 at 2:22 PM, Tab Atkins Jr. <> wrote:
>>> On Thu, Oct 30, 2014 at 9:58 AM, Zack Weinberg <> wrote:
>>> @will-use {
>>>   .foo;
>>>   #bar;
>>> }
>> I can see where it's nice to have something more general than just for
>> fonts, but I'm concerned that this still requires you to parse the
>> entire stylesheet, construct the rule tree, and perform
>> potentially-nontrivial matches to decide which URLs to preload.
> Is that really significant?  The difference between "naively spot
> preloads during parsing" and "figure out preloads after stylesheets
> have loaded" is, at worst, a second or so. The use-case you presented
> was for things that aren't used on the current page, but that you'd
> like to get ready for later page loads.

That's not my use case at all.  My primary use case for 'will use' is
the body font that's going to be required for *this page*, which is
being loaded *right now*, the fonts may or may not already be cached,
and every millisecond we can shave counts.

By way of illustration, if I visit my own website
( in Chrome with a cold cache, there's a
~250ms delay in between load completion for the HTML and load
initiation for the style sheet (not sure what's up with that). The
style sheet is fully available 80ms after that.  Loads for resources
referenced within the style sheet don't kick off for another
100-150ms.  (Loads for images referenced directly from the HTML, by
contrast, fire immediately after the style sheet finishes.) Firefox
does better, initiating the stylesheet load within 10ms of load
completion for the HTML and image loads almost immediately after that
(*not* waiting for the style sheet) but it still doesn't begin to load
fonts until 200-250ms later.

>>>>  and 'false' means they SHOULD NOT.
>>> Is this necessary?  The default is already "should not", and I don't
>>> think anyone wants to change that.
>> I think I *do* want to change that, if that's really the current
>> spec-default.  Browsers should be allowed to apply clever
>> am-I-going-to-need-this heuristics if they want.
> Sure, but do we really need to call out "definitely don't preload
> this" as a case?  Do you believe that the heuristics will
> false-positive often enough to actually need this kind of control?

Yes.  Consider Wikipedia, again: potentially dozens of fonts only one
or two of which would actually be required on any given page.  A
heuristic of average cleverness might waste a lot of bandwidth
downloading fonts that are not yet known to be necessary.

>> ?? All the existing font-* descriptors parallel font-* properties in
>> style rules.  All the existing *non*-font-* descriptors (src:,
>> unicode-range:) *don't* parallel font-* properties.  That's a simple
>> bright line and we should stick to it.
> Oh, sure, that's true.  I'm confused about your request, then - the
> only other descriptor requested recently is font-rendering, which does
> have a parallel property proposed.

Oh, ok.  I think the "Per-selector font rendering strategy" section of
the proposal got added after I last read it.


Received on Thursday, 30 October 2014 19:39:31 UTC