一文读懂 Next.js 中的 SSR、CSR、SSG、ISR 和 DPR 技术

最新推荐文章于 2023-08-08 17:35:29 发布

汽车之家客户端前端团队

最新推荐文章于 2023-08-08 17:35:29 发布

阅读量573

点赞数 3

本文链接：https://blog.csdn.net/G_yws233/article/details/131912153

版权

服务端预渲染专栏收录该内容

1 篇文章 0 订阅

订阅专栏

最近组内在学习next.js,里面涉及到客户端渲染和服务端渲染中使用的不同的技术。我把学习过程中了解到的这些技术点逐个进行分析、比较和总结，咱不废话了，开始吧。

CSR（Client Side Rendering）客户端渲染

CSR 就是客户端渲染，如常见的 SPA 所使用的渲染方式，所有的主流框架都支持，或者说：只要是在客户端渲染过程中使用到了 JS，数据是通过客户端发送请求获取并渲染的都可以算作客户端渲染。

CSR 主要流程图：
在这里插入图片描述
在 Next.js 中想要使用客户端渲染也很简单，只要上述的这些 API ，例如 getStaticProps 、getServerSideProps …都没使用，数据都是通过在组件内部使用 axios 或者 fetch 去发送请求获取并渲染的，那么我们使用的就是纯客户端渲染了，与直接使用 Vue 或 React 并无差别。所以其实没必要单独起一个服务来做这些。

以 React项目打包编译后的HTML为例:

<!DOCTYPE html>
<html lang="en">
 <head>
   <meta charset="UTF-8" />
   <link rel="icon" type="image/svg+xml" href="/vite.svg" />
   <meta name="viewport" content="width=device-width, initial-scale=1.0" />
   <title>React App</title>
   <script type="module" crossorigin src="/assets/index-c7e05d32.js"></script>
   <link rel="stylesheet" href="/assets/index-d526a0c5.css">
 </head>
 <body>
   <div id="root"></div>
 </body>
</html>

可以很清楚的看到页面内容中只有 <div id="root"></div> 元素，没有其他的元素，然后通过加载 index-c7e05d32.js、index-d526a0c5.css 来执行渲染。整个渲染过程包括，生成DOM节点，注入样式，交互事件绑定，数据获取等等。

优点
1. 服务器压力变轻了，让渲染工作在客户端进行，后端专注于 API 开发真正的前后端分离，服务器直接返回不加工的html
2. 用户在后续访问操作体验好，（首屏渲染慢）可以将网站做成SPA，可以增量渲染
缺点
1. 不利于SEO，因为搜索引擎不执行JS相关操作，无法获取渲染后的最终html。
2. 首屏渲染时间比较长，因为大部分与网页生命周期相关的任务都由JS处理，这导致页面的首次内容绘制(FCP)和交互时间(TTI)较差。这取决于应用程序的复杂性和大小，这会增加更多的时间。这意味着用户在首次绘制(FP)和FCP之间的时间内几乎看不到任何内容。

SSR（Server Side Rendering）服务端渲染

SSRSSR 也就是服务端渲染，是指在服务器端将页面渲染成 HTML 后再返回给客户端。

SSR 主要流程图：
在这里插入图片描述
在 Next.js 中，如果启用了 SSR，那么每次的每次请求都会重新生成页面。想要开启 SSR，我们可以在定义组件的那个文件中暴露一个异步函数 getServerSideProps，这个方法类似于 getStaticProps ，只是执行的时机不同， getServerSideProps 会在每次页面接受请求时都调用。

根据 getServerSideProps 的调用时机，我们可以知道这个方法适用于展示需要经常更新的数据。下面放个官方例子：

export default function Page({ data }) {
  // 渲染数据...
}

// 这个方法每次请求时都会调用
export async function getServerSideProps() {
  // 从外部 API 获取数据
  const res = await fetch(`https://.../data`)
  const data = await res.json()

  // 通过 props 向组件内传入数据
  return { props: { data } }
}

除了调用时机外，getServerSideProps 与 getStaticProps 并无二致，因此还是很好理解的。

优点
1. 有利于SEO，页面内容都在服务器生成，搜索引擎直接抓取到最终页面结果。
2. 有利于首屏渲染，HTML所需数据都在服务器处理好生成HTML，首屏渲染时间变短。
缺点
1. 渲染都在服务端，占用服务端资源而导致服务端压力增加。
2. 页面交互/跳转会导致整个页面刷新，体验较差。
应用场景
- 出于首屏打开速度、用户体验、SEO 等目的需要让用户更快的看到页面首屏内容
- 想要预先渲染的页面内容中存在动态的内容

SSG（Static Site Generation ）静态站点生成

SSG是静态站点生成。在构建的时候直接把结果页面输出html到磁盘，每次访问直接把html返回给客户端，相当于一个静态资源。

SSG 主要流程图：
在这里插入图片描述

Next’s 中静态网站生成一般分为三种情况，分别是:

纯静态页面，不需要依赖外部数据;
页面的内容依赖外部数据;
页面的路径依赖外部数据;

不需要依赖外部数据

function About() {
 return <div>About</div>
}

export default About

这种情况最简单，Next.js 会在打包时直接生成一个静态的 HTML。

页面的内容依赖外部数据

export default function Blog({ posts }) {
  // 渲染文章...
}
// 这个函数会在 build 时接收请求
export async function getStaticProps() {
  // 请求 API 获取文章数据
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  // 在构建时，Blog 组件可以接收到 posts 这个 props
  return {
    props: {
      posts,
    },
  }
}

为了能够在预渲染的时候拿到外部的数据，我们可以在定义组件的那个文件中暴露一个异步函数 getStaticProps ，在打包页面时 Next.js 会先执行 getStaticProps 中的操作，例如发送请求，数据处理之类的。

然后我们可以返回一个对象，其中 props 字段的值会在渲染组件时作为 props 传入，这样就实现了构建时从外部获取数据。

页面的路径依赖外部数据

在Next.js中，路由是由文件系统驱动的，每个页面对应一个文件，文件的路径即为页面的路由路径。例如，pages/index.js 对应根路径 /，pages/about.js 对应 /about 路由。

当需要动态生成页面时，可以使用动态路由。动态路由允许在路由路径中使用参数，这些参数可以根据 URL 中的值来动态生成页面。例如，可以创建一个动态路由 /posts/[id] 用于显示不同 id 值的文章详情页面。

但是，当使用动态路由时，Next.js 需要知道有哪些有效的参数值（例如文章的 id）以便进行预渲染呢？

为了解决这个问题，Next.js 提供了一个特殊的方法 getStaticPaths，你可以在页面组件中使用该方法来声明需要预渲染的参数值列表。

在页面组件中，如果你希望使用动态路由，你可以实现 getStaticPaths 方法。该方法返回一个对象，其中包含一个 paths 数组，这个数组包含了所有需要预渲染的参数值。例如，对于 /posts/[id]，可能有多个不同的文章 id 需要预渲染，这些 id 值就会包含在 paths 数组中。

当用户访问一个动态路由页面时，Next.js 会根据 getStaticPaths 方法提供的参数值列表，预先生成静态的 HTML 文件，并将其缓存起来。这样，对同一篇文章的后续请求将会直接返回预渲染好的静态内容，提高了页面的加载速度和性能。

优点
1. 性能出色，把生成好的html文件可以放到 CDN 上，还能提高缓存利用率。
2. 有利于SEO，由于html已经提前生成好，不需要服务端和客户端去渲染。
缺点
1. 在构建期间生成大量 HTML 文件可能具有挑战性且耗时。
2. 任何数据更新都需要应用程序完成构建过程，以使用最新数据再次生成页面 - 这体验非常不好！
3. 对于高度动态的内容并不合适，只适用于静态数据
应用场景
1. 对于首屏速度、用户体验、SEO 等考虑需要让用户更快的看到页面首屏内容情况。
2. 静态内容或低度动态内容或比较规定的动态内容比较合适。
所以常用于通过 CMS 生成内容、博客站点等静态内容较多的场景。

ISR（Incremental Static Regeneration）增量式静态再生

ISR是一种用于生成静态网页的技术。它在现代静态网站生成器和框架中得到广泛应用，旨在提高网站生成的效率和性能。

ISR 主要流程图：
在这里插入图片描述

ISR解决SSG不适合高度动态内容的这个问题。它工作原理如下：

初始生成：在第一次构建静态网站时，所有的页面都会被生成。
增量式生成：在之后的每次内容更新时，ISR 只会重新生成发生更改的那部分页面，而不是整个网站。这意味着只有受影响的页面会重新生成，其他页面保持不变。
缓存：生成的页面会被缓存起来，当用户请求该页面时，直接从缓存中获取，从而避免了重复的生成过程，提高了网站的响应速度。

从ISR流程图上看，对比SSG只是增加了Server端的逻辑，分别做了以下处理：

在服务端收到对应页面请求时，服务端会先返回当前内容然后对页面做失效验证。
如果页面实现，服务端会对失效的页面进行后台增量构建。
当下次请求到达时，如果新的页面已经生成成功，则会返回新页面的内容，但在此之前还会继续使用旧页面的内容。当然这样不是绝对的，

要在 Next.js 中开启 ISR ，只需要在前面介绍的 getStaticProps 函数中返回一个 revalidate 属性，下面放一个官方的示例：

function Blog({ posts }) {
  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  )
}

// 这个方法会在服务端渲染或者 build 时被调用
// 当使用了 serverless 函数、开启 revalidate 并且接受到新的请求时也会被重新调用
export async function getStaticProps() {
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  return {
    props: {
      posts,
    },
    
    // Next 将会尝试重新生成页面:
    // - 接受到新的请求
    // - 每隔最多十秒钟
    revalidate: 10, // 单位为秒
  }
}

// 这个方法会在服务端渲染或者 build 时被调用
// 当使用了 serverless 函数该路径还没有被生成过就会被重新调用
export async function getStaticPaths() {
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  // 基于 posts 获取我们想要预渲染的路径
  const paths = posts.map((post) => ({
    params: { id: post.id },
  }))

  // 在 build 时，我们将只预渲染 paths 中的路径
  // { fallback: 'blocking' } 在页面不存在时按需进行服务端渲染。
  return { paths, fallback: 'blocking' }
}

export default Blog

ISR 的实现方式是将某些页面标记为可 ISR 页面。这些页面在生成时与 SSG 页面相同，但它们还有一个“revalidate”（再生成时间）。这个时间告诉 Next.js 何时需要重新生成页面。

所以关于增量生成我们也可以简单的总结为：“传统的预渲染如果需要更新内容就得将全部页面重新生成 HTML，而 增量生成 允许我们单独设置某一些页面重新生成“，这样就能节省很多不必要的性能开支了。

优点
1. 具有 SSG 的所有优点，并且它减少了应用程序的构建时间，因为它避免了在构建期间预渲染所有页面。
2. 如果数据有任何更新，则重新生成页面，而无需重建整个应用程序。
缺点
1. 对于没有预渲染的页面，用户首次访问将会看到一个 fallback 页面，此时服务端才开始渲染页面，直到渲染完毕。这就导致用户体验上的不一致。
2. 对于已经被预渲染的页面，用户直接从 CDN 加载，但这些页面可能是已经过期的，甚至过期很久的，只有在用户刷新一次，第二次访问之后，才能看到新的数据。对于电商这样的场景而言，是不可接受的（比如商品已经卖完了，但用户看到的过期数据上显示还有）。
关于ISR的利弊可以参考 Netlify 的这篇文章：Incremental Static Regeneration: Its Benefits and Its Flaws
应用场景

使用非交易类的商品类平台、对实时性要求不是很高的都可以用吧，比如：新闻/资讯、博客、社交媒体等。

DPR（Distributed Persistent Rendering）分布式持续渲染

DPR是一种分布式持久渲染技术，用于在多台计算机上渲染图像或动画。该技术利用多台计算机的处理能力和存储容量，将渲染任务分配给不同的计算机节点。这些节点之间通过网络进行通信，协同完成渲染任务。由于渲染任务通常需要大量的计算和存储资源，DPR技术可以显著提高渲染效率和速度。

为了解决 ISR 的一系列问题，Netlify 在前段时间发起了一个新的提案： Distributed Persistent Rendering (DPR)

DPR 本质上讲，是对 ISR 的模型做了几点改动，并且搭配上 CDN 的能力：

去除了fallback 行为，而是直接用On-demand Builder（按需构建器）来响应未经过预渲染的页面，然后将结果缓存至 CDN；
数据页面过期时，不再响应过期的缓存页面，而是CDN回源到 Builder 上，渲染出最新的数据；
每次发布新版本时，自动清除 CDN 的缓存数据。

在 Netlify 平台上，你可以像这样定义一个 Builder，用于预渲染或者实时渲染。这个 Builder 将会以 Serverless 云函数的方式在平台上运行：

const { builder } = require("@netlify/functions")

async function handler(event, context) {

  return {
    statusCode: 200,
    headers: {
      "Content-Type": "text/html",
    },
    body: `
    <!DOCTYPE html>
      <html>
        <body>
          Hello World
        </body>
    </html>
    `,
  };
}

exports.handler = builder(handler);

更多详细信息可以参考文档：on-demand-builders

缺点
1. 新页面访问可能会触发 On-demand Builder 同步渲染，导致当次请求响应时间比较长；
2. DoS 攻击比较难防御，因为攻击者可能会大量访问新页面，导致 Builder 被大量并行运行，这里需要平台方实现 Builder 的归一化和串行运行。

总结

技术本身并不是完美的，CSR、SSR、SSG、ISR、DPR 这些解决方案，多多少少都有一些自身无法解决的问题，它们本质上就是在平衡动态性、渲染性能、缓存性能这三个矛盾点，依然需要继续探索和演进下去。随着技术在持续发展，或许后续会有更好的解决方案。

好了，以上就是这篇文章的全部内容，感谢各位能读到这里，若对你有帮助，记得帮我点赞哟~~~ ，如有疑问，欢迎评论区留言。

参考文献

汽车之家客户端前端团队

关注

3
点赞
踩
2

收藏

觉得还不错? 一键收藏
1
评论
一文读懂 Next.js 中的 SSR、CSR、SSG、ISR 和 DPR 技术

技术本身并不是完美的，CSR、SSR、SSG、ISR、DPR 这些解决方案，多多少少都有一些自身无法解决的问题，它们本质上就是在平衡动态性、渲染性能、缓存性能这三个矛盾点，依然需要继续探索和演进下去。随着技术在持续发展，或许后续会有更好的解决方案。
复制链接

扫一扫