背景周末上网，看到一则消息：NextJS9.3在NextJS平台中引入了静态站点生成功能。静态站点生成，也称为SSG：StaticSiteGeneration。喝完口水顺便回忆一下现在的渲染模式：SSR（ServerSideRendering）SSG（StaticSiteGeneration）SSRWithhydrationCSRwithPre-renderingCSR（ClientSideRendering）TrisomorphicRendering没什么新鲜的，简单总结一下review吧顺便分享给大家，希望能给大家带来一些启发。正文1.SSR（ServerSideRendering）SSR，服务器端渲染。服务器渲染为服务器上的页面生成完整的HTML以响应导航。这避免了在客户端进行额外的数据获取和模板化往返，因为它是在浏览器获得响应之前处理的。服务器渲染通常会导致快速的首次绘制(FP)和首次内容绘制(FCP)。在服务器上运行页面逻辑和呈现可避免向客户端发送大量JavaScript，这有助于实现快速交互时间(TTI)。这是有道理的，因为通过服务器呈现，您实际上只是将文本和链接发送到用户的浏览器。这种方法适用于各种设备和网络条件，并且可以带来有趣的浏览器优化，例如流式文档解析。流程：浏览器-->服务器-->服务器执行渲染-->index.html(实时渲染内容))-->渲染-->bundle.js+图片-->渲染优势内容即刻可用-因为它会将HTML发送到客户端，所以几乎可以立即看到页面内容。无需获取额外的客户端-理想情况下，服务器呈现进程将进行所有必需的调用以获取数据，因此不会从客户端进行额外的服务调用。非常适合SEO缺点在服务器上速度慢-页面需要呈现两次：一次在服务器上，一次在客户端上。同事也可能从服务器发出服务调用以呈现页面，所有这些都需要时间，因此可能会延迟向客户端发送HTML的初始时间。与某些UI库不兼容-如果您使用的某些库使用window，那么您必须想办法解决它。因为Node.js中没有窗口或文档。2.SSG(StaticSiteGeneration)SSG：静态网站生成。静态站点生成类似于服务器端呈现，不同之处在于您在构建页面而不是在请求它们时呈现页面。与服务器呈现不同的是，由于不必动态生成页面的HTML，它还能够始终如一地快速处理第一个字节。通常，静态呈现意味着提前为每个URL生成一个单独的HTML文件。通过预先生成的HTML响应，可以将静态渲染器部署到多个CDN以利用边缘缓存。优点内容立即可用-因为HTML被发送到客户端，所以几乎可以立即看到页面内容。无需获取额外的客户端-理想情况下，服务器呈现进程将进行所有必需的调用以获取数据，因此不会从客户端进行额外的服务调用。非常适合SEO快速-静态内容呈现速度非常快。无服务器-无需运行服务器。缺点大型站点可能会很慢-如果有很多路线，速度可能会很慢。与某些UI库不兼容-如果您使用的某些库使用window，那么您必须想办法解决它。因为Node.js中没有窗口或文档。3.SSRWithhydrationhydration，直译为水合。让人看得一头雾水。简而言之，将功能放回已在服务器上呈现的HTML的整个过程称为水合作用。换句话说，重新呈现一次呈现的HTML的过程称为水合作用。这种方法试图通过同时进行客户端渲染和服务器端渲染来取得平衡。导航请求（例如整页加载或重新加载）由服务器处理，服务器将应用程序呈现为HTML，然后嵌入JavaScript和数据以呈现到生成的文档中。理想情况下，可以像服务器渲染那样实现快速的FirstContentfulPaint，然后使用称为（再）水化的技术在客户端再次渲染来修补它。这是一个新颖的解决方案，但它也有一些相当大的性能缺陷。水合作用的SSR的主要缺点是：即使改进了FirstPaint，它也会对交互时间产生显着的负面影响。SSR的页面往往看起来具有欺骗性和交互性，但在执行客户端JS并附加事件处理程序之前，实际上无法响应输入。在移动设备上可能需要几秒钟甚至几分钟。原理提示：相对于JS带来的延迟交互，这种模式带来的问题可能更严重：服务端响应导航请求，返回应用UI的数据描述。同时，它还返回用于构成该UI的源数据，以及该UI实现的完整脚本，然后在客户端启动。只有在bundle.js完成加载和执行后，UI才会变得可交互。例如：蓝色部分包含最开始的3个复选框，以及需要加载的bundle.js。一开始，您会立即看到UI。bundle加载执行后，页面会更新，进入交互状态。从真实网站收集的性能指标表明，使用SSRHydrationMode效果不佳，强烈建议不要使用它。原因归结为用户体验：最终很容易将用户带入怪异的山谷。4.CSRwithPrerenderingPre-render的原理是：html页面在构建阶段渲染，无需二次渲染。也就是说，打包的时候页面是什么，那么预渲染是什么。等到JS下载执行完毕，如果页面有数据更新，会重新渲染页面。这会产生数据延迟的错觉。Pre-render使用Chrome官方的Puppeteer工具来抓取页面。提供了一系列无需UI即可调用Chrome功能的API，适用于爬虫、自动化处理等多种场景。它功能强大，因此很容易将运行时HTML打包到一个文件中。其原理是：在Webpack构建阶段结束时，在本地启动一个Puppeteer服务，访问配置了预渲染的路由，然后将Puppeteer中渲染的页面输出成HTML文件，并创建路由对应的目录。这样就达到了预渲染的目的。流程：浏览器-->服务器-->index.html（预渲染内容）-->Render-->bundle.js+images-->Render5。CSR（ClientSideRendering）CSR，顾名思义，客户端渲染。客户端渲染，是指：使用JavaScript直接在浏览器中渲染页面。所有逻辑、数据获取、模板和路由都在客户端而不是服务器上处理。CSR示意图：流程：浏览器-->服务器-->index.html（白屏）-->bundle.js-->图片-->渲染优势服务端速度快——渲染速度因为只渲染空白页面非常快速地。静态支持-空白页面可以静态生成并通过S3等服务提供，使事情变得更快。支持单页应用程序——客户端呈现是支持单页应用程序或SPA的模型。成本相对较低——与SSR/SSG相比，CSR更容易开发/维护。缺点没有初始渲染-如果应用程序很大，或者客户端连接速度慢，加载时间太长，用户体验不是很好。6、三态渲染如果能结合Service-Worker，三态渲染模式说不定也能派上用场。在三态渲染模型中，可以使用serverstreamingrendering进行初始导航，等html加载完成后再让serviceworker继续渲染导航html。这使缓存的组件和模板保持最新，并启用SPA样式的导航以在同一会话中呈现新视图。如果可以在服务器、客户端页面和服务工作者之间共享相同的模板和路由代码，则此方法效果很好。三态渲染模型：7.服务器端渲染VS客户端渲染服务器渲染为每个URL按需生成HTML，这比只提供静态渲染的内容要慢。同时还有一定的优化空间：服务端渲染+HTML缓存可以大大减少服务端渲染时间。服务器渲染的优势在于它可以拉取更多“实时”数据并响应比静态渲染更完整的一组请求。总结从SSR->CSR，中间的不同渲染模式，都在图中：本文介绍的6种渲染模式，至于怎么选择，这里给一些不成熟的建议：对seo的要求不高，同时对于运营需求比较多的项目，比如一些管理后台系统，建议使用CSR。因为只有执行完bundle，页面才能进行交互。单纯看元素不交互是没有意义的，SSR会带来额外的开发和维护成本。如果页面没有数据，或者是纯静态页面，建议使用预渲染。因为这是一种通过预览包来构建页面的方式，不会增加服务器的负担。如果对SEO和加载速度有比较大的需求，页面数据请求比较多，建议使用SSR。好了结局，天快黑了，仅此而已。如有错误，欢迎留言指正。我在周末研究Reciol.js，我觉得它很有趣。稍后我可能会出一篇分析文章，敬请期待。关注我如果你觉得这篇内容对你很有启发，那就关注我吧~更多精彩：聊一聊ESM、Bundleless、Vite、Snowpack记得一个“无限列表”滚动优化“面试三招”代码分割（上）Cache的”“面试三轴”（上）“面试三轴”缓存（下）“面试三轴”HTTP（上）“面试三轴”HTTP（下）这篇“面试三轴”参考资料https://umijs.org/zh-CN/docs/...https://juejin.im/post/684490...https://juejin.im/post/684490...
