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节点,注入样式,交互事件绑定,数据获取等等。
-
优点
-
服务器压力变轻了,让渲染工作在客户端进行,后端专注于 API 开发真正的前后端分离,服务器直接返回不加工的html
-
用户在后续访问操作体验好,(首屏渲染慢)可以将网站做成SPA,可以增量渲染
-
缺点
-
不利于SEO,因为搜索引擎不执行JS相关操作,无法获取渲染后的最终html。
-
首屏渲染时间比较长,因为大部分与网页生命周期相关的任务都由JS处理,这导致页面的首次内容绘制(FCP)和交互时间(TTI)较差。这取决于应用程序的复杂性和大小,这会增加更多的时间。这意味着用户在首次绘制(FP)和FCP之间的时间内几乎看不到任何内容。
SSR(Server Side Rendering)服务端渲染
SSR
也就是服务端渲染, 是指在服务器端将页面渲染成 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
并无二致,因此还是很好理解的。
-
优点
-
有利于SEO,页面内容都在服务器生成,搜索引擎直接抓取到最终页面结果。
-
有利于首屏渲染,HTML所需数据都在服务器处理好生成HTML,首屏渲染时间变短。
-
缺点
-
渲染都在服务端,占用服务端资源而导致服务端压力增加。
-
页面交互/跳转会导致整个页面刷新,体验较差。
-
应用场景
-
出于首屏打开速度、用户体验、
SEO
等目的需要让用户更快的看到页面首屏内容 -
想要预先渲染的页面内容中存在动态的内容
SSG(Static Site Generation )静态站点生成
SSG
是静态站点生成。在构建的时候直接把结果页面输出html到磁盘,每次访问直接把html返回给客户端,相当于一个静态资源。
SSG
主要流程图
Next's 中静态网站生成一般分为三种情况
1.纯静态页面不需要依赖外部数据
function About() {
return <div>About</div>
}
export default About
这种情况最简单,Next.js 会在打包时直接生成一个静态的 HTML。
2.页面的内容依赖外部数据
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
传入,这样就实现了构建时从外部获取数据。
3.页面的路径依赖外部数据
在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 文件,并将其缓存起来。这样,对同一篇文章的后续请求将会直接返回预渲染好的静态内容,提高了页面的加载速度和性能。
-
-
优点
-
-
性能出色,把生成好的html文件可以放到 CDN 上,还能提高缓存利用率。
-
有利于SEO,由于html已经提前生成好,不需要服务端和客户端去渲染。
-
缺点
-
在构建期间生成大量 HTML 文件可能具有挑战性且耗时。
-
任何数据更新都需要应用程序完成构建过程,以使用最新数据再次生成页面 - 这体验非常不好!
-
对于高度动态的内容并不合适,只适用于静态数据
-
应用场景
所以常用于通过
CMS
生成内容、博客站点等静态内容较多的场景。
-
对于首屏速度、用户体验、
SEO
等考虑需要让用户更快的看到页面首屏内容情况。 -
静态内容或低度动态内容或比较规定的动态内容比较合适。
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,而 增量生成 允许我们单独设置某一些页面重新生成“,这样就能节省很多不必要的性能开支了。
-
优点
-
具有 SSG 的所有优点,并且它减少了应用程序的构建时间,因为它避免了在构建期间预渲染所有页面。
-
如果数据有任何更新,则重新生成页面,而无需重建整个应用程序。
-
缺点
-
对于没有预渲染的页面,用户首次访问将会看到一个 fallback 页面,此时服务端才开始渲染页面,直到渲染完毕。这就导致用户体验上的不一致。
-
对于已经被预渲染的页面,用户直接从 CDN 加载,但这些页面可能是已经过期的,甚至过期很久的,只有在用户刷新一次,第二次访问之后,才能看到新的数据。对于电商这样的场景而言,是不可接受的(比如商品已经卖完了,但用户看到的过期数据上显示还有)。
关于ISR
的利弊可以参考 Netlify 的这篇文章:Incremental Static Regeneration:ItsBenefitsAndItsFlaws (https://www.netlify.com/blog/2021/03/08/incremental-static-regeneration-its-benefits-and-its-flaws/)
-
应用场景
使用非交易类的商品类平台、对实时性要求不是很高的都可以用吧,比如:新闻/资讯、博客、社交媒体等。
DPR(Distributed Persistent Rendering) 分布式持续渲染
DPR
是一种分布式持久渲染技术,用于在多台计算机上渲染图像或动画。该技术利用多台计算机的处理能力和存储容量,将渲染任务分配给不同的计算机节点。这些节点之间通过网络进行通信,协同完成渲染任务。由于渲染任务通常需要大量的计算和存储资源,DPR技术可以显著提高渲染效率和速度。
为了解决 ISR 的一系列问题,Netlify 在前段时间发起了一个新的提案:Distributed PersistentRendering(DPR)(https://github.com/jamstack/jamstack.org/discussions/549)
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(https://docs.netlify.com/configure-builds/on-demand-builders/)
-
-
缺点
-
-
新页面访问可能会触发
On-demand Builder
同步渲染,导致当次请求响应时间比较长; -
DoS
攻击比较难防御,因为攻击者可能会大量访问新页面,导致Builder
被大量并行运行,这里需要平台方实现Builder
的归一化和串行运行。
总结
技术本身并不是完美的,CSR、SSR、SSG、ISR、DPR 这些解决方案,多多少少都有一些自身无法解决的问题,它们本质上就是在平衡动态性、渲染性能、缓存性能这三个矛盾点,依然需要继续探索和演进下去。随着技术在持续发展,或许后续会有更好的解决方案。