25.3 SSR 性能优化与缓存策略

服务端渲染（SSR）解决了纯客户端应用在 SEO 和首屏加载上的短板，但同时也引入了服务端计算开销和响应延迟的问题——每个请求都要在 Node 服务上完整执行一次组件的渲染与数据获取流程。要让 SSR 在生产环境中跑得快、扛得住流量，就必须引入多层次的缓存和针对性的渲染优化。本节的内容聚焦于 Nuxt 3（Vue 3 的全栈框架）生态下的实用策略。

1. 渲染层面的缓存

页面级缓存（SSR 缓存）
对于内容更新不频繁的页面（如文章详情、产品介绍页），最直接的做法是缓存整页的 HTML 字符串，避免每次请求都重新渲染。

Nuxt 3 提供了 nuxt-multi-cache 这类社区模块，可以按路由配置缓存策略。简单场景下，你也可以通过服务端中间件自行实现：

// server/middleware/page-cache.ts
const cache = new Map()

export default defineEventHandler((event) => {
  const url = event.path
  // 只缓存静态页面或特定路由
  if (url.startsWith('/articles/')) {
    const cached = cache.get(url)
    if (cached && cached.expire > Date.now()) {
      return cached.html
    }
  }
  // 未命中则继续渲染，并在响应后缓存
})

组件级缓存
Nuxt 3 允许对某个异步组件的结果进行缓存，尤其适合侧边栏、页脚等在全站重复出现但数据变化慢的组件。通过 <ClientOnly> 或自定义服务端组件，配合 useAsyncData 的 key 和 transform 可实现局部缓存。

2. 数据获取层的缓存

SSR 最常见的性能瓶颈不是渲染模板，而是等待后端 API 或数据库查询。在 Nuxt 3 中，useFetch 和 useAsyncData 已经内置了请求去重和结果缓存机制。

请求去重：同一页面内多个组件调用同一个接口，Nuxt 会自动合并为一次请求，避免重复网络开销。
服务端数据缓存：利用 getCachedData 或 transform 将接口返回值临时存入内存或外部缓存（如 Redis）。

<script setup>
const { data } = await useFetch('/api/products', {
  key: 'products-list',
  getCachedData(key) {
    // 如果已有缓存且未过期，直接使用
    return cachedData?.expire > Date.now() ? cachedData.payload : undefined
  },
  transform(payload) {
    // 存入缓存
    cachedData = { payload, expire: Date.now() + 60_000 }
    return payload
  }
})
</script>

对于高并发场景，建议将缓存外移到 Redis 等共享存储，确保多进程/多实例间缓存一致。

3. CDN 与静态化策略

全量静态生成（SSG）
如果页面内容完全不变，最彻底的优化是直接使用 SSG，在构建时生成 HTML。Nuxt 3 支持 nuxt generate 预渲染路由，生成的静态文件可以直接推送到 CDN，服务端甚至无需运行 Node。

ISR（增量静态再生成）
当页面内容需要定期更新又不要求实时性时（如新闻列表），ISR 是理想选择。Nuxt 3 配合 Nitro 引擎支持 SWR（stale-while-revalidate）缓存策略，该策略会在后台异步重新生成页面，并在生成完成后替换旧缓存。

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/news/**': { swr: 600 }  // 缓存 10 分钟，后台更新
  }
})

CDN 缓存头部与边缘计算
即便使用动态 SSR，也可以通过设置 Cache-Control 响应头，利用 CDN 的边缘节点缓存页面副本，大幅减少到达源站的请求量。Nitro 允许在 server/ 目录下自定义响应头。

4. 客户端激活优化

SSR 生成的 HTML 传递到浏览器后，还需要进行一次“激活”（hydration），将静态 DOM 与客户端 Vue 实例挂接，使其变为可交互。这个过程存在开销：

避免不必要的客户端脚本：将仅用于服务端渲染的逻辑（如格式化日期、数据转换）置于 server/ 目录，避免打包到客户端。
延迟加载非关键组件：使用 <ClientOnly> 包裹第三方 UI 组件（如地图、图表），这些组件在服务端不渲染，激活阶段再异步加载，能明显减少首帧的 JS 执行时间。

<ClientOnly>
  <HeavyChart :data="chartData" />
  <template #fallback>
    <div class="skeleton">加载中...</div>
  </template>
</ClientOnly>

5. 服务端运行时优化

模板编译优化
Nuxt 3 在生产模式下会预编译所有 Vue 组件，并启用 Vue 3 的静态提升、PatchFlags 等编译优化，服务端渲染函数本身是高度优化的纯字符串拼接过程。

合理拆包，减小服务端包体积
Nitro 支持自动代码分割，但需留意服务端打包时是否误引入了大型的浏览器专用库（如 moment、lodash 全量）。推荐使用支持 tree-shaking 的替代库，或通过 nuxt.config 的 vite 配置将某些包标记为纯客户端侧。

进程管理
Node 服务是单线程模型，密集计算会阻塞事件循环。可以通过 PM2 的集群模式启动多实例，或利用 Nitro 内置的多 worker 能力来利用多核 CPU。同时注意避免在服务端渲染过程中执行同步的 CPU 密集型任务（如大 JSON 序列化、图片处理），这类任务应异步交由队列处理。

6. 监控与剖析

所有优化都应建立在可量化指标之上。你可以通过以下工具定位 SSR 性能瓶颈：

Nitro 内置性能钩子：在 server/plugins 中记录每个请求的渲染耗时。
应用性能监控（APM）：如 Sentry、New Relic，追踪服务端慢请求。
浏览器 Lighthouse / Web Vitals：关注 TTFB（首字节时间），它直接反映了 SSR 服务响应速度。

小结

SSR 的优化不是“做一次就完成”，而是分层缓存 + 按需降级 + 运行时减负的持续过程。牢记这条路径：

能用 SSG 或 ISR 静态化的内容，就别让服务端实时渲染。
必须实时渲染的，先在数据层做好缓存，缩短接口等待。
接口已经足够快时，用组件级缓存或 CDN 缓存进一步降低渲染频率。
始终关注客户端激活体积，让交互发生得顺滑而不突兀。