Jamstack和SSR、CSR等web页面渲染方式的发展概述页面渲染方式主要指的是html页面的渲染时机，比如客户端

概述

页面渲染方式主要指的是html页面的渲染时机，比如客户端渲染、服务端渲染等，后面会对这些有更详细的介绍，另外还会介绍一个见的不太多的名词Jamstack。

传统的SSR

ssr即服务端渲染。

Http0.9 当初就是设计用来获取html页面的，对应的页面是服务端（开发语言不限，比如php、java等）生成的，路由完全由服务端控制，这也是前后端分离之前普遍的做法。

优缺点

优点

完全由服务器生成，利于seo
相对于后面的csr初始化加载速度快缺点
由于每次切换路由都要请求完整资源，后续路由速度慢
每次请求都要生成对应资源，消耗服务器资源比较多

Static site generators

后来前后端分离，前端可以生成html静态页面，直接部署在静态资源服务器上，可以不用依赖后端服务。比如使用jquery操作的活动页，或者github page。

CSR

csr即客户端渲染。在csr中，html页面body中只有一个挂载整个应用的元素，当前一般使用的react和vue就是完全的csr，这种情况下也被称为SPA，即单页面应用，整个应用对应的html只需要加载一次。

优缺点

优点

初始化以后路由快
不需要服务端动态生成，可以使用cdn

缺点

初始化速度慢
不利于seo

当代的SSR

说了这么多，我们怎么把前面两种方案的优点合起来呢？

当我们使用CSR时，页面内容是js在浏览器js引擎中运行生成，而nodejs同样包含js引擎v8，因此可以在服务端将这个过程提前，即将一个路由的页面在服务端生成，然后到浏览器进行Hybrid，即在dom上挂载事件监听器使页面可互动，然后整个应用向SPA一样使用。

vue和react都提供了用于服务端渲染的api,react相关demo可以参考这里。

优缺点

优点

初始化快，初始化时只下载当前页面对应的资源
后续路由快，初始化后会下载其他模块的bundle，转成普通的SPA
利于seo

缺点

仍然需要服务器预渲染对应页面

Jamstack

Static Site Generation

前面的场景要么是完全由服务端渲染，要么完全由浏览器渲染，如果我们把服务端渲染的页面提前生成好了，不就不需要每次服务端预渲染了，这个过程就叫做Static Site Generation。

前面介绍的从传统ssr到csr中间似乎漏掉了什么东西，即还有很长一段时间我们是直接编辑html，然后用jquery编辑dom的，这时候我们开发的产物也是可以直接渲染的页面，比如github pages。

Jamstack介绍

Jamstack是一个web架构，使用jamstack后，前端部署的是build时渲染的html，这些文件可以直接放到cdn上，其中的动态内容可以使用api，比如build前使用headless CMS提供博客等内容，使用http api提供其他数据管理功能。

SSG

其中除了提供上述“当代ssr”的功能外，还提供了SSG(Static Site Generation),即将页面在build时生成html得以放置在cdn上。

我们可以通过Static HTML Export将所有页面导出并脱离服务端部署，这种方式所需要的数据在打包时已经知道了，如果要更换需要重新打包。

ISR

前面一种生成的静态页面可以独立于服务器部署，这里包括下面都需要服务端处理另外的功能。

ISR（Incremental Site Rendering）用来增量的渲染静态页面，比如有些网站有数千个页面，每次发布渲染所有页面都需要很多时间，通过这个技术可以只渲染关键页面，并且各个页面有一个过期时间，当用户访问未生成的页面（用户会看到fallbak页面）或过期页面时（用户会看到旧页面）会自动生成新的页面来更新内容，新生成的内容将在重新访问时看到，而无需重新build。

除了可以根据时间触发更新，还可以使用On-demand Revalidation主动更新。

因为网站内容在随着时间等因素变化，因此它违反了atomic and immutable deployment,即当你想将版本回退到之前某个时刻时，并不一定能实现。

DPR

即Distributed Persistent Rendering，和ISR一样开始只渲染关键页面，当用户访问未渲染页面时，会生成，然后除非重新build不然不会改变，这保证了每次build内容的不可变性。

参考

ssr相关

nextjs相关

jamstack相关