各位观众老爷们，晚上好！今天咱们聊聊前端界一对好基友，也是一对欢喜冤家：服务端渲染 (SSR) 和静态站点生成 (SSG)。 它们都是提升网站性能的利器，但用法和适用场景却大相径庭。 别怕，我保证用最接地气的方式，把这俩家伙扒个底朝天。
开场白：前端性能优化的那些事儿
话说，前端开发这行，用户体验是王道。 谁也不想打开个网站，半天刷不出来，或者白屏一片。除了优化代码、压缩资源，还有一个大杀器，就是渲染方式的优化。 传统的客户端渲染 (CSR) 简单粗暴，但首屏加载慢是硬伤。 为了解决这个问题，SSR 和 SSG 应运而生。
第一幕：SSR (Server-Side Rendering) – 动态的魅力
SSR，顾名思义，就是在服务器端把页面渲染好，然后把完整的 HTML 直接发送给浏览器。 浏览器拿到的是可以直接显示的 HTML，无需等待 JavaScript 下载、解析和执行。
-
工作原理：
- 浏览器发起请求。
- 服务器接收请求。
- 服务器执行 JavaScript 代码，获取数据。
- 服务器将数据填充到 HTML 模板中，生成完整的 HTML。
- 服务器将 HTML 发送给浏览器。
- 浏览器渲染 HTML，用户看到页面。
- 浏览器下载 JavaScript 脚本，进行 hydration (水合作用)，将服务器端渲染的 HTML "激活"，添加事件处理和交互功能。
-
代码示例 (Node.js + React):
// server.js import express from 'express'; import React from 'react'; import { renderToString } from 'react-dom/server'; import App from './App'; // 你的 React 组件 import template from './template'; // HTML 模板 const app = express(); app.use(express.static('public')); // 静态资源 app.get('*', (req, res) => { const appString = renderToString(<App />); const html = template({ body: appString, title: '我的 SSR 应用', }); res.send(html); }); app.listen(3000, () => { console.log('Server is running on port 3000'); }); // template.js (简单的 HTML 模板) export default ({ body, title }) => { return ` <!DOCTYPE html> <html> <head> <title>${title}</title> </head> <body> <div id="root">${body}</div> <script src="/bundle.js"></script> </body> </html> `; }; // App.js (简单的 React 组件) import React from 'react'; function App() { return ( <div> <h1>Hello, SSR!</h1> <p>This is a server-side rendered React app.</p> </div> ); } export default App;解释：
renderToString函数将 React 组件渲染成 HTML 字符串。template函数是一个简单的 HTML 模板，用于将渲染后的 HTML 插入到网页中。- 服务器将完整的 HTML 发送给浏览器。
- 浏览器渲染 HTML，用户看到页面。
bundle.js包含客户端 JavaScript 代码，负责 hydration 和交互。
-
优点：
- 首屏加载速度快： 浏览器直接拿到 HTML，无需等待 JavaScript 下载和执行。
- SEO 友好： 搜索引擎爬虫可以更容易地抓取页面内容，因为内容已经存在于 HTML 中。
- 更好的用户体验： 尤其是在网络环境较差的情况下，SSR 可以更快地显示页面内容。
-
缺点：
- 服务器压力大： 服务器需要承担渲染页面的任务，增加了服务器的负载。
- 开发复杂度高： 需要同时维护服务端和客户端的代码，增加了开发和维护的难度。
- TTFB (Time To First Byte) 可能会比较长： 服务器需要时间来渲染页面，导致 TTFB 增加。
- Hydration 开销： 客户端需要将服务器端渲染的 HTML "激活"，这会带来一定的性能开销。
-
适用场景：
- 需要 SEO 优化的网站： 例如新闻网站、博客、电商网站等。
- 对首屏加载速度要求高的网站： 例如大型网站、移动端网站等。
- 需要动态内容的网站： 例如用户认证、个性化推荐等。
第二幕：SSG (Static Site Generation) – 静态的优雅
SSG，就是在构建时就把页面渲染好，生成静态 HTML 文件。 浏览器访问时，直接从服务器获取静态 HTML 文件，无需任何额外的计算。
-
工作原理：
- 开发者编写代码，包括 HTML 模板、数据源和生成逻辑。
- 在构建时，SSG 工具执行代码，从数据源获取数据。
- SSG 工具将数据填充到 HTML 模板中，生成静态 HTML 文件。
- 将静态 HTML 文件部署到服务器。
- 浏览器发起请求。
- 服务器直接返回静态 HTML 文件。
- 浏览器渲染 HTML，用户看到页面。
-
代码示例 (Next.js):
// pages/index.js import React from 'react'; function HomePage({ posts }) { return ( <div> <h1>My Blog</h1> <ul> {posts.map((post) => ( <li key={post.id}>{post.title}</li> ))} </ul> </div> ); } export async function getStaticProps() { // 模拟从 API 获取数据 const posts = [ { id: 1, title: 'First Post' }, { id: 2, title: 'Second Post' }, ]; return { props: { posts, }, }; } export default HomePage;解释：
getStaticProps函数在构建时执行，用于获取数据。- 返回的
props会传递给HomePage组件。 - Next.js 会在构建时将
HomePage组件渲染成静态 HTML 文件。
-
优点：
- 性能极佳： 浏览器直接获取静态 HTML 文件，无需任何额外的计算，速度非常快。
- 安全性高： 不需要运行服务端代码，降低了安全风险。
- 易于部署： 可以部署到任何静态文件服务器上，例如 CDN。
- 成本低： 不需要强大的服务器，降低了服务器成本。
-
缺点：
- 不适合动态内容： 每次数据更新都需要重新构建，不适合频繁更新的内容。
- 构建时间长： 站点规模越大，构建时间越长。
- 不适合用户个性化内容： 由于是静态的，无法根据用户进行个性化定制。
-
适用场景：
- 博客、文档、产品介绍等内容型网站： 这些网站的内容更新频率较低，且不需要用户个性化定制。
- 营销页面、着陆页： 这些页面对性能要求高，且内容相对固定。
- 静态网站： 顾名思义，就是内容基本不变的网站。
第三幕：SSR vs SSG – 巅峰对决
既然 SSR 和 SSG 都是解决前端性能问题的方案，那到底该选哪个呢？ 咱们来一场巅峰对决，看看它们各自的优缺点。
| 特性 | SSR | SSG |
|---|---|---|
| 渲染时机 | 请求时 | 构建时 |
| 性能 | 较好，首屏加载快 | 极佳，静态文件直接返回 |
| SEO | 优秀 | 优秀 |
| 动态内容 | 支持 | 不支持，需要重新构建 |
| 构建时间 | 无 | 长，站点规模越大越长 |
| 服务器压力 | 大 | 小 |
| 复杂度 | 高 | 低 |
| 适用场景 | 需要 SEO 和动态内容的网站 | 内容型网站、营销页面 |
选择依据：
- 内容更新频率： 如果内容更新频繁，SSR 更合适。 如果内容基本不变，SSG 更合适。
- SEO 需求： 如果需要 SEO 优化，SSR 和 SSG 都可以。
- 动态内容需求： 如果需要动态内容，SSR 更合适。
- 性能要求： 如果对性能要求极高，SSG 更合适。
- 开发资源： SSR 开发复杂度高，需要更多的开发资源。
第四幕：混合方案 – 各取所长
其实，SSR 和 SSG 并不是非此即彼的关系。 我们可以将它们结合起来，发挥各自的优势。 例如，对于博客网站，可以使用 SSG 生成文章列表页和静态页面，使用 SSR 渲染评论等动态内容。
-
Incremental Static Regeneration (ISR):
Next.js 提供的 ISR 功能，允许我们在部署后更新静态页面。 我们可以设置一个 revalidate 时间，例如 60 秒。 当用户访问页面时，如果页面已经过期，Next.js 会在后台重新生成页面，并在下次访问时返回新的页面。
// pages/index.js import React from 'react'; function HomePage({ posts }) { return ( <div> <h1>My Blog</h1> <ul> {posts.map((post) => ( <li key={post.id}>{post.title}</li> ))} </ul> </div> ); } export async function getStaticProps() { // 模拟从 API 获取数据 const posts = [ { id: 1, title: 'First Post' }, { id: 2, title: 'Second Post' }, ]; return { props: { posts, }, revalidate: 60, // 每 60 秒重新生成页面 }; } export default HomePage;解释：
revalidate: 60表示每 60 秒重新生成页面。- 当用户访问页面时，如果页面已经过期，Next.js 会在后台重新生成页面，并在下次访问时返回新的页面。
第五幕：框架选择 – 工欲善其事
选择合适的框架，可以大大简化 SSR 和 SSG 的开发。 目前比较流行的框架有：
-
Next.js (React): Next.js 是一个基于 React 的 SSR 和 SSG 框架，提供了开箱即用的 SSR 和 SSG 支持，以及路由、数据获取、优化等功能。
-
Nuxt.js (Vue): Nuxt.js 是一个基于 Vue 的 SSR 和 SSG 框架，类似于 Next.js。
-
Gatsby (React): Gatsby 是一个基于 React 的 SSG 框架，专注于静态站点生成。
-
Hugo (Go): Hugo 是一个用 Go 语言编写的 SSG 工具，速度非常快。
-
Eleventy (JavaScript): Eleventy 是一个简单灵活的 SSG 工具，可以使用多种模板语言。
总结：
SSR 和 SSG 都是前端性能优化的重要手段。 SSR 适合需要 SEO 和动态内容的网站，SSG 适合内容型网站和营销页面。 我们可以根据实际需求选择合适的方案，甚至将它们结合起来，发挥各自的优势。
最后的忠告：
选择 SSR 还是 SSG，没有绝对的正确答案。 关键在于了解你的业务需求，权衡各种因素，选择最适合你的方案。 不要盲目跟风，也不要过度优化。 记住，用户体验才是王道！
好了，今天的讲座就到这里。 希望大家有所收获，也希望大家在前端的道路上越走越远！ 谢谢大家！