- From: Yoav Weiss <yoav@yoav.ws>
- Date: Thu, 13 Nov 2014 08:51:17 +0100
- To: Ilya Grigorik <ilya@igvita.com>
- Cc: John Daggett <jdaggett@mozilla.com>, www-style list <www-style@w3.org>
- Message-ID: <CACj=BEg38Fb6QUHp7iX9YizTURYe+PYT142kSyQMVfOMeQRE4A@mail.gmail.com>
On Thu, Nov 13, 2014 at 12:05 AM, Ilya Grigorik <ilya@igvita.com> wrote: > 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. > Fair enough. I agree that there are cases where an opt-in would be required. So, as you suggest, we could have an opt-in signal for "guarantied" preloading, and do our best effort to figure out if a preload is needed in its absence.
Received on Thursday, 13 November 2014 07:51:45 UTC