理解服务端渲染SSR SSR服务端渲染器在发出请求时通过服务端渲染生成页面内容，浏览器只需直接显示从服务器端返回的HTML即可。
客户端呈现CSR通常是在构建普通的SPA单页面APP时构建的客户端呈现的APP表示，当有请求时，CSR客户端呈现Client Side Render的页面内容为空
优点是减轻了服务器的计算压力。 实现前后分离，团队开发中承担各自的任务即可，显著提高开发效率。 坏处是SEO，搜索引擎爬虫无法完全解析用户页面。 随着请求的增加，用户的等待时间会变长，第一个画面的渲染会变慢。 正在消耗用户浏览器的性能。 服务端渲染(SSR server side render )在发出请求时通过服务端渲染生成页面内容，浏览器只需直接显示从服务器端返回的HTML即可。 在传统的服务端渲染中，也称为后端模板渲染，如Jsp或php。 这是最早的时期的web，当客户端请求时，在服务器上使用模板引擎将模板和数据连接成完整的HTML发送给客户端，客户端收到后直接解析HTML就显示在浏览器中，在追加的异步请求中要使web具有交互性，客户端必须使用js来操作DTML
好的SEO优点是搜索引擎的爬虫捕获工具可以直接显示完全渲染的页面，因此如果SEO对站点很重要，并且页面异步获取内容，则服务器可能需要渲染SSR来解决此问题内容到达时间time-to-content变快。 特别是在网络条件或运行缓慢的设备上，不必等待所有JavaScript都被下载并运行。 用户可以更快地看到完全渲染的页面，通常可以获得更好的用户体验。 另外，在内容到达时间Time-to-content与转化率直接相关的APP情况下，内容的到达时间time-to-conte缺点开发条件有限，浏览器固有的代码与特定的生命周期挂钩函数life cycle 某些外部扩展库外部库可能需要特殊处理才能在服务器渲染APP中运行。 与可以部署到任何静态文件服务器上的完整静态单页APP应用程序SPA不同，服务器呈现APP应用程序通常必须位于Node.js server运行时环境中。 显然，如果服务器端负载较大，并且在Node.js中呈现完整的APP应用程序，则CPU资源CPU-intensive-CPU负载将高于仅提供静态文件的server。 因此，如果希望在高流量环境中使用high traffic，则必须准备合适的服务器负载并明智地采用缓存策略。 预渲染使用服务器端渲染SSR，/，/about， 如果SEO只是为了改进少数营销页面(如/contact )，则构建时构建时间为特定根的静态HTML，而不是使用web服务器实时动态编译HTML 如果使用webpack，则可以使用prerender-spa-plugin轻松添加渲染。
优点渲染设置简单，前端APP可以作为完全静态的站点使用。 缺点仅适用于特定的静态页面。 总结本质上对于渲染也是一样的，进行字符串的拼接生成HTML，两者的差异最终体现在时间消耗和性能消耗上。 当客户端在不同的网络环境下发出数据请求时，客户端需要经过从Js加载完成到数据请求再到页面呈现的时间，从而导致大量的时间消耗和浏览器性能的消耗。 而服务端通过内网请求，数据响应快，无需等待Js代码加载，可以先请求数据，再渲染可视部分，然后返回客户端，客户端进行二次渲染。 这样，大部分会消耗服务器端的性能，客户端页面的响应时间也更快。
SSR服务渲染主要解决最初的画面渲染和SEO优化。 是否需要SSR服务渲染主要取决于SEO对于网站是否非常重要，以及内容到达时间time-to-content对于APP应用的重要性。 例如，如果构建的是内部仪表板，则初始加载时的额外几百毫秒并不重要。 在这种情况下，在服务器端渲染SSR就太夸张了。 但是，如果大量访问流量来自搜索引擎，则服务端呈现SSR是必需的解决方案。 或者，内容到达时间time-to-content要求是绝对重要的指标，在这种情况下，服务器端呈现SSR有助于实现最佳的初始加载性能。 总之，开发需要根据实际场景寻找解决方案。
每日一题https://github.com/wind runner max/everyday参考https://SSR.vue js.org/zh/https://zhuan LAN.zhi Hu.com/p/90746589359 ww 9074658359 10b 6074 d 772 c https://github.com/yacan8/blog/issues/303359 juejin.im/post/68908105919684713359 Jue Jin.in