Re: Need to: "preload" CSS and JS

On Sun, Dec 19, 2010 at 9:22 AM, Getify <getify@gmail.com> wrote:
> For instance, a site may have some "bootstrapper" JS code that serves the
> critical baseline behavior on the mobile page, but it may have one or more
> additional layers of complex functionality that it wants to layer in a
> little bit at a time. If it were to wait to *load* those resources, a
> significant UX "lag" may appear to the user when they click something and
> the page must wait for the script to load.

So why don't you just write all the extra code as a bunch of functions
that don't do anything until called?  Then put the script at the end
of the body.  Its download won't block anything earlier in the page
from working, and it will do nothing when executed, so it just has to
be parsed.  What problems does this have?

Alternatively, are <script async> and/or <script defer> useful here,
in browsers that support them?  (Remember that if some browsers don't
yet support existing specced features, that doesn't affect our
discussion here.  If the problem is "browsers don't support existing
specs", the solution is not "let's make more specs".)

> That "lag" could be reduced if, during some of the time the user was reading
> content and not yet interacting with it, the page could have been
> "preloading" (but not executing) the JS/CSS for that feature. As I said, the
> JS/CSS may have some noticeable impact on the UX of the initial page load if
> it were allowed to be parsed/executed during the critical first few seconds
> of page-load.

So even parsing the script is too expensive for you?  How about you
fetch it by AJAX and then eval() it when you need it?  I recall
reading that some Google sites were doing this.

> <link rel=prefetch> has been thought to perhaps solve this use case.
> However, the definition of it is not quite what we need. The spec suggests
> that it's a "hint" to the browser on things that will be needed "later", and
> that the browser should fetch them silently in the background at some point,
> during browser idle time.
>
> While this type of definition may very well be valid for "preloading" in the
> original sense of the word (such as loading something on page A that will be
> used on page B), performance optimization folks are seeing the need for a
> mechanism that is more proactive so that you can force the preload of a
> resource for on-demand use "later" in the lifetime of page A.
>
> Because its definition is more of a hint than a proactive request, it's
> unclear/unreliable whether a script loader could dynamically inject such a
> <link> element with `rel=prefetch` and force the browser to download that
> resource right then (or soon thereafter).

Perhaps the answer is to just get browsers to implement rel=prefetch
properly, then.

> Also, several of the browsers do not implement the `load` event for <link>
> elements, so a script or css loader cannot determine that the resource has
> finished loading.

This is a bug in those browsers, and is not relevant here.  Writing
new specifications and getting those browsers to implement them is
considerably more complicated than just getting the browsers to fix
the bug.

> Hopefully, this helps shed some light on the reasoning behind providing a
> proactive mechanism for "preloading" with on-demand parsing/execution as a
> separately available step.

It sounds like what you'd like is a mechanism to inform the browser
that you want a particular resource to be loaded and cached for the
lifetime of the current page, even if its caching headers don't allow
this.  (This isn't a violation of the spirit of the caching headers,
if you consider that browsers normally use resources for as long as
the current page is open even if they're uncacheable.)  That sounds
like a workable idea -- perhaps we could adapt <link rel=prefetch>, or
perhaps make up a new JavaScript function.  I don't think it's at all
workable to try specifying browser caching behavior more generally.

Of course, browsers should always be free to ignore prefetching
requests if necessary.  But authors should be allowed to say "Load
this resource right now and cache it unless it will interfere with
page layout speed, or you otherwise have good reason not to."

Received on Sunday, 19 December 2010 17:27:04 UTC