Using `Link: rel=preload` is interesting, but it misses the real opportunity to get the critical resources before the html and window to grow the congestion win

Using `Link: rel=preload` is interesting, but it misses the real opportunity to get the critical resources before the html and window to grow the congestion window early. At best you are in a race condition on the browser's preloader/speculative parser. At worse, you are competing with the html base request with your pushed resources. The better solution is to push these resources before the HTTP headers and status code from the application framework. The real opportunity is to get the content downloaded early, grow the congestion window ahead of receiving the html, then yielding the socket to the html, and then continue pushing content until the browser starts making it's own http requests. As all things - mileage will vary. Some times this is a large opportunity (eg: User in Australia requesting content from NY; or DR failover). Other times, push opportunity might be negligible (eg: cached html page) On high RTT networks, this does save you the full round trip for the request. For more details on this check out my talk at Velocity Amsterdam: https://youtu.be/GjWD1pOkxUk?t=1534 https://youtu.be/GjWD1pOkxUk?t=1534 https://speakerdeck.com/colinbendell/promise-of-push https://speakerdeck.com/colinbendell/promise-of-push I also built a tool (on top of webpagetest.org) that helps you evaluate the potential for push here: https://shouldipush.com https://shouldipush.com