每个页面都有自己的预载缓存，因此对打算用于其他页面的资源进行预载是没意义的。例如，我们无法对加载其他页面时需要的资源进行预载。此外对服务工作进程安装中使用的页面进行预载也是没意义的，服务工作进程并不会检查页面的预载缓存。
Chrome - 部分支持
Safari - 部分支持
Firefox - 不支持
Edge - 不支持
Chrome不支持使用任何API进行的预载。例如fetch()不会使用预载缓存，虽然XHR可以使用，但前提是需要带凭据发送（问题描述）。
Safari只有最新的技术预览版支持预载，fetch()不使用预载缓存，XHR也不使用（问题描述）。
Firefox不支持预载，但相关实现正在进行中（问题描述）。
Edge不支持预载。如果希望支持，请来这里投票。
建议再完美的预载，其速度也要略微慢于完美的HTTP/2推送，因为推送不需要等待浏览器发出请求。然而预载方式的实现更简单，也更易于调试。建议目前继续使用预载，因为浏览器对预载的支持只会越来越完善，但为了确保预载项能够被正常使用，也需要留意开发工具提供的信息。
一些服务会将预载的报头转换为HTTP/2推送。我觉得这种做法是错误的，毕竟这两种做法之间还有一些微妙的差异，但未来一段时间里也许只能如此。然而你需要确保这些服务能将报头从最终响应中剔除，否则可能面临竟态条件，预载先于推送进行，导致带宽占用翻倍。
推送技术的未来目前HTTP/2推送技术还存在一些相当麻烦的Bug，可一旦这些问题顺利解决，我认为对于目前需要内联的资源，尤其是对渲染结果至关重要的CSS来说，该技术将成为最理想的选择。缓存摘要功能顺利实现后，我们将有可能同时从内联以及缓存机制中获益。
哪种做法更恰当，这取决于服务器是否足够智能，可以让我们为内容的流式传输确定最合适的优先级。例如我希望最重要的CSS能够与页面头一起并行传输，但CSS优先级最高，毕竟CSS没有发送完成的情况下，推送暂时无法渲染的主体内容，这也是对带宽的浪费。
如果你的服务器响应速度略慢（由于开销不菲的数据库查询或其他因素），也可以利用这段时间推送页面可能需要的资源，随后在页面可用后更改优先级。
之前已经说过，本文并不是为了吐槽哪种技术，希望你也不要有这样的误解。HTTP/2推送有助于改善性能，但建议只有在妥善测试后再考虑使用，否则可能会让速度变得更慢。