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.

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.

Preloading resources as untyped data doesn't seem like a good match to the 
loader implementation mostly dealing with typed resources. 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.

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?

- Alexey

> 11 нояб. 2015 г., в 6:11, Yoav Weiss <y...@yoav.ws> написал(а):
> Hi,
> I'm interested in adding support for <link rel=preload> 
> <https://w3c.github.io/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.
> Thanks!
> Yoav
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

webkit-dev mailing list

Reply via email to