有研究创造，网站加载韶光每增加一秒，用户便会流失落 10%。为提高页面的秒开率，各路人马不断探索着优化策略，仅仅在浏览器领域下的优化已经知足不了极致的哀求了，大家开始往做事端方向不断探索，并一度让【做事端渲染】这一古早的观点 “翻红”，且炒得火热。
做事端渲染简称 SSR，全称 Server Side Rendering，顾名思义是将渲染的事情放在 Server 端进行。这种办法不仅有利于首屏渲染，提高 SPA 运用的首屏相应速率，还方便搜索引擎抓取，有利于 SEO 优化。不过，到 2023 年了，SSR 并没有预想中的盛行。
有评论认为，大部分用 SSR 的缘故原由是为了做事 SEO，但现在搜索引擎已经跟上发展步伐了，对付用框架写成的 SPA 支持也不错，以是 SSR 必要性没那么大了。还有人以为 SSR 便是伪需求，业务逻辑和掌握器分离好了加载一样快。
但也有评论认为，现在仍旧有大量的用户由于网络环境或设备情形，在访问 Web 页面的时候无法达到很好的体验，如果要提升这部分用户的体验，那么 SSR 便是一种不可或缺的办法。
对此，真实的情形是若何的？实际运用中，阻碍 SSR 成为 Web 主流开拓模式的缘故原由是什么？这种方法放到本日的环境下过期了吗？什么样的业务场景更适宜 SSR 呢？对此，开源中国约请了两位前端大佬，来听听他们的意见。
刘奎，社区昵称 kuitos 。支付宝体验技能部前端工程师，开源微前端方案 qiankun 作者，目前在蚂蚁卖力 Web 基建研发干系事情。刘勇，社区昵称天猪，某大厂 Node.js Infra 卖力人，EggJS / CNPM 核心开拓者。一、SSR，并不是伪需求Q1：以你的履历，什么类型的项目和场景更常用 SSR ？能举些例子吗？
刘奎：对首屏性能非常敏感，或者对 SEO 有强诉求的这类网站会更常用 SSR，如：
电商平台：更快的首屏渲染可以让用户更快的看到商品信息，提升购买转化率营销活动页：秒开能有效提升营销活动的业务效果门户网站：内容型站点常日对 SEO 有着比较强的诉求Q2：从你的实际体验出发，你以为 SSR 比较于 CSR（Client-side rendering）模式，上风在哪？
刘奎：从我个人体验来看，最大的上风还是在首屏体验上，SSR 模式下 HTML 加载过程中用户就能看到有效的页面内容，这个基本是 CSR 很难做到的。
Q3：如今搜索引擎已经支持渲染了，你认为还有必要由于 SEO 的缘故原由利用 SSR 吗？
刘奎：由于众所周知的缘故原由，海内的搜索引擎对 SPA 类型的运用支持的并不好，如果希望自己的网站能更好的被爬虫索引到，基本上还是须要利用 SSR（或者 SSR 的变种）方案了。
Q4：有人认为 SSR 是伪需求，要改进首屏渲染性能的话，后端做事的业务逻辑和掌握器分离，掌握器分视图掌握器和接口掌握器，调用相同的业务逻辑。第一次打开页面，前端 JavaScript 加载页面渲染的数据，用户交互时再要求接口获取数据。这个方案比性能焦急的 SSR 强多了。你怎么评价？
刘奎：这个方案实质还是 CSR，无法办理 CSR 方案原生的问题：即用户必须等到 JS 下载完成 -> 发起接口要求 -> JS 获取数据渲染页面之后，才能看到有效内容的问题。在越苛刻的网络环境及用户设备条件下，这个问题会越明显。
刘勇：根据团队的基建成熟度和业务场景做技能选型，这 2 个方案没有绝对的利害，也不是绝对的割裂，它们是可以通过前端工程化结合成一个方案的。
二、SSR，想红有点难
Q5：以当前的形势来看，SSR 并没能成为 Web 主流的开拓模式，你以为这个中的阻碍有哪些？
刘奎：我以为紧张有这几类缘故原由：
技能繁芜度：SSR 须要在做事器端进行渲染，并与前端框架进行集成，对开拓职员来说须要节制更多的技能知识。SSR 带来的额外的开拓及掩护本钱：相对付 CSR，SSR 方案须要前端额外去关注做事审察干的开拓及运维，比如如何写出更高性能的做事端渲染逻辑，如何处理潜在的内存透露、变量污染等隔离问题，如何做 SSR 的容灾（在 SSR 失落败时 fallback 到 CSR）等，这些都须要团队有额外的资源及时间投入。场景匹配度：海内大量的做事是通过小程序、APP 这类载体进行分发的，纯 Web 技能栈的产品相对较少，这点与国外的场景有着非常大的不同。刘勇：首先，SSR 是须要做事器资源本钱的，在降本提效的大背景下，会须要结合 Serverless 或边缘打算等一些基建才能找到平衡点。同时既然是做事端，就有一定的运维能力哀求，对前端团队的技能积累有一定的哀求。
其次，框架的封装和掩护如果做的不好的话，业务同学写 SSR 很随意马虎弄出内存透露问题，这是非常常见的。而且目前的前端框架还没有针对 SSR 场景进行优化，如果只是首屏展示快，但紧接着要下载超大的 Bundle 文件，从而用户可交互韶光太慢，就得不偿失落了。
末了，演进路径问题，譬如蚂蚁那边，他们当年就已经跟把离线包的高下游基建都做的很完善了，APP 侧、网络侧都有兄弟团队合营一起打磨。这种模式会有一些毛病，如离线包太多时的业务竞争问题，但就首屏性能这一点上，SSR 不一定比它好多少，这时候让他们切换到 SSR 就会有不小的阻力。
Q6：有评论认为 SSR 开拓和掩护本钱太高了，转而投向了 CSR 的怀抱。CSR 能否取得跟 SSR 一样的效果呢？有什么详细的操作方案吗？
刘勇：从首屏性能的关键点看，CSR 如果不做一定的优化的话，至少 3 次串行的 HTTP 要求，首屏韶光肯定比不过 SSR（互操作韶光就不一定）。
不过相应的办理方案也挺多的，如 ServiceWorker、离线包等等办法。
刘奎：单从首屏渲染速率这一点来看，CSR 想取得 SSR 类似的效果，可以采纳以下方案优化：
首屏页面静态资源优化：通过代码切割 &Q7：如果将原有的运用直接切换到 SSR 一体化运用中来，本钱会有多大？对开拓团队会有哪些寻衅呢？
刘奎：本钱及寻衅有以下几点：
运用改造本钱：大部分运用都是无法直接在做事端环境运行的，基本都须要做一定程度的改造，比如肃清首屏渲染代码中对 window、location 等浏览器特有 API 的依赖，构建出用于做事端运行的 JS 等。SSR 函数研发及运维寻衅：同时具备丰富的前端及做事端开拓履历的团队在大部分公司都是非常少见的，如前面提到的，SSR 带来的额外的做事真个开拓及运维寻衅，这个也是须要前端团队考虑的。三、大概，SSR + CSR 会是未来新方向？Q8：现在一些网站采取了首屏做事器端渲染，即对付用户最开始打开的那个页面采取的是做事器端渲染，这样就担保了渲染速率，而其他的页面采取客户端渲染，这样就完成了前后端分离。你以为这会是领悟了两者上风的更完美的方案吗？
刘奎：是的，这也是目前社区内的最佳实践，能很好的保留 SSR 及 SPA 运用的优点。
刘勇：这实在很多年前就有干系实践了，譬如当年云龙在 UC 的 Scrat Pagelet 便是类似的实践，乃至当时做的是后续页面也通过做事端局部渲染，按需更新前端页面的阶段。
这种办法在业界也有看到一些更近一步的实践：开拓者很自然的去写逻辑，不用管什么分离不分离的事，在前端工程化那一层自动拆分，SSG + SSR + CSR，一些可以静态构建的直接在构建阶段处理了，一些可以在做事端渲染的做事端，剩下的非刚需的组件直接前端渲染掉。这些都能做，条件是前端工程化这块的基建是否足够完善，研发模式是否足够收敛。
末了提醒下，我所理解大部份 SSR 实践，一样平常也会在前面再挡一个短时效的 CDN，然后通过 CSR 做千人千面的润色和后续业务逻辑。
Q9：你如何看待 SSR 的未来发展？是会随着硬件的升级逐步淘汰，还是会随着技能的更新加倍盛行？
刘勇：优化思路是不会过期的，大概某一天我们现在熟习的 SSR 的编程界面变了，譬如当年的 SSR 是用 nunjucks、ejs 之类的模版，现在是 react、vue。未来也会有新的技能涌现，但它很有可能也属于 SSR 的一种实践模式。
刘奎：按照我的履历来看，很多时候新的技能方案大都会考试测验更多的压榨硬件性能，从而得到更好的交互体验，以是任何期间都会存在相对「低端」的设备，这个该当是办理不掉的（笑
在我看来，SSR 最紧张的落地本钱还是在做事真个研发及运维上，这个对付大部分公司的前端团队都是较大的包袱，进而由于 ROI 不高导致 SSR 落地困难。但是，随着 Serverless 的发展，涌现了许多险些 “零运维” 的 Serverless 方案，可以极大地降落前端团队的运维本钱。同时，从社区的趋势来看，近年来盛行的各种前端框架都在拥抱 Edge 和 SSR，例如 Next.js、remix-run、Qwik、Astro、Fresh 等。同时，React 等库也推出了性能表现更佳的流式 SSR 能力。通过这些框架技能的集成和迭代，不仅可以显著降落前端工程师开拓 SSR 运用的研发本钱，还能进一步提升传统 SSR 的性能效果。
从目前的趋势来看，我以为 SSR 会随着研发及运维本钱的降落，变得加倍的盛行。
Q10：结合你的项目履历，你会如何评价 SSR 这一模式呢？
刘勇：从前真个历史演进看，是 SSR → CSR → SSR，粗一看彷佛是在开历史倒车，但实际不然。
举个例子，当年前真个 HTML + CSS + JS 都是 all-in-one 的单文件办法，由于那时候前端没有编译能力只能写在一起；随着前端工程化的演进，开拓期拆成多文件办法进行组织，构建时自动处理成为了主流；再进一步又涌现了类似 Vue SFC 这样的单文件办法，这是开倒车么？实在不是，而是随着基建的完善，用户编程界面是可以更贴近直觉的，性能和支配之类的事交给工具去做即可。
因此，我认为 SSR 模式是有真实场景的，但在目前这个阶段，我以为它还有很多切实的性能问题和工程化问题须要办理才能更好的落地。
刘奎：CSR 虽然也能得到比较好的首屏体验，但受限于用户设备的性能，存在着明显的性能天花板。而 SSR 则能更好的借助边缘打算（ESR）、流式渲染等做事端能力，有效的提升性能天花板，在大部分时候会是 Web 运用提升首屏性能的一个有效武器。
当然每个项目和团队都有不同的特点和目标，在选择开拓模式时须要综合考虑各种成分。
对此，你怎么看？你的项目采纳了 SSR 还是 CSR 呢？快来评论区说说你的体验吧～
