SSR与SSG在性能优化中的核心差异解析

在实际项目中，常常会碰到“该用服务器渲染还是先生成静态文件”这样的抉择。把握两者的性能本质，往往比单纯追求速度更能决定架构的可持续性。

SSR 的性能特征

SSR（Server‑Side Rendering）在每一次请求时都要在服务器上执行完整的渲染流水线，生成 HTML 再返回给浏览器。因为渲染过程与业务逻辑紧耦合，页面的首屏时间（TTFB）直接受到后端负载、数据库查询以及模板编译的影响。

• TTFB 通常在 300‑800 ms 之间，峰值时甚至突破 1 s。
• 需要保持服务器常驻进程，CPU 与内存占用随并发量线性增长。
• 动态数据可即时获取，适合电商、社交等对实时性要求极高的场景。
• 首次渲染后仍需在客户端进行 Hydration，额外的 JS 包体积会影响后续交互延迟。

SSG 的性能特征

SSG（Static Site Generation）在构建阶段把所有页面预先渲染成纯 HTML，随后通过 CDN 直接分发。由于不再依赖实时计算，用户请求几乎等同于取回一个文件，网络延迟成为唯一瓶颈。

• TTFB 常在 30‑100 ms 之间，靠近 CDN 边缘节点的访问甚至低于 20 ms。
• 服务器负载几乎为零，构建成本集中在 CI/CD 阶段。
• 适合文档、博客、营销页面等内容更新频率低、可缓存的场景。
• 无需 Hydration（或仅在极少数交互组件上执行），JS 包体积大幅削减。

SSR 与 SSG 的选型考量

如果业务需要每秒数千次的个性化查询，SSR 的实时渲染优势不可忽视；相反，若页面内容在一天内只会更新一次，SSG 的超低延迟和成本优势则更具说服力。下面的对比表把关键指标浓缩成一目了然的形式。

把握这些差异，团队可以在同一项目中混合使用：核心业务页走 SSR，营销落地页走 SSG，甚至在同一框架（如 Next.js）里通过 getServerSideProps 与 getStaticProps 交叉布局。这样既能保证实时性，又不必为全站的低频页面背负额外的计算开销。