<div dir="ltr">Hello Alexey,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 18, 2015 at 1:27 AM, Alexey Proskuryakov <span dir="ltr">&lt;<a href="mailto:ap@webkit.org" target="_blank">ap@webkit.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hello Yoav,<div><br></div><div>Is there any technology on the horizon that would simplify doing this kind of optimization? If done manually, this seems:</div><div>- complicated, so only a few sites will do this;</div><div>- very likely to go stale, as the content changes, but preload instructions do not get updated;</div><div>- related to the above, the failure mode is opaque, as the website will only get a little slower to load, and not break functionally.</div></div></blockquote><div><br></div><div>I believe that the goal for many of the use cases is to automate that optimization in order to mitigate the issues you raised:</div><div>* For static sites, build scripts could easily add these hints as part of the build process.</div><div>* For dynamic site frameworks (e.g. Django), middleware code can be used to add the hints dynamically.</div><div>* CDNs and optimization engines can use site analysis and heuristics in order to add the hints automatically for their customers.</div><div><br></div><div>The framework and CDN use cases can mean that few implementations may result in many deployments of that optimization.</div><div><br></div><div>Regarding the third point (opaque failure mode), we could emit console errors in case where the preloaded resource is not used.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>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.</div></div></blockquote><div><br></div><div>For the CDN/optimization-engine use-case, HTTP headers would be significantly easier to add automatically.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Preloading resources as untyped data doesn&#39;t seem like a good match to the loader implementation mostly dealing with typed resources.</div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div> Additionally, fetching depends on the referring document&#39;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.</div></div></blockquote><div><br></div><div>Good point to consider while implementing! :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>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?</div></div></blockquote><div><br></div><div>Preload has several advantages over HTTP/2 push:</div><div>* Preload is not limited to first-party resources.</div><div>* Preload will take into consideration the browser&#39;s cache.</div><div>* Preload doesn&#39;t require server side smarts (so can be used to speed up static sites hosted on e.g. GitHub pages or S3).</div><div>* Preload is not limited to secure origins.</div><div><br></div><div><br></div></div></div></div>