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 > firstname.lastname@example.org > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list email@example.com https://lists.webkit.org/mailman/listinfo/webkit-dev