[webkit-dev] <link rel=preload>

[Yoav Weiss]

Hello Alexey,

On Wed, Nov 18, 2015 at 1:27 AM, Alexey Proskuryakov <ap at webkit.org> wrote:

> Hello Yoav,
>
> Is there any technology on the horizon that would simplify doing this kind
> of optimization? If done manually, this seems:
> - complicated, so only a few sites will do this;
> - very likely to go stale, as the content changes, but preload
> instructions do not get updated;
> - related to the above, the failure mode is opaque, as the website will
> only get a little slower to load, and not break functionally.
>

I believe that the goal for many of the use cases is to automate that
optimization in order to mitigate the issues you raised:
* For static sites, build scripts could easily add these hints as part of
the build process.
* For dynamic site frameworks (e.g. Django), middleware code can be used to
add the hints dynamically.
* CDNs and optimization engines can use site analysis and heuristics in
order to add the hints automatically for their customers.

The framework and CDN use cases can mean that few implementations may
result in many deployments of that optimization.

Regarding the third point (opaque failure mode), we could emit console
errors in case where the preloaded resource is not used.


> Sending the preload requests in HTTP response headers seems like it would
> provide the most benefit, but is also more prone to the above issues.
>

For the CDN/optimization-engine use-case, HTTP headers would be
significantly easier to add automatically.


> Preloading resources as untyped data doesn't seem like a good match to the
> loader implementation mostly dealing with typed resources.
>

The `as` attribute makes it so that the resources will not be downloaded
untyped, but will (most likely) merge with the current HTMLPreloadScanner
loading logic.


> Additionally, fetching depends on the referring document's properties
> (notably the charset is inherited for same origin subresources). This is
> not necessarily a blocker, but the proposal adds a different way to think
> about subresource loading.
>

Good point to consider while implementing! :)


>
> There appears to be some feature duplication with HTTP/2 server push
> functionality, could you please characterize the differences that would
> make it worth having both?
>

Preload has several advantages over HTTP/2 push:
* Preload is not limited to first-party resources.
* Preload will take into consideration the browser's cache.
* Preload doesn't require server side smarts (so can be used to speed up
static sites hosted on e.g. GitHub pages or S3).
* Preload is not limited to secure origins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20151118/3c587da0/attachment.html>