- From: Ilya Grigorik <ilya@igvita.com>
- Date: Wed, 12 Nov 2014 15:05:40 -0800
- To: Yoav Weiss <yoav@yoav.ws>
- Cc: John Daggett <jdaggett@mozilla.com>, www-style list <www-style@w3.org>
- Message-ID: <CAKRe7JE5RCT7SGMiuDz8qUFvh+f+H-eGfQLPayDOTMftajmhow@mail.gmail.com>
On Tue, Nov 11, 2014 at 3:20 PM, Yoav Weiss <yoav@yoav.ws> wrote: > Regarding the opt-in for preloading purposes, I believe (but have not > proved yet) that it may not be necessary, and that CSS based resources can > be preloaded without it, at least for the majority of cases. A smarter CSS preloader would be *awesome*, and if you can make it happen, you'll be my hero... again. :) That said, while a smarter preloader would definitely help many sites, it is also not sufficient. Simple example: a JS constructed page that builds up its DOM from API data, etc -- preloader wouldn't be able to do much. A more complicated example: section of my site is displayed on-demand and uses a font that is otherwise not used anywhere else, and pulls in a new background image. For obvious reasons, I'd like to preload those resources before the user triggers the display of said section, such that they are not forced to wait for those to download. Both approaches work together: we need an explicit signal, and we could definitely use a smarter preloader. On Tue, Nov 11, 2014 at 6:15 PM, John Daggett <jdaggett@mozilla.com> wrote: > The key problem a preload hint would solve is that the decision > about whether to use a font or not happens fairly late in the page > loading process. The hint would simply short circuit the "is this > font used?" process and add it to the load queue. > Yep, exactly. Same logic applies for background images, and/or any other CSS initiated fetches. ig
Received on Wednesday, 12 November 2014 23:06:50 UTC