老站迁到 HTTP/2，先把这四个坑填了

2026 年 10 月我们给一个跑了八年的官网做协议升级，配置本身半小时搞定，后面的调整花了两周。协议换了，之前十几年的优化习惯要跟着改。

迁移本身很简单

服务器支持、证书配好、开 ALPN，基本就完事。云服务和 CDN 现在默认都支持 HTTP/2，很多站其实早就开着了，只是没注意。

怎么确认？看 DevTools 的协议列，显示 h2 就是 HTTP/2。命令行也能看，curl 带 --http2 参数。

HTTP/1.1 时代为了绕过并发限制，把图片、JS、CSS 拆到多个子域名。

HTTP/2 支持多路复用，一个连接就能并发，分片反而变成负担：每个域名要单独 DNS、单独 TLS，多花几百毫秒。

我们这次把六个静态域名合成了两个，首屏的连接建立时间少了 400 毫秒。

以前把十几个 CSS 合成一个大文件，减少请求数。

HTTP/2 下请求不贵了，合并反而伤害缓存。改一个组件，整个大文件的缓存全部失效。

我们的做法是按页面拆分，首屏一份、其余按路由分。改一个页面不影响其他页面的缓存。

HTTP/2 的服务端推送（Server Push）当年被当成优势，现在主流浏览器已经移除支持。

还在用 push 的配置要清掉。它不但没收益，还可能造成重复下载，反而更慢。

替代方案是 preload，浏览器支持稳定，行为可预期。

源站升级了，CDN 还是 HTTP/1.1，用户端就享受不到。

还有反向代理、WAF、负载均衡，任何一层不支持，整条链路就退回旧协议。

迁移前逐层确认，从源站查到边缘节点。查的方式很简单，逐层用 curl 看返回的协议版本。

看三个数：首屏资源加载完成时间、连接建立时间、总请求数。

对比迁移前后各测三次。我们这次的改善主要来自连接数减少，首屏时间从 2.4 秒降到 1.9 秒。

再看真实用户数据。CrUX 里没有协议维度，但 LCP 的变化能反映出来，按地区分组看更明显，网络条件差的地区改善更大。

还有个细节值得记住：HTTP/2 下单个大文件的下载主要受带宽限制，多路复用省的是排队时间。所以迁移之后该做的是减少总字节，不是继续拆文件。这两件事方向不同，别搞混。

HTTP/2 的收益和页面资源数量直接相关。一个只有五个请求的简单页面，迁移前后几乎没差别。

资源多、第三方多的站收益明显，尤其是以前用域名分片的站。

升级本身不难，难的是清理旧习惯。这件事没人会主动做，通常要等一次性能审计才会被发现。

标签:HTTP2协议升级页面体验

元

元析智能

为软件公司做 SEO 和 GEO 优化