在讨论页面加载性能问题时，我经常听到有人说“HTTP/2 推送可以解决这问题”，但我对这个技术的了解不多，于是打算深入研究一下。
HTTP/2 推送远比我最初想象中更复杂，也更底层，但最让我措手不及的地方在于，这种技术在不同浏览器上的表现竟然有这么大的差别，本来我还觉得这技术已经足够成熟，可以在生产环境中使用了。
本文并不是那种认为“HTTP/2 推送一无是处”的吐槽文。我觉得 HTTP/2 推送真的很强大，以后还会更加完善，但并不算能解决所有问题的万灵药。
完整的 Fetch 路径
在页面和目标服务器间，横亘着一系列可能拦截请求的缓存和其他机制：
当人们希望尝试或向别人解释 Git 或其他看得见的东西时，通常会使用类似上面这样的流程示意图，在本来就懂的人看来，这样的示意图一目了然，但不懂的人往往会一头雾水。如果你也有这种感觉，那要先说声抱歉了！希望下文能帮你更好地理解。
HTTP/2 推送的工作原理
- 页面：嘿 example.com，能把你的首页让我看一看吗？
- 服务器：没问题！哦，在我给你发送首页的同时，还需要发送一些样式表、图片、JavaScript，以及一些 JSON。
- 页面：额，好的。
- 页面：我已经看到 HTML 了，但貌似还需要一个样式……哦，好像你已经发过来了，酷！
服务器响应请求时，可以顺便包含额外的资源。例如包含一系列请求报头，这样稍后浏览器就知道如何匹配不同报头。这些额外的资源位于缓存中，当浏览器请求的资源与缓存中的匹配时即可直接从缓存中获取。
这种方法可以改善性能，原因在于可以提前发送可能需要的资源，而不需要等待浏览器索取，因此可以提高页面加载速度。
多年来我对 HTTP/2 推送的了解仅限于此，听起来挺简单，但魔鬼往往隐藏在细节中……
任何东西都可以使用推送缓存
HTTP/2 推送是一种底层网络功能，用到网络栈的任何东西都可以使用该功能。但只有确保一致性以及可预测性，才能发挥最大作用。
我试着推送一些资源，并通过下列方式收集：
- fetch()
- XMLHttpRequest
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
当GPT遇到低代码——低代码平台AIGC开发落地实战
从“全干”工程师的发展路径，看前端的定位与价值
关于 API 文档驱动研发模式的探索与实践
评论