出品 | OSC开源社区（ID：oschina2013)有研究发现，网站加载时间每增加一秒，用户便会流失 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 类似的效果，可以采取以下方案优化：

首屏页面静态资源优化：通过代码切割 & 懒加载等手段，确保首屏需要的 JS/CSS 是最小化的版本，并通过内联等方式直接打到 HTML 中，减少首屏渲染需要的网络请求；

缓存和预加载：利用客户端的缓存及预加载等机制，提升二次访问速度；

使用更轻量的框架：选择更轻量的前端框架，从而减少首屏的 JS 体积，提升加载速度；

优化关键接口响应速度：优化首屏需要的关键内容的接口响应速度，确保前端能更快的呈现页面。

但如果还有额外的 SEO 诉求，单纯的 CSR 可能很难达到一样的效果。 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 呢？快来评论区说说你的体验吧～