Hello Alexey, On Wed, Nov 18, 2015 at 1:27 AM, Alexey Proskuryakov <a...@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.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
