20.5 静态资源优化、Gzip 压缩、CDN 加速

在 Web 应用的性能优化中，静态资源（HTML、CSS、JavaScript、图片、字体等）的加载速度直接影响用户的第一感知。对于 Node.js 后端来说，虽然它的主要职责是动态接口，但多数项目仍然会涉及静态资源的托管或代理。本节从三个关键维度给出在 Node.js 生态中优化静态资源的实用策略：资源本身的体积优化、传输层的 Gzip 压缩，以及架构层的 CDN 加速。

20.5.1 静态资源优化的整体思路

静态资源优化的核心目标可以概括为 “减少传输量，提高缓存命中率”。具体落地时有几条黄金法则：

压缩：对文本类资源（CSS、JS、HTML、JSON 等）启用 Gzip 或 Brotli，对图片使用 WebP/AVIF 等更高效的格式。
合并与按需加载：将小文件合并为少数大文件以减少 HTTP 请求（Webpack 的 code splitting 平衡点），同时配合 Tree Shaking 删减未使用代码。
版本化与强缓存：通过文件名哈希（如 app.3f2a9b.js）实现长缓存，配合 Cache-Control: max-age=31536000, immutable 让浏览器直接从本地读取。
使用 CDN：将资源分发到靠近用户的边缘节点，降低物理延迟。

对于 Node.js 应用来说，静态资源优化往往不仅涉及代码本身，更涉及部署架构。一个高频误区是让 Node.js 进程直接承担大流量静态文件分发任务，这既浪费了 Node.js 擅长的异步 I/O 能力，又容易被慢速客户端拖住事件循环。因此，最佳实践中 Node.js 多数仅作为 API 服务器，静态资源交由更高效的专业组件处理。

20.5.2 Gzip 压缩：在 Node.js 中如何启用与调优

Gzip 是文本压缩的通用方案，开启后通常能将 CSS、JS、HTML 的体积减少 60%–80%。在 Node.js 中启用 Gzip 有多种方式，需要根据部署架构选择最合适的一种。

方式一：应用层中间件压缩（适用于纯 Node.js 部署）

如果由于某些原因必须由 Node.js 直接返回静态资源，可以使用压缩中间件。以 Express 为例：

npm install compression

const express = require('express');
const compression = require('compression');
const app = express();

// 启用 gzip 压缩，放在其他中间件之前
app.use(compression({
  level: 6,            // 压缩级别 0-9，6 是平衡点
  threshold: 1024,     // 仅压缩大于 1KB 的响应
  filter: (req, res) => {
    // 可自定义过滤，默认根据 Accept-Encoding
    return true;
  }
}));

app.use(express.static('public'));
app.listen(3000);

Koa 用户可使用 koa-compress，NestJS 用户同样可以直接引入 compression 作为 Express 中间件。

需要注意的权衡：

CPU 开销：压缩会消耗 CPU 时间，高并发时可能影响事件循环。可以通过提高 threshold（只压缩较大文件）或降低 level 来减轻压力。
重复压缩：如果同一资源频繁被请求，每次压缩是浪费。此时应采用预压缩：构建时生成 .gz 文件，配合 express-static-gzip 等中间件直接读取。

方式二：反向代理层处理 Gzip（生产环境推荐）

在绝大多数生产环境中，Node.js 进程前都会有一层反向代理，例如 Nginx、HAProxy 或者云厂商的负载均衡器。将 Gzip 压缩交给反向代理处理，是更优雅的选择：Node.js 输出未压缩的响应，由 Nginx 等高效组件异步压缩，完全不占用 Node.js 的事件循环。

示例 Nginx 配置：

server {
    listen 80;
    server_name example.com;

    # 开启 gzip
    gzip on;
    gzip_vary on;
    gzip_min_length 1024;
    gzip_comp_level 6;
    gzip_types text/plain text/css application/json
               application/javascript text/xml application/xml
               application/xml+rss text/javascript;

    # 静态文件直接由 Nginx 处理
    location /static/ {
        alias /var/www/static/;
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # 动态请求反向代理到 Node.js
    location /api/ {
        proxy_pass http://nodejs_server;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

这样，Node.js 不用关心压缩，专注处理业务逻辑；而 Nginx 利用其高效的 C 模块完成压缩，更能利用多核，避免压缩成为性能瓶颈。

Brotli 压缩的进阶选择

Brotli 算法比 Gzip 压缩率更高（尤其在文本文件上可再减少 20% 左右），现代浏览器均已支持。同样，建议在反向代理层启用（Nginx 需编译 ngx_brotli 模块），应用层则可使用 compression 配合 iltorb 等库。注意 Brotli 压缩更耗费 CPU，预压缩同样是可选的优化。

20.5.3 CDN 加速：将内容推送到离用户最近的地方

CDN（内容分发网络）的核心原理是把静态资源复制到遍布全球的边缘节点，用户请求时由最近的节点直接响应，从而实现低延迟、高吞吐、源站减压。对 Node.js 应用来说，CDN 与静态资源优化的结合通常遵循以下模式。

模式一：静态资源完全托管到 CDN

前端打包后的 JS、CSS、图片等文件直接上传到 CDN 服务（如阿里云 OSS + CDN、AWS S3 + CloudFront），应用中的资源引用使用绝对 URL 指向 CDN 域名：

<link rel="stylesheet" href="https://cdn.example.com/css/app.3f2a9b.css">
<script src="https://cdn.example.com/js/app.3f2a9b.js"></script>

Node.js 后端完全不参与静态资源服务，只提供数据 API。这种做法将 Node.js 从静态资源 I/O 中彻底解放，是最彻底的优化。

模式二：CDN 回源到 Node.js 服务器

如果暂时无法将静态资源单独发布，可以让 CDN 回源到 Node.js 服务器（或前面的 Nginx）。此时 CDN 作为第一层缓存，仅当边缘节点未命中时才向源站请求。Node.js 仍可使用 express.static 或 Nginx 上的静态目录，但需要在响应中设置恰当的缓存头，让 CDN 知道如何缓存。

关键缓存头设置示例（Node.js 侧）：

app.use('/static', express.static('public', {
  maxAge: '1y',                 // 缓存一年
  setHeaders: (res, path) => {
    // 仅对带哈希的文件设置 immutable
    if (path.includes('.')) {
      const ext = path.split('.').pop();
      if (['js','css','png','jpg','svg'].includes(ext)) {
        res.setHeader('Cache-Control', 'public, max-age=31536000, immutable');
      }
    }
  }
}));

CDN 会根据 Cache-Control 和 Expires 头决定缓存时长。配合文件名哈希，资源一经发布便可永久缓存，更新时直接改文件名即可实现无痛刷新。

模式三：CDN 与 Gzip/Brotli 的结合

当使用 CDN 时，Gzip 和 Brotli 的压缩可以在边缘节点完成。多数 CDN 服务支持“智能压缩”：源站提供未压缩版本，CDN 根据客户端 Accept-Encoding 头自动压缩并缓存不同版本。这样源站连压缩计算都免了。

如果源站已预压缩并托管在对象存储中，也可以通过 CDN 的“回源拉取”能力直接分发 .gz 或 .br 文件，但需要 CDN 支持相应的头部转发（如 Content-Encoding）。

20.5.4 生产环境的推荐架构

结合前面章节（19.3 CI/CD、20.3 集群）的内容，一个典型的 Node.js 生产部署中，静态资源的处理链通常是：

用户 → CDN 边缘节点 → [回源] → Nginx（反向代理 + 静态文件）
                                │
                                └→ Node.js 集群（仅 API）

CDN 承担第一线加速，缓存静态资源并可选压缩。
Nginx 作为 Node.js 的反向代理，同时可以直接托管静态文件（如果未使用对象存储），并执行 Gzip 压缩。
Node.js 集群 仅处理动态 API 请求，不直接服务静态资源，避免了慢速连接拖慢事件循环的风险。

如果项目规模较小，直接用 Node.js 加一个 compression 中间件也未尝不可，但一定要清楚它在高并发下的局限性。无论选择哪种方案，核心原则不变：静态资源要远离 Node.js 主线程，缓存越靠前越好，体积越小越好。

通过本节介绍的三层优化——压缩资源体积、启用传输压缩、利用 CDN 分发——我们能将静态资源的加载速度提升到极致，同时让 Node.js 进程专注于它最擅长的高并发 API 处理。这也是性能优化从单一节点到整体架构的思维跃迁：一个问题最佳的解决位置，往往不在你的代码里。