CSR，SSR和SSG是什么，有什么优缺点？

CSR是什么

CSR全称是 Client Side Rendering ，代表的是客户端渲染。顾名思义，就是在渲染工作在客户端（浏览器）进行，而不是在服务器端进行。举个例子，我们平时用vue，react等框架开发的项目，都是先下载html文档（不是最终的完全的html），然后下载js来执行渲染出页面结果。

以react为例，客户端渲染初始化的html一般如下

<!DOCTYPE html>
<html lang="en">
 <head> 
  <title data-react-helmet="true">react app</title> 
  <noscript> 
  </noscript>
 </head>
 <body>
  <noscript>
   You need to enable JavaScript to run this app.
  </noscript> 
  <div id="root"></div>
  <script type="text/javascript" src="/static/js/bundle.js" defer=""></script> 
  <script type="text/javascript" src="/static/js/main.chunk.js" defer=""></script> 
 </body>
</html>

可以看出当前页面除了 <div id="root"></div> 元素，没有其他的元素，然后通过加载 bundle.js , main.chunk.js 来执行渲染。整个渲染过程包括，生成DOM节点，注入样式，交互事件绑定，数据获取等等。

客户端渲染的优缺点

优点

前后端分离。前端专注于界面开发，后端专注于api开发，且前端有更多的选择性，可以使用vue，react框架开发，而不需要遵循后端特定的模板。
服务器压力变轻了，渲染工作在客户端进行，服务器直接返回不加工的html
用户在后续访问操作体验好，（首屏渲染慢）可以将网站做成SPA，可以增量渲染

缺点

不利于SEO，因为搜索引擎不执行JS相关操作，无法获取渲染后的最终html。
首屏渲染时间比较长，因为需要页面执行ajax获取数据来渲染页面，如果请求接口多，不利于首屏渲染

SSR是什么

SSR全称是 Server Side Rendering，代表的是服务端渲染。与客户端渲染不同的是，SSR输出的是一个渲染完成的html，整个渲染过程是在服务器端进行的。例如传统的JSP，PHP都是服务端渲染

服务端渲染的优缺点

优点

有利于SEO，由于页面在服务器生成，搜索引擎直接抓取到最终页面结果。
有利于首屏渲染，html所需要的数据都在服务器处理好，直接生成html，首屏渲染时间变短。

缺点

占用服务器资源，渲染工作都在服务端渲染
用户体验不好，每次跳转到新页面都需要在重新服务端渲染整个页面，不能只渲染可变区域

SSG是什么

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

静态站点生成的优缺点

优点

减轻服务器压力，可以把生成的静态资源（html）放到CDN上，合理利用缓存
有利于SEO，由于html已经提前生成好，不需要服务端和客户端去渲染

缺点

只适用于静态数据，对于经常改动的数据，需要每次重新生成页面。
用户体验不好，每次打开新页面都需要重新渲染整个页面，不能只渲染可变区域

除了 CSR，SSR，SSG之外，还有其他渲染解决方案，这里简单介绍一下，分别是

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

关键性的页面（如网站首页、热点数据等）预渲染为静态页面，缓存至 CDN，保证最佳的访问性能；
非关键性的页面（如流量很少的老旧内容）先响应 fallback 内容，然后浏览器渲染（CSR）为实际数据；同时对页面进行异步预渲染，之后缓存至 CDN，提升后续用户访问的性能。

页面的更新遵循 stale-while-revalidate 的逻辑，即始终返回 CDN 的缓存数据（无论是否过期）；如果数据已经过期，那么触发异步的预渲染，异步更新 CDN 的缓存。

nextjs 提供的 ISR 解决方案

一个 next.js 的reactions-demo

ISR的缺点

对于没有预渲染的页面，用户首次访问将会看到一个 fallback 页面，此时服务端才开始渲染页面，直到渲染完毕。这就导致用户体验上的不一致。
对于已经被预渲染的页面，用户直接从 CDN 加载，但这些页面可能是已经过期的，甚至过期很久的，只有在用户刷新一次，第二次访问之后，才能看到新的数据。对于电商这样的场景而言，是不可接受的（比如商品已经卖完了，但用户看到的过期数据上显示还有）。

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

DPR的运行模式如下

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

DPR的缺点

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

原创声明

本文为原创，未经授权，禁止任何媒体或个人自媒体转载

商业侵权必究，如需授权请联系 340443366@qq.com

原文链接：www.kelen.cc