[webkit-dev] <link rel=preload>

Ryosuke Niwa rniwa at webkit.org
Wed Nov 11 06:50:16 PST 2015


On Wed, Nov 11, 2015 at 6:11 AM, Yoav Weiss <yoav at yoav.ws> wrote:
> I'm interested in adding support for <link rel=preload> and the
> corresponding "Link:" headers and wanted to gauge interest for supporting
> the feature.
>
> The preload relationship provides a declarative fetch primitive that enables
> developers to initiate a resource fetch and separate fetching from resource
> execution. As such, preload is a low-level primitive that enables
> applications to build custom resource loading and execution behaviors
> without hiding resources from the user agent and incurring delayed resource
> fetching penalties.
>
> Use cases include:
> * Early fetch of lately discovered critical resources - Sites that contain
> critical resources that aren't discoverable by the preload scanner (e.g.
> fonts, JS loaded scripts and styles, etc) can use the feature to download
> these critical resources early
> * Separation of download and execution in a declarative, non-hacky way.
>
> All in all, it would enable Web sites to significantly improve loading
> performance in various common scenarios.

This seems helpful in reducing the initial latency for sub resource loading.

One strange thing about this feature is that the authors have to load
the resource again using script element, etc... to get the actual
content.  I suppose the reason we don't do that is the fact it could
load a subresource of an arbitrary type and that exposing the contents
of scripts need to be restricted to the same origin documents.

But as I understand it, this is sort of a declarative fetch / XHR.
And historically, fetch / XHR never worked with cross-origin resources
so it seems fine to add such a restriction and let authors extract the
contents.  I think it would be particularly useful for fetching JSON,
etc...

I also thought of an alternative design to introduce "preload"
attribute on img, script, etc... but that doesn't work for fonts,
background images, etc...

- R. Niwa


More information about the webkit-dev mailing list