Re: [css-fonts] font prefetch hints

I really like where this discussion is heading... and I would like to push
it towards a generic solution for any CSS-initiated fetches:
- I have a font resource that shouldn't wait for layout; I know I'll need
it on this page.
- I have a background image that shouldn't wait for layout; it's my hero
image and I need it asap.
- content type doesn't matter, it's all the same problem... don't wait for
layout to initiate the fetch.

Ideally, I'd like to see two things:
1) ability to opt-out a particular resource from lazyload behavior (aka,
initiate early fetch)
2) ability to modify fetch parameters

For broader context, see [1]. For fetch parameters (#2) the intent is to
allow the developer to modify the browser defaults - e.g. raise priority of
a fetch relative to other resources. The current thinking is that this can
be done via a src-settings (or some such) attribute on the element, which
would contain the initialization options for the underlying fetch request:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26533#c1

We should expose same flexibility for CSS-initiated fetches. In fact,
perhaps #1 is simply a subset of #2?

- Perhaps we can extend url() to accept extra parameters? e.g.
url("http://...",
<fetch init options>?)
- Perhaps we can use a generic "fetch-settings" attribute that can
communicate these options? E.g.

@font-face {
    font-family: myFont;
    src: url(myFont.woff);
    fetch-settings: preload <fetch init options>?;
}

ig

[1]
https://www.igvita.com/2014/10/02/extensible-web-resource-loading-manifesto/

On Thu, Oct 30, 2014 at 2:35 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

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