你点开网站，页面转圈转得比你等外卖还煎熬。
服务器没崩、图片也压了、CDN也开了……可用户还是划走，搜索引擎照样给你降权。问题可能就藏在最底层：你还在用 HTTP/1.1。

你的网站还在用HTTP1.1吗？这可能是最隐蔽的拖慢原因

HTTP/1.1 有个硬伤：一个连接，一次只能干一件事。
哪怕你只是加载一张 2KB 的图标，它也得排队，等前面那个 CSS 文件下载完、解析完、执行完——才轮得到它。

浏览器想绕开？那就多开几个连接。但每个域名最多只让开 6～8 个。
而现代网页动辄几十个资源：CSS、JS、字体、SVG、WebP 图片、JSON 配置……全挤在这几个“窄门”里，后面的一律靠边站。

我帮一个本地家居电商查过，首页资源 60+ 个，首屏加载要五六秒，跳出率高到运营天天找我问是不是广告投错了。
结果发现，连 HTTP/2 都没开。
一开，加载节奏立刻变了——不是“一个接一个”，而是“一堆一起上”。
因为 HTTP/2 支持多路复用：一个连接里，几十个请求并行跑，谁也不卡谁。

怎么确认？打开 Chrome 开发者工具 → Network 标签 → 右键表头 → 勾选 Protocol。
如果看到的全是 http/1.1，那这事今天就得办。

3个必须掌握的资源优化技巧，让HTTP2真正跑起来

HTTP/2 不是魔法开关。它擅长并行，但怕你一股脑塞太多请求过去。
资源数量、加载时机、字体策略，这三个地方不调，HTTP/2 就是空有马力，拉不动车。

1. 小文件该内联就内联，别硬凑大包

HTTP/1.1 时代流行“全站 CSS 合成一个”，现在真没必要了。
一个 300KB 的 CSS 文件，哪怕走 HTTP/2，也会拖慢关键样式渲染——浏览器得等它整个下完、解析完，才能画第一屏。

更实在的做法：

  • 小于 2KB 的图标、按钮样式、首屏关键 CSS，直接写进 HTML 的 <style> 里；
  • 中等体积的资源（比如单张 50KB 的 Banner 图），保持独立请求，让 HTTP/2 并行拉；
  • 大 JS 或框架代码，按路由或功能懒加载，别一上来全塞进去。

2. 懒加载不是“越早加载越好”

很多懒加载插件会提前加载视口下方 2～3 屏的图片，美其名曰“预判用户行为”。
实际呢？用户根本没往下滚，这些请求白发，还占着 HTTP/2 连接和带宽。

真正的懒加载，就一条：
图片还没进视口，浏览器连 src 都别设。
用 IntersectionObserver 监听滚动，进了再赋值 src 或 srcset。
我改过两个资讯站，首屏触发的图片请求数直接砍掉近一半，TTFB 和 LCP 都稳了不少。

3. 字体别“全家桶”，要什么加载什么

一个中文字体文件动辄 2～5MB，加粗、斜体、不同字重各来一份，全扔上去，HTTP/2 再能并行也扛不住带宽吃紧。

两步减负：

  • 在 @font-face 里加上 font-display: swap，让文字先用系统字体顶着，字体加载完再换；
  • 用 unicode-range 按需切字体子集，比如首页只用拉丁字母 + 数字，就别把几千个中文汉字全载进来；CMS 类站点若主要面向国内用户，优先加载 GBK 常用字集，别一上来就塞 Noto Sans CJK 全量包。

服务器配置对了，HTTP2才能真的跑起来

开了 HTTP/2 ≠ 跑得快。
就像给电动车装了电机，但刹车卡着、胎压不足、电瓶老化——动力再强也白搭。

服务器推送？先关掉，别碰

HTTP/2 的 Server Push 听着很酷：浏览器还没开口，服务器就把 CSS/JS 推过去了。
但现实是：90% 的推送都在做无用功。
比如你推了一个 main.css，但用户缓存里早有了，或者这个 CSS 里 80% 的规则根本没用到——推过去，等于往网络里倒垃圾。

真要用？只推首屏绝对绕不开的 1～2 个资源（比如关键 CSS + 主题 JS），且必须带上 Cache-Control: max-age=31536000，避免重复推送。
更稳妥的做法：先关掉 Server Push，观察一周数据，再决定要不要开。

正文压缩不能省，Brotli 比 Gzip 更值得试

HTTP/2 确实做了头部压缩（HPACK），但 HTML、JS、CSS 这些正文内容，还得靠 Gzip 或 Brotli。
Brotli 压缩率通常比 Gzip 高 15%～20%，尤其对文本类资源效果明显。
Nginx 1.13.6+、Apache 2.4.26+ 都原生支持。开一下，重启服务，不用改代码就能见效。

连接别“太勤快地断”

HTTP/2 连接是长连接，但默认超时时间太短（比如 5 秒），用户切个 Tab 再回来，连接早就断了，得重新 TLS 握手——又是一次 200ms+ 的延迟。

建议把 keepalive_timeout 设成 30～60 秒。既不会让闲置连接占满服务器资源，又能覆盖大多数用户浏览间隙。

第三方脚本是HTTP2的最大敌人

你主站跑 HTTP/2，但 Google Analytics、百度统计、微信分享按钮、客服弹窗、广告联盟……它们大多还卡在 HTTP/1.1，而且域名五花八门。

浏览器一看：哦，这是 www.google-analytics.com，跟你的 example.com 不是一个家，得新开连接——HTTP/2 的多路复用？不归这儿管。
更糟的是，有些第三方脚本还会阻塞 DOMContentLoaded，主站都准备好了，它还在那儿吭哧加载。

真实案例：一个企业官网，主域加载 1.2 秒，但一个海外广告 SDK 加载失败重试了 4 次，总耗时 4.7 秒，LCP 直接被它钉在底部。

解法很简单：

  • 所有非首屏必需的第三方脚本，加上 async 或 defer；
  • 分析类脚本（如 GA、神策）统一延迟到 window.onload 后再初始化；
  • 如果某个第三方必须同步加载（比如某些风控 SDK），至少用 <link rel="preconnect" href="https://xxx.com"> 提前建连，省掉 DNS + TLS 时间。

监控HTTP2效果，别靠“我觉得变快了”

页面加载时间（Page Load）波动太大，受用户网络、设备、后台进程影响严重，不适合当 HTTP/2 是否生效的判断依据。

盯这两个指标：

  • Network 面板的瀑布图：打开 DevTools → Network → 刷新页面 → 看所有请求的 Start Time。如果大量请求的蓝色条（Request Start）几乎叠在一起，说明多路复用起了作用；如果还是明显分批、错峰出现，说明连接没复用，或资源被其他逻辑阻塞；
  • TTFB（Time to First Byte）：HTTP/2 的 HPACK 能小幅降低 TTFB，但如果开启后 TTFB 没变化，大概率是后端拖了后腿——比如 WordPress 插件太多、PHP 执行慢、数据库查询没索引。这时候优化 HTTP/2 没用，得去查 slow_query_log 或开 Xdebug。

WebPageTest 也可以用，重点看 “Connection Reuse” 这一栏：如果每次请求都显示 “New Connection”，说明服务器没正确复用连接，回头检查 keepalive_timeout 和 SSL 配置。

今天就能做的1个行动：打开 Chrome，验证并开启 HTTP2

别新建文档、别查教程、别等排期——就现在，打开 Chrome，做这三件事：

  1. 访问你的网站 → F12 打开开发者工具 → Network 标签 → 刷新页面；
  2. 右键点击请求列表顶部任意字段 → 勾选 Protocol；
  3. 看第一行（通常是 HTML）的 Protocol 列：如果是 http/1.1，立刻去后台操作。
  • 如果你用宝塔、cPanel 或阿里云虚拟主机：进「网站设置」→「SSL」→ 找到「HTTP/2」开关，打开，保存；
  • 如果你用 Nginx（常见于自建服务器或 Docker）：编辑配置文件，在 listen 443 ssl; 那行后面加上 http2，变成 listen 443 ssl http2;，然后 nginx -t && systemctl reload nginx；
  • 如果你用 Cloudflare、腾讯云 CDN、又拍云：进 CDN 控制台 →「协议与优化」→ 找到「HTTP/2」或「HTTP/2 & HTTP/3」选项，确保开启。

做完，刷新 Network 面板，看到 h2 了？恭喜，你已经跨过了加载效率的第一道坎。
剩下的事，可以明天再聊。