- From: Ilya Grigorik <igrigorik@gmail.com>
- Date: Thu, 30 Oct 2014 15:59:01 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Zack Weinberg <zackw@panix.com>, www-style list <www-style@w3.org>
- Message-ID: <CAKRe7JEHjKfvRk+dBM=Jy7e3eSi7MRBTvk3cc3i+dHbd5qVYOw@mail.gmail.com>
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 > >
Received on Thursday, 30 October 2014 23:00:09 UTC