各种渲染模式
约 785 字大约 3 分钟
2025-10-26
CSR
服务器先返回一个很瘦的 HTML(基本是壳 + JS),浏览器下载 JS 后再请求数据、拼页面。
优点
- 交互体验好:特别适合复杂交互(后台系统、富应用)
- 服务器压力小:主要压力在客户端
- 前后端分离舒服:API + 前端 SPA 很常见
缺点
- 首屏慢:要等 JS 下载/执行完才能看到主要内容
- SEO 相对差:纯 CSR 对搜索引擎不友好(现在也能做,但成本更高)
- 弱网/低端机体验差:JS 重、执行慢就卡
适用场景
后台管理、需要登录后才能看内容的应用、强交互 web app。
SSR
用户请求页面 → 服务器把页面渲染成 HTML(通常也会拉取数据)→ 返回完整 HTML → 浏览器“水合”(hydrate)接管交互。
优点
- 首屏快:第一时间就有 HTML 内容
- SEO 友好:搜索引擎更容易抓取
- 分享预览好:社交平台爬虫能读到内容(标题、摘要、OG 图)
缺点
- 服务器成本更高:每次请求都要渲染
- 复杂度高:同构代码、hydration、缓存、首屏数据、状态一致性
- TTFB 可能变长:服务器渲染花时间(但换来首屏更完整)
适用场景
内容型页面、营销页、电商商品详情、文章页、对 SEO/首屏特别敏感的页面。
SSG
构建时(build)就把每个页面生成静态 HTML 文件,部署到 CDN,用户请求直接拿静态文件。
优点
- 最快(通常):CDN 直接回静态 HTML
- 最便宜、最稳:几乎不需要服务器渲染
- 安全:攻击面更小(主要是静态资源)
缺点
- 内容更新不实时:更新要重新 build + 发布
- 页面数量多会 build 很慢:比如几万篇文章、很多商品页
- 个性化难:基于用户实时数据要靠客户端再请求
适用场景
文档站、博客、活动页、公司官网、内容更新不频繁的站点。
ISR
常见于 Next.js 概念,Nuxt 生态里也有类似的“按需重新生成/缓存失效再生成”的思路(不同平台实现细节会不一样)。
页面先按 SSG 方式生成并走 CDN。之后:
- 可以设置 定时重新生成(比如每 60 秒允许更新一次)
- 或者 某个页面被访问时发现过期,后台再生成新版本并替换缓存 (用户可能拿到旧的,但很快会变新)
优点
- 兼顾 SSG 性能 + SSR 更新能力
- 大站友好:不用每次全量 build,内容更新更灵活
- 成本更可控:绝大多数流量仍是静态
缺点
- 一致性是“最终一致”:短时间内可能有人看到旧内容
- 缓存策略复杂:什么时候过期、怎么触发更新、怎么回源
- 依赖平台能力:部署环境要支持这种缓存/重建模型
适用场景
电商商品、新闻、内容量大且经常更新但又想保持静态性能的站。