HTTP/2 对前端性能有哪些提升？

简化版

HTTP/2 相比 HTTP/1.1 的主要提升是多路复用、头部压缩、二进制分帧和请求优先级。多路复用让多个请求共享一个连接，减少连接数量和队头阻塞问题，对前端多资源加载更友好。

详细版

HTTP/1.1 下浏览器对同一域名连接数有限，多个资源可能排队，请求头也会重复传输。

HTTP/2 改进：

二进制分帧：更高效解析。
多路复用：一个连接并发多个请求响应。
HPACK 头部压缩：减少重复 header。
请求优先级：浏览器可表达资源优先级。

对前端的影响：

不再需要过度域名分片。
小文件合并的收益下降。
仍然需要压缩、缓存、代码分割。

HTTP/2 优化传输，不会减少 JS 执行成本。

完整版教学

一、HTTP/1.1 的问题

HTTP/1.1 虽然支持 keep-alive，但同一连接上请求响应仍然容易排队。同一域名连接数有限，资源多时加载瀑布明显。

前端过去常用雪碧图、文件合并、域名分片来减少请求或提高并发。

二、HTTP/2 的多路复用

HTTP/2 把请求和响应拆成帧，在同一个 TCP 连接上交错传输。这样多个资源可以同时进行，不必严格等待前一个响应完成。

这对包含大量 JS、CSS、图片的小资源页面很有帮助。

三、头部压缩

前端请求通常带大量重复 header，比如 Cookie、User-Agent、Accept。HTTP/2 使用 HPACK 压缩头部，减少重复传输。

但如果 Cookie 特别大，每次请求仍然会带来额外成本，所以 Cookie 体积也要控制。

四、面试追问与工程落地

面试官可能问：“HTTP/2 下还需要合并文件吗？”

不需要像 HTTP/1.1 时代那样过度合并，但也不是越碎越好。请求调度、压缩效率、缓存粒度、构建复杂度都要考虑。现代项目更关注合理代码分割，而不是盲目合并。

工程中启用 HTTP/2 后，要减少域名分片，因为多个域名会拆散连接，反而损失多路复用收益。

五、应用层多路复用仍受 TCP 约束

HTTP/2 为每个请求建立逻辑 stream，帧可以交错，但所有 stream 通常共享一条 TCP 连接：

TCP 字节流：[A1][B1][C1][A2][B2][C2]
                ↑ B1 所在 TCP 包丢失
应用交付：后续已到达字节仍等待 TCP 重传缺口

队头阻塞	HTTP/1.1	HTTP/2
应用层请求排队	常见	多路复用显著缓解
TCP 丢包阻塞	存在	仍存在，且会影响共享连接中的流
连接数量	浏览器常开多条	通常更少、复用更集中

若 RTT 为 100ms，丢包重传至少可能带来一个 RTT 量级等待，连接中其他流也会受到 TCP 有序交付影响。这正是 HTTP/3/QUIC 进一步按流处理丢包的动机。

HTTP/2 解决的是 HTTP/1.1 应用层队头阻塞，不是消灭所有队头阻塞；底层 TCP 边界必须说清。

六、前端优化策略如何变化

HPACK 使用静态/动态表压缩重复头部，但超大 Cookie 仍会增加编码表压力和隐私风险。服务端与浏览器还受最大并发 stream、流量控制和优先级实现影响，多路复用不等于无限并发。RFC 9113 已弃用早期复杂的依赖/权重优先级信令，现代优先级也只是调度提示，不能承诺资源严格按指定顺序完成。

过去把 30 个图标合成一张雪碧图能减少 HTTP/1.1 请求排队；HTTP/2 下拆分能改善缓存粒度，但若拆成 300 个极小模块，仍有请求调度、压缩字典、服务端 CPU 和构建运行时开销。选型应以关键路径和真实瀑布图为准。

不再过度域名分片，因为每个新域名可能增加 DNS、TCP、TLS，并拆散连接复用。仍要保留内容压缩、缓存、按路由代码分割、图片优化和减少第三方资源；HTTP/2 不会执行更少 JavaScript。

先定位：网络等待？下载体积？主线程执行？渲染阻塞？
再选择：H2 连接优化 / 缓存压缩 / 代码拆分 / 运行时优化

连接合并还受证书、DNS 和服务器配置约束；不能仅因两个域名指向同一 IP，就假设浏览器一定复用同一 HTTP/2 连接。

七、常见误区与追问

误区：HTTP/2 完全消除了队头阻塞。 它缓解应用层排队，但共享 TCP 仍有丢包导致的有序交付阻塞。
误区：HTTP/2 下资源拆得越碎越好。 请求、调度、服务器处理和运行时模块仍有成本。
误区：升级 HTTP/2 会让 JavaScript 执行更快。 协议优化传输，不减少解析、编译和执行工作。
追问：为什么不再鼓励域名分片？ 多域会拆连接并增加 DNS/TLS，损失同源多路复用收益。
追问：HPACK 解决什么？ 压缩同一连接中重复 HTTP 头，不压缩响应体。
追问：一个连接能否无限开 stream？ 不能，双方有并发和流量控制限制，服务端资源也有限。
追问：何时 HTTP/3 更有优势？ 高 RTT、丢包和移动网络切换场景更可能受益于 QUIC 的独立流与连接迁移。

八、加强记忆

分帧：HTTP 消息拆成带 stream 标识的二进制帧。
复用：多请求交错共享连接，缓解 HTTP/1.1 排队。
压头：HPACK 减少重复 header，不影响业务体和 JS 执行。
遗留边界：底层 TCP 丢包仍可能阻塞整条连接交付。
策略变化：减少域名分片与盲目合并，按缓存粒度合理拆包。
优化方法：用瀑布图、CPU 和渲染指标定位瓶颈，不把协议当万能药。

简化版

详细版