Next.js 实战项目 | 青训营笔记这是我参与「第五届青训营」笔记创作活动的第8天 CSR,SSR,SSG CSR

这是我参与「第五届青训营」笔记创作活动的第8天

CSR,SSR,SSG

客户端渲染(Client-Side Rendering)。常见B端WEB应用开发模式，前后端分离，服务端压力相对较轻，渲染工作在客户端进行，服务器直接返回不加工的HTML

我们可以发现在CSR渲染的页面中返回的HTML文件中，大多都是<link>和<script>标签，其主要作用就是引入css和js文件

而关于页面内容的html代码则只有一个最外层标签<div id="root"><div/>，我们会根据JS代码在原有的document中插入节点，使内容展示

SPA：单页面应用，它所需的资源(HTML CSS JS等)，在一次请求中就加载完成，不需要刷新动态加载，首屏时间长

SSR(Server-Side Rendering)。不是什么新鲜的概念，从原先的JSP/PHP就已经体现了服务器端渲染

代码耦合度较高，且模板语言中混杂编程语言对于一些复杂的功能，维护起来较困难

BFF:Backend For Frontend，服务于前端应用的后端

前后端一体化，一套React代码在服务器上运行一遍，到达浏览器又运行一遍，而且首次渲染出的HTML要一样

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

优点：

相比于SSR，因为不需要每次请求都由服务端处理，所以可以大幅减轻服务端的压力

缺陷：

在于只能用于偏静态的页面，无法生成与用户相关的内容，也就使所有的用户访问的页面都是相同的

浏览器的推广程度，取决于搜索引擎对站点检索的排名，搜索引擎可以理解为一种爬虫，它会爬取指定页面的HTML，并根据用户输入的关键词对页面内容进行排序检索，最后形成我们看到的结果

使用CSR的话，页面相关代码较少，难以被检索到关键字

SSR/SSG 只需要请求一个HTML文件就能展现出页面，虽然在服务器上会调取接口，但服务器之间的通信要比客户端快

因为不需要请求大量js文件，这使得SSR/SSG可以拥有更短的首屏时间

SSR的实现

同构的重要原因之一：保证js事件的运行

Next.js是一个构建在Node.js之上的开源Web开源框架，支持基于React的Web应用程序功能，例如服务端渲染和生成静态网站

优点：上手快，覆盖了足够多的性能优化和生态

在服务端执行，只能在页面层面进行绑定，采取同构，首次渲染服务端渲染，路由跳转时用客户端路由，意味着如果使用router跳转当前页，会在客户端执行这部分逻辑

测试getInitialProps首次在服务器上渲染，在跳转时，会在客户端执行逻辑：

我们通过debugger进行测试，如果打开页面的时候，页面出现调试页面，那么就证明代码在客户端中执行

SSR，与getInitialProps不同的是即使使用router跳转路由，也只会在服务端执行这部分逻辑

SSG，在服务器端构建时执行如果涉及动态路由（带参数），需要使用getStaticPaths配置所有可能的参数情况

使用场景：页面固定且情况不多

Strapi简单实现CMS