Re: [css-fonts] font prefetch hints

On Thu, Oct 30, 2014 at 12:39 PM, Zack Weinberg <zackw@panix.com> wrote:
> On Thu, Oct 30, 2014 at 3:07 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Thu, Oct 30, 2014 at 11:56 AM, Zack Weinberg <zackw@panix.com> wrote:
>>> On Thu, Oct 30, 2014 at 2:22 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>>> On Thu, Oct 30, 2014 at 9:58 AM, Zack Weinberg <zackw@panix.com> 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
> (https://www.owlfolio.org/) 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.

Okay, that was unclear from your first email.  Kicking off loads asap
is reasonable.  It has different requirements that drive syntax than
the thing I suggested; you really want the URL immediately.

Hmm.  So, some types of resources don't carry their context with them,
like images; you'll need to specify the type alongside the url.  These
tend to be simple, as well.  Other resources, like fonts, have more
complex semantics (with formats and fallback, for example), but they
come with a context: in the case of fonts, the @font-face rule itself.
That's why, in your original font-focused suggestion, you had it as a
@font-face descriptor, so that the hint and the URL are both known
roughly at the same moment.

Maybe a @preload rule (name pending) that can contain (a) lists of
explicit contexts with urls, and (b) any resource-using at-rules, like
@font-face.  Example:

@preload {
  images: url(foo), url(bar);
  @font-face {
    ...
  }
}

If we need to provide some knobs to twiddle about preload policy, we
can add those as more descriptors on the @preload rule.

>>>>>  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.

I'm a little unsure about this - it means that pages that dont't want
to waste bandwidth have to use preload hints on *every* large
resource, to ensure that it's either preloaded or not.  I'd rather
browsers stick with conservative heuristics, so that pages only have
to worry about using preload hints on a small number of critical
resources.

~TJ

Received on Thursday, 30 October 2014 21:36:34 UTC