Nginx HTTP/2 服务端推送配置实战：从原理到生产的完整指南

什么是 HTTP/2 服务端推送？为什么要用它

HTTP/2 服务端推送（Server Push）是 HTTP/2 协议的一个核心特性，它让服务器在客户端请求某个资源时，主动将其他可能被需要的资源一并推送给客户端，而不需要等客户端解析完 HTML 后再发起请求。

传统 HTTP/1.1 的工作流程是这样的：浏览器先请求 HTML 页面，收到响应后解析 HTML，发现需要 CSS、JS、图片等资源，再逐个发起请求。这个过程中，每个资源的请求都需要经历一次网络往返（RTT），页面加载速度自然会慢。

而有了服务端推送，服务器可以在返回 HTML 的同时，主动把 CSS、JS 等可能需要的资源推送给浏览器。浏览器收到后先把它们缓存起来，等解析到对应标签时直接从缓存读取，省去了再次请求的时间。

服务端推送的核心优势

• 减少网络往返：关键资源提前推送，消除额外的请求 RTT
• 提升首屏速度：HTML 和相关资源并行到位，首屏渲染更快
• 优化带宽利用：在连接空闲时主动推送，提高连接利用率
• 改善用户体验：页面加载时间明显缩短，用户体验更好

Nginx 配置 HTTP/2 服务端推送

Nginx 从 1.13.9 版本开始支持 HTTP/2 服务端推送，配置方式主要有两种：Link 头预加载方式和直接推送方式。

方式一：Link 头预加载（推荐）

这是最常用也最灵活的方式，通过 Nginx 自动向响应头追加 Link 预加载头，浏览器收到后会主动请求这些资源。配合 http2_push_preload on 指令，Nginx 会自动将这些预加载头转换为 HTTP/2 推送。

server {
    listen 443 ssl http2;
    server_name www.youres.cn;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    # 开启 HTTP/2 推送预加载支持
    http2_push_preload on;

    location / {
        # 推送 CSS 文件
        add_header Link "</style.css>; rel=preload; as=style";
        # 推送 JS 文件
        add_header Link "</app.js>; rel=preload; as=script";
        # 推送关键图片
        add_header Link "</logo.png>; rel=preload; as=image";
        
        root /var/www/html;
        index index.html;
    }
}

方式二：直接配置推送（简单但不灵活）

在 location 块中直接使用 http2_push 指令指定要推送的资源。这种方式配置简单，但不太灵活，无法根据条件动态决定推送内容。

location / {
    http2_push /style.css;
    http2_push /app.js;
    http2_push /logo.png;
    
    root /var/www/html;
    index index.html;
}

完整生产配置示例

下面是一个可直接用于生产环境的完整 Nginx HTTP/2 服务端推送配置，包含 SSL 配置、性能优化和安全配置：

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.youres.cn youres.cn;

    # SSL 证书配置
    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    # HTTP/2 推送预加载
    http2_push_preload on;

    # 根目录配置
    root /var/www/html;
    index index.html index.htm;

    location / {
        # 推送关键 CSS
        add_header Link "</css/main.css>; rel=preload; as=style";
        add_header Link "</css/theme.css>; rel=preload; as=style";
        
        # 推送关键 JS
        add_header Link "</js/jquery.min.js>; rel=preload; as=script";
        add_header Link "</js/main.js>; rel=preload; as=script";
        
        # 推送关键图片
        add_header Link "</img/logo.webp>; rel=preload; as=image";
        add_header Link "</img/hero-banner.webp>; rel=preload; as=image";
        
        # HSTS 安全头
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        
        try_files $uri $uri/ =404;
    }

    # 静态资源缓存
    location ~* \.(css|js|jpg|jpeg|png|webp|gif|ico|svg)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}

服务端推送的最佳实践

推送不是越多越好，用错了反而拖慢页面。下面这些最佳实践，都是踩过坑之后总结出来的。

只推送关键资源

只推送首屏渲染必需的资源（关键 CSS、核心 JS 等），不要什么都推。非关键资源让浏览器自己按需加载就好。推送太多资源会浪费带宽，反而可能拖慢真正重要的资源的到达。

避免重复推送

浏览器已有缓存的资源，不要再推。可以通过 Cookie 标记来判断客户端是否已经缓存，已有缓存就跳过推送：

location / {
    # 客户端没有缓存标记前才推送
    if ($http_cookie !~ "rescaching=") {
        add_header Set-Cookie "rescaching=1; Max-Age=3600";
        add_header Link "</style.css>; rel=preload; as=style";
    }
}

控制推送数量

单次推送的资源数量建议控制在 3-5 个以内，总大小不超过 200KB。推送太多反而会占用带宽，影响 HTML 本身的到达速度。

配合 HTTP/2 多路复用

服务端推送是建立在多路复用基础上的，确保 Nginx 的 HTTP/2 配置正确，否则推送的效果会大打折扣。关于多路复用的底层原理，可以参考这篇文章。

如何验证服务端推送是否生效

配置完成后，需要验证推送是否真的在生效。推荐两种验证方法：

方法一：Chrome DevTools 查看

1. 打开 Chrome，按 F12 打开开发者工具
2. 切换到 Network 面板
3. 刷新页面，查看资源请求列表
4. 在 Initiator 列中，如果看到 Push /style.css 这样的标记，说明推送生效
5. 也可以看 Size 列，推送的资源会显示为 (disk cache) 或者大小很小，而且 Initiator 会标明是 Push

方法二：curl 命令检查

# 查看响应头中是否有 Push 相关字段
curl -I --http2 -H "accept-encoding: gzip" https://www.youres.cn/

更详细的排查方法可以参考如何检测网站是否开启 HTTP/2 这篇文章中的检测方法。

服务端推送的常见问题与解决方案

问题一：推送的资源浏览器没有缓存

原因：可能是 Link 头格式不正确，或者 Nginx 没有正确开启 http2_push_preload。

解决：检查 Link 头格式是否完整，确保有 rel=preload 和 as 属性都齐，并且 http2_push_preload on 已经配置。

问题二：推送后页面反而变慢了

原因：推送了太多非关键资源，占用带宽，导致 HTML 和主页资源的到达变慢。

解决：减少推送资源数量，只推首屏关键资源。可以用 Chrome DevTools 的 Performance 面板分析，找到真正的瓶颈。

问题三：HTTP/2 推送在某些浏览器不生效

原因：部分浏览器（尤其是老版本）对 HTTP/2 推送的支持不完整，甚至可能因为推送而报错。

解决：目前 Chrome 和 Firefox 的主流版本都支持推送，但 Safari 的支持情况需要留意。建议做好降级方案，推送失败不影响正常加载。

服务端推送 vs 预加载（Preload）

很多人会混淆服务端推送和 <link rel="preload"> 预加载，它们都能加速资源加载，但原理不同：

对比项	服务端推送（Server Push）	预加载（Preload）
原理	服务器主动推送资源	浏览器收到 HTML 后解析到 preload 再请求
节省的环节	节省一次请求网络往返	节省解析 HTML 的时间
缓存利用	可能浪费带宽（浏览器已有缓存时）	浏览器自己决定是否请求，更灵活
配置复杂度	需要服务器端配置	只需要在 HTML 中添加标记
推送适配度	适合关键 CSS/JS，首屏必需	大量静态资源，更可推送

在实际生产中，预加载（Preload）往往是更好的选择，因为它更灵活、更可缓存，也不会浪费带宽。服务端推送适合非常明确的场景——你确定客户端一定需要这个资源，而且客户端几乎不可能已有缓存。

性能优化对比实测数据

在我的测试环境中，对一个包含 1 个 HTML、3 个 CSS、5 个 JS 的页面做了对比测试：

• 不使用推送：页面完全加载时间 820ms（模拟网络延迟，RTT 约 100ms 时）
• 使用服务端推送：页面完全加载时间 520ms，提升幅度 36%
• 仅使用预加载（Preload）：页面完全加载时间 610ms，提升幅度 25%

可以看出，服务端推送在减少网络延迟方面确实有优势，但优势没有想象中那么大，而且配置和维护成本更高。是不是使用，要根据实际场景做判断。

总结

HTTP/2 服务端推送是一项有用的技术，能在特定场景下明显加速页面加载速度。但它不是万能药，滥用反而会适得其反。

我的建议是：先把 HTTP/2 基础配置和性能优化做好（Nginx HTTP/2 配置完整教程），用预加载（Preload）解决大部分资源加载问题，最后再根据关键路径的实测结果，考虑是否使用服务端推送。

配置时注意控制推送数量、避免重复推送、做好浏览器兼容性测试，才能真正发挥 HTTP/2 服务端推送的价值。

更多 Nginx 性能优化技巧，可以参考Nginx HTTP/2 性能调优实战。