环境变量与安全机制
6.3 服务端渲染 vs 客户端渲染
Tip
理解SSR和CSR的区别,学会选择合适的渲染模式,优化首屏速度和SEO。
1. 为什么要学这个?
你做了一个博客网站,用的是纯React(客户端渲染)。你把链接发到推特上,结果预览图是一片空白,标题显示Loading...。
你的用户抱怨:打开网页通过手机4G网络,先是看白屏3秒,然后图标才一个个蹦出来。
典型的技术选型错误:该用SSR的地方用了CSR。
2. 核心概念
2.1 CSR vs SSR
-
CSR(客户端渲染):自助火锅
- 服务器只给你端上来生肉和菜(JSON数据+JS代码)
- 你得自己在锅里涮(浏览器执行JS生成HTML)
- 优点:吃起来自由(交互体验好)
- 缺点:坐下要等水烧开(首屏慢),SEO差
-
SSR(服务端渲染):外卖成品
- 后厨(服务器)直接把做好的盖饭(完整的HTML)送到你面前
- 打开盖子就能吃
- 优点:到手即食(首屏极快,SEO完美)
- 缺点:后厨压力大,不能点太复杂的定制菜
-
SSG(静态站点生成):预制菜
- 编译时就生成好HTML,访问时直接给静态文件
3. 渲染流程对比
graph TD
subgraph CSR["客户端渲染(CSR)"]
C1[Client: 请求页面] --> S1[Server: 返回空HTML + JS]
S1 --> C2[Client: 加载菊花转圈...]
C2 --> C3[Client: 执行JS, 拉取数据]
C3 --> C4[Client: 终于出现了内容]
end
subgraph SSR["服务端渲染(SSR)"]
C5[Client: 请求页面] --> S2[Server: 查数据库, 拼装HTML]
S2 --> C6[Client: 看到完整页面!]
C6 --> C7["Client: 此后是Hydration(注水)过程"]
end
style CSR fill:#ffe0b2
style SSR fill:#c8e6c9
**Next.js的魔法:**Next.js默认是SSR + Hydration。它先给你发一碗"看起来能吃"的仿真模具(SSR HTML),让你一眼看到内容;然后悄悄把"灵魂"(JS事件)注入进去(Hydration),让它变回可交互的活物。
4. 适用场景
| 🎯 场景 | 推荐模式 | 理由 |
|---|---|---|
| 公司官网/博客 | SSG / SSR | 必须被谷歌搜索到(SEO),且要求秒开 |
| 后台管理系统 | CSR | 只有内部人用,不需要SEO,交互复杂更重要 |
| 电商详情页 | SSR | 商品价格实时变动,且需要SEO |
5. 避坑指南
| ✅ 推荐做法 | ❌ 禁忌 |
|---|---|
| 默认使用Next.js(SSR) | 默认用Create React App(已过时) |
| Use Client只包住交互部分 | 在根布局layout.tsx加use client(导致整个应用退化为CSR) |
| 检查SEO结果 | 以为页面上有字,爬虫就能看到(右键"查看网页源代码"确认) |
6. 真实案例
Story
2010年,Digg v4的陨落
Digg曾是Web 2.0时代的王者(Reddit的前辈)。2010年,他们发布了第4版,决定完全重写。技术决策:他们激进地采用了当时最新潮的全客户端渲染(Full CSR)架构。灾难后果:1)SEO归零:Google爬虫当时还读不懂JS,只看到了一片白板,Digg的流量一夜之间暴跌;2)性能雪崩:用户的浏览器甚至跑不动这么复杂的JS,页面经常卡死。结果:愤怒的用户大规模迁移到了Reddit,Digg从此一蹶不振,最终以50万美元"白菜价"被贱卖(原本估值1.6亿美元)。
Vibe心法:利用Next.js的服务端渲染(SSR)直接派发"成品盖饭",只在必要时才进行客户端"注水"——首屏速度就是用户留存率。
7. 本章小结
- ⚡ 首屏为王:SSR能让用户在0.1秒内看到内容,CSR可能要等3秒
- 🔍 SEO命门:想让搜索引擎收录,HTML里必须有货,不能只有JS脚本
- 🎯 技术选型:C端产品首选Next.js(SSR),B端后台可选CSR
- 💧 Hydration:Next.js先发送HTML(SSR),再注入JS事件(Hydration)