同一个页面，静态生成的 TTFB 是 90 毫秒，SSR 是 480 毫秒，纯客户端渲染的首字节只要 120 毫秒但 LCP 会差一截。这是我们在三类软件站上测出来的结果，测试时间是去年 10 月到 12 月。结论是内容页静态化，个性化部分交给客户端。
测的三类站
文档站：内容按版本发布，天然适合静态生成。我们把一个 800 页的文档站从 SSR 改成静态生成加 CDN，TTFB P75 从 610 毫秒降到 95 毫秒，服务器成本降了四成。
营销站：一周改两次，用增量静态再生成就够。首页原来每次请求都走 Node 服务，改成静态加 10 分钟缓存，TTFB 从 540 到 130 毫秒。
后台控制台：登录后才能看，SSR 没法省。这类页面我们没动渲染方式，只在服务端做了接口并行和数据预取。
为什么 SSR 慢
三个原因：每个请求都要跑一遍框架渲染、接口调用在服务端串行、没有缓存层。第一项省不掉，后两项能改。
一个客户做了接口并行加 60 秒数据缓存，SSR 的 TTFB 从 700 毫秒降到 280 毫秒。这个投入产出比挺高，比换框架现实得多。
静态化的边界
静态化不是万能的，两个前提：内容不因人而异、更新可以延迟。定价页如果按地区显示不同价格就得小心；用户中心如果静态化，页面会串号。
我们的做法是"壳静态加数据客户端"：HTML 里只有布局和文案，个性化数据用接口补。代价是首屏数据晚一点到，对内容页来说无所谓。
CDN 命中率才是分水岭
静态生成只是第一步，页面能不能落到离用户最近的节点，取决于缓存命中率。同样两个用静态生成的站，命中率 95% 的 TTFB 是 90 毫秒，命中率 40% 的 TTFB 是 380 毫秒，差别比 SSR 到静态生成这一步还大。
所以我们改静态生成的时候，会同时把 CDN 的规则和预热一起做。不预热的话，发布后第一批用户仍然要走回源，那几分钟的 TTFB 和没改一样。
一条判断清单
内容页（文档、博客、案例、术语表）走静态生成。营销页（首页、功能、定价）走静态加短缓存。后台和工具走 SSR，重点优化接口。这条线我们用了两年，没出过大问题。
给文档站上 SSR 还配不好缓存的，我见过好几个。这是纯粹的资源浪费，也是 TTFB 优化最常见的弯路。文档站的核心诉求是"任何地方都快手可及"，静态页面加 CDN 就是答案，不需要更复杂的东西。
元析智能
为软件公司做 SEO 和 GEO 优化