服务端推送实战要点

服务端推送技术允许服务器主动向客户端发送数据，无需等待客户端请求。在现代Web性能优化中，它对于减少延迟、提升关键资源的加载速度至关重要，尤其是在处理关键CSS、字体或首屏渲染所必需的脚本时。

HTTP/2 Server Push 的核心机制

HTTP/2 Server Push 允许服务器在响应一个初始请求时，主动将客户端可能需要的其他资源一并推送。其核心在于，服务器通过 PUSH_PROMISE 帧提前告知客户端：“我将要发送这个资源给你”，客户端可以据此判断是否已缓存该资源，并决定是否接收。

一个典型的流程是：

  1. 客户端请求 index.html。
  2. 服务器解析 index.html，发现它依赖于 styles.css 和 app.js。
  3. 在发送 index.html 的响应体之前，服务器先发送针对 styles.css 和 app.js 的 PUSH_PROMISE 帧。
  4. 客户端收到 PUSH_PROMISE，检查缓存。如果缓存未命中，它会保留这些流，准备接收数据。
  5. 服务器随后发送 index.html 的响应数据，紧接着在同一个TCP连接上，主动推送 styles.css 和 app.js 的内容。

服务端推送的配置与实现

实现方式主要取决于后端服务器。以下是一些常见服务器的配置示例。

Nginx 配置示例：
在Nginx中，你可以在配置文件的 http、server 或 location 块中使用 http2_push 指令或 http2_push_preload 指令。

nginx 复制代码 
server {
    listen 443 ssl http2;
    server_name example.com;

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

    root /var/www/html;

    # 方法1：直接指定要推送的资源
    location = /index.html {
        http2_push /styles/main.css;
        http2_push /js/app.js;
    }

    # 方法2：利用 `Link` 预加载头部，并启用 `http2_push_preload`
    # 这需要应用在响应中生成 Link 头部
    location / {
        http2_push_preload on;
    }
}

更推荐使用第二种方法（Link 头部 + http2_push_preload），因为它将决策逻辑（推送什么）交给了应用层，更加灵活。

Node.js (with Express & spdy) 示例：
虽然Node.js原生 http2 模块支持推送，但使用 spdy（兼容HTTP/2）的示例更常见。

javascript 复制代码 
const express = require('express');
const spdy = require('spdy');
const fs = require('fs');
const path = require('path');

const app = express();

app.get('/', (req, res) => {
  // 设置 Link 预加载头部
  res.set('Link', '</styles/main.css>; rel=preload; as=style, </js/app.js>; rel=preload; as=script');

  const stream = res.push('/styles/main.css', {
    status: 200,
    method: 'GET',
    request: {
      accept: '*/*'
    },
    response: {
      'content-type': 'text/css'
    }
  });
  stream.on('error', (err) => console.error('Push stream error:', err));
  stream.end(`
    body { font-family: Arial; color: #333; }
    h1 { color: #1a73e8; }
  `);

  // 推送另一个资源
  const stream2 = res.push('/js/app.js', {
    status: 200,
    method: 'GET',
    request: {
      accept: '*/*'
    },
    response: {
      'content-type': 'application/javascript'
    }
  });
  stream2.on('error', (err) => console.error('Push stream error:', err));
  stream2.end(`console.log('App JS loaded via push!');`);

  // 发送主文档
  res.send(`
    <!DOCTYPE html>
    <html>
    <head>
      <title>HTTP/2 Push Demo</title>
      <link rel="stylesheet" href="/styles/main.css">
    </head>
    <body>
      <h1>Hello, HTTP/2 Push!</h1>
      <script src="/js/app.js"></script>
    </body>
    </html>
  `);
});

const options = {
  key: fs.readFileSync('./server.key'),
  cert: fs.readFileSync('./server.crt')
};

spdy.createServer(options, app).listen(443, (err) => {
  if (err) {
    console.error(err);
    return;
  }
  console.log('Server listening on https://localhost:443');
});

推送策略与智能决策

盲目推送所有资源会导致带宽浪费，甚至拖慢页面加载。必须制定智能策略。

  1. 推送关键、小型的资源：优先推送阻塞渲染的关键CSS、Web字体或首屏必需的、较小的JavaScript。避免推送大型图片或视频。
  2. 基于缓存决策：最理想的推送是“仅推送未缓存的资源”。这可以通过 Cookie 或服务端会话存储来实现一个简单的缓存指示器。
    javascript 复制代码 
    // 伪代码示例：Node.js 中基于 Cookie 的简单缓存感知推送
app.get('/index.html', (req, res) => {
  const userCacheKey = req.cookies['asset-version'] || 'v1';
  const currentVersion = 'v2';

  if (userCacheKey !== currentVersion) {
    // 用户缓存过期，推送关键资源
    res.push('/critical.css', { ... });
    // 设置新版本的 Cookie
    res.cookie('asset-version', currentVersion, { maxAge: 86400000 });
  }
  // 无论是否推送，都发送主文档
  res.sendFile('index.html');
});
  3. 使用 Link 头部与 preload：如前所述，在HTML响应头中设置 Link: </asset.css>; rel=preload; as=style。支持HTTP/2 Push的服务器（如配置了 http2_push_preload 的Nginx）会自动将其转换为推送。同时，不支持HTTP/2的客户端或浏览器会将其视为普通的预加载指令，实现了优雅降级。
  4. 聚合与去重：确保不会因为多个页面都请求了同一个资源而重复推送。服务器应维护一个连接级别的推送记录（虽然实现复杂）。

潜在陷阱与规避方法

  • 推送已缓存的资源：这是最大的浪费。解决方案如上所述，需要实现缓存感知。
  • 推送过多资源：这会占用带宽，可能挤占主文档和其他重要资源的传输。严格遵守“仅推送关键、小型资源”的原则，并为推送的总体大小设置预算（例如，不超过50KB）。
  • 浏览器缓存行为差异：不同浏览器对推送资源的缓存行为可能不一致。确保推送响应带有正确的缓存控制头部（如 Cache-Control: public, max-age=31536000）。
  • 连接竞争：在低速网络上，大量推送可能延迟主文档的到达。可以考虑只推送最高优先级的1-2个资源，或者使用 priority 提示（H3优先考虑）。
  • 代理和CDN支持：并非所有中间代理或CDN都完全支持或正确传递HTTP/2 Server Push。在使用前，需确认你的基础设施链支持它。

监控、度量与未来演进

  • 监控：使用Chrome DevTools的 Network 面板，查看资源是否显示为 Push 来源（Protocol 列显示 h2， Initiator 列显示 Push）。在服务器日志中记录推送事件。
  • 度量：通过对比实验（A/B测试），衡量启用推送前后对 LCP (Largest Contentful Paint)、FCP (First Contentful Paint) 等核心Web Vitals指标的影响。关注是否有负面效果。
  • 未来与HTTP/3：HTTP/2 Server Push在实践中暴露出一些问题（如缓存一致性问题、实现复杂性）。HTTP/3引入了一个更完善的替代方案——服务器提示（Server Hints），例如使用 103 Early Hints 状态码或专门的帧来提示预加载，将获取决策权完全交还给客户端，被认为是更可持续的方向。目前，在考虑长期架构时，应更侧重于使用 preload、preconnect 等客户端提示，并与 103 Early Hints 相结合。