在前端圈，渲染模式的选型“不可能三角”：开发效率、首屏性能与动态交互。如果你选错了模式，无论你的监控系统如何优化上报，LCP 的曲线也永远无法达标。
一、 核心概念：谁在什么时候干了活？
1. CSR (Client-Side Rendering) —— 客户端渲染
- 逻辑：服务器只给一个“空壳” HTML 和一个巨大的 JS 包。浏览器下载、解析并执行 JS 后，才开始生成 DOM 并请求数据。
- 现状：React/Vue 的 SPA（单页应用）默认模式。
- 监控视角：FP（首次渲染）极快（白屏结束），但 FCP/LCP 极慢（数据回来前页面是空的）。
2. SSR (Server-Side Rendering) —— 服务端渲染
- 逻辑：每当用户请求，服务器现跑一遍代码，生成完整的 HTML 字符串丢给浏览器。
- 现状：Next.js / Nuxt.js 的核心能力。
- 监控视角：TTFB（首字节时间）受服务器性能影响，但 FCP 几乎等于 TTFB，用户能瞬间看到内容。
3. SSG (Static Site Generation) —— 静态网站生成
- 逻辑：在构建阶段（Build Time）就把所有页面跑一遍，生成一堆纯 HTML 静态文件。
- 现状：适合个人博客、文档、或者变化不频繁的电商详情页。
- 监控视角：性能的极致。配合 CDN，LCP 时间几乎可以忽略不计。
二、 深度对比：你的业务该选哪一种？
| 维度 | CSR (SPA) | SSR (Dynamic) | SSG (Static) |
|---|---|---|---|
| SEO 友好度 | 差（爬虫看到的是空壳） | 极好 | 极好 |
| 首屏白屏时间 | 长 | 短 | 极短 |
| 服务器压力 | 低（压力在客户端） | 高（每次请求都要计算） | 极低（只读静态文件） |
| 数据实时性 | 实时 | 实时 | 滞后（需要重新构建） |
三、 避坑指南
1. SSR 的“水合（Hydration）”陷阱
你以为 SSR 回来就万事大吉了？HTML 虽然出来了，但此时页面是不可交互的。浏览器还需要下载 JS 并绑定事件。
- 坑点：如果 JS 体积过大，会出现“看得见点不动”的尴尬期（FID 指标爆表）。
- 对策：使用 Streaming SSR（流式渲染）或 Progressive Hydration（渐进式水合）。
2. SSG 的“构建地狱”
如果你的商城有 10 万个商品，每次改个页脚（Footer）都要全量重新构建 SSG 页面，你的 Jenkins 可能会跑满一天。
- 对策：开启 ISR (Incremental Static Regeneration) 。Next.js 支持在后台静默更新某个特定页面，无需重启整个构建流程。
3. CSR 的“白屏黑洞”
对于交易大屏等强交互应用，CSR 是首选，但必须配合 骨架屏（Skeleton Screen） 。
- 建议：在你的监控系统中，重点监控 TTI（可交互时间） ，这才是 CSR 应用的生死线。
