音视频开发系列（18）新一代Web技术栈的演进：SSR/SSG/ISR/DPR都在做什么？

在开始阅读之前，先解释一下文章里用到的英文缩写：

• CSR：Client Side Rendering，客户端（通常是浏览器）渲染；

• SSR：Server Side Rendering，服务端渲染；

• SSG：Static Site Generation，静态网站生成；

• ISR：Incremental Site Rendering，增量式的网站渲染；

• DPR：Distributed Persistent Rendering，分布式的持续渲染。

从 SSR 到 SSG

SSR 这套技术栈相信很多人应该都非常熟悉了（如果你不熟悉的话可以先阅读相关文章），React/Vue/Angular 等等都从框架层面直接提供了支持，例如在 React 中你可以这样使用：

import React from 'react'
import ReactDOMServer from 'react-dom/server'

const html = ReactDOMServer.render(<h1>Hello, world!</h1>)

SSR 最早是为了解决单页应用（SPA）产生的 SEO、首屏渲染时间等问题而诞生的，在服务端直接实时同构渲染用户看到的页面，能最大程度上提高用户的体验，流程类似下面：

但 SSR 引入了另一个问题，既然要做服务端渲染，就必然需要一个实时在线的后台服务（通常是基于 Node.js 的服务）用来承载页面请求，那么：

 

1、需要服务器的计算资源和公网流量来部署这套服务，并且消耗的资源与页面的访问量成正相关，当页面的访问量突增时，渲染服务也需要进行扩容；

2、服务端只能部署在有限的几个地域，对于距离服务端较远的用户而言，加载速度跟静态资源的 CDN 相比，慢了一个数量级（通常是 1-5ms VS 50-100+ms）；

3、日常也存在传统服务端同样的运维、监控告警等方面的负担，团队需要额外的人力来开发和维护。

有没有办法解决这些问题呢？

我们重新对 SSR 进行审视，服务端渲染出的页面，逻辑上讲可以分成下面两大块：

1、变化不频繁，甚至不会变化的内容：例如文章、排行榜、商品信息、推荐列表等等，这些数据非常适合缓存；

2、变化比较频繁，或者千人千面的内容：例如用户头像、Timeline、登录状态、实时评论等。

例如，在一篇文