SSR 它到底香不香？细数 SSR 的利与弊-低调大师

SSR 它到底香不香？细数 SSR 的利与弊

2020-10-12 813

关注「前端向后」微信公众号，你将收获一系列「用心原创」的高质量技术文章，主题包括但不限于前端、Node.js以及服务端技术

一.SSR 简介

SSR（Server-Side Rendering）并不是什么新奇的概念，前后端分层之前很长的一段时间里都是以服务端渲染为主（JSP、PHP），在服务端生成完整的 HTML 页面

摘自图解 SSR 等 6 种前端渲染模式

之所以要在服务端完成组件渲染工作，是因为有性能与可访问性两大优势

二.2 大优势

性能

与 CSR（Client-side rendering）模式相比，SSR 的性能优势体现在 2 方面：

网络链路

省去了客户端二次请求数据的网络传输开销
服务端的网络环境要优于客户端，内部服务器之间通信路径也更短

内容呈现

首屏加载时间（FCP）更快
浏览器内容解析优化机制能够发挥作用

网络链路上，由服务端发出接口请求，将返回数据随 HTML 响应内容一次性传递到客户端，比 CSR 二次请求更快。并且服务端网络传输速度更快（可以有更大带宽）、通信路径更短（可以同机房部署）、通信效率也更高（可以走 RPC）

内容呈现方面，CSR 的 HTML 大多是个空壳儿：

<!DOCTYPE html>
<html>
<head>
    <title>My Awesome Web App</title>
    <meta charset="utf-8">
</head>
<body>
    <div id="app"></div>
    <script src="bundle.js"></script>
</body>
</html>

客户端拿到这种 HTML 只能立即渲染出一页空白，二次请求的数据回来之后才能呈现出有意义的内容，而 SSR 返回的 HTML 是有内容（数据）的，客户端能够立刻渲染出有意义的首屏内容（First Contentful Paint）。同时，静态的 HTML 文档让流式文档解析（streaming document parsing）等浏览器优化机制也能发挥其作用

关键区别是 SSR 不依赖客户端环境，包括网络环境和设备性能，即使用户的网络情况很糟（弱网）、设备性能很差（廉价、老旧设备），服务端渲染同样能够保障与最优用户环境（Wi-Fi 网络、高端设备）下相近的内容加载体验

可访问性

可访问性（accessibility）从两方面理解：

对人：古老、特殊的用户设备，比如禁用了 JavaScript
对机器人：爬虫程序等，典型的，搜索引擎爬虫

前者一般不必太过在意，后者要关注两大“客户”：

搜索引擎：SEO
社交媒体：抓取页面内容展示缩略信息（比如 Twitter 卡片等）

对 PC 站点而言，保证搜索引擎能够正确索引、准确理解页面内容，有重要的商业价值（搜索结果靠前，曝光量更大）。移动端虽不必考虑搜索引擎爬取，但也有类似的社交分享需求，社交媒体会抓取目标页面中的图片等作为缩略信息

P.S.诚然，有些搜索引擎能够正确爬取重 CSR 的 SPA，但不是全部，并且一大批社交媒体大都只从响应 HTML 中提取部分内容作为缩略信息，动态渲染 HTML（部分）内容的需求真切存在

虽具有这些优势，但 SSR 却远不如 CSR 应用广泛，是因为 SSR 面临着 6 大难题

三.6 个难题

难题 1：如何利用存量 CSR 代码实现同构

为了降级、复用、降低迁移成本等目的，通常会采用一套 JavaScript 代码跨客户端、服务端运行的同构方式来实现 SSR，然而，要让现有的 CSR 代码在服务端跑起来，先要解决诸多问题，例如：

客户端依赖：分为 API 依赖和数据依赖两种，比如window/document之类的 JS API、设备相关数据信息（屏幕宽高、字体大小等）
生命周期差异：例如 React 中，componentDidMount在服务端不执行
异步操作不执行：服务端组件渲染过程是同步的，setTimeout、Promise之类的都等不了
依赖库的适配：React、Redux、Dva 等等，甚至还有第三方库等不确定能否跑在 universal 环境，是否需要跨环境共享状态，以状态管理层为例，SSR 要求其 store 必须是可序列化的
两边共享状态：每一份需要共享的状态都要考虑（服务端）如何传递、（客户端）如何接收

难题 2：服务的稳定性和性能要求

与客户端程序相比，服务端程序对稳定性和性能的要求严苛得多，例如：

稳定性：异常崩溃、死循环
性能：内存/CPU 资源占用、响应速度（网络传输距离等都要考虑在内）

因此面临后端专业性问题，Demo 级的 SSR 可能并不难，但高可用的 SSR 服务却绝非易事，如何应对大流量/高并发，如何识别故障，如何降级/快速恢复，哪些环节需要加缓存，缓存如何更新……

难题 3：配套设施的建设

SSR 最核心的部分是渲染服务，但除此之外还要考虑：

本地开发套件（校验 + 构建 + 预览/HMR + 调试）
发布流程（版本管理）

一整套的工程设施，在 SSR 模式下都需要重新考虑

难题 4：钱的问题

引入 SSR 渲染服务，实际上实在网络结构上加了一层节点，而大流量所过之处，每一层都是钱：

Most importantly, SSR React apps cost a lot more in terms of resources since you need to keep a Node server up and running.

将组件渲染逻辑从客户端改到服务器执行，计算资源的成本必须考虑在内

难题 5：hydration 的性能损耗

客户端接到 SSR 响应之后，为了支持（基于 JavaScript 的）交互功能，仍然需要创建出组件树，与 SSR 渲染的 HTML 关联起来，并绑定相关的 DOM 事件，让页面变得可交互，这个过程称为 hydration

hydration 所需加载、执行的 JavaScript 代码不见得比 CSR 模式少多少，这部分工作在客户端执行，受限于用户设备的性能，在较差的设备下可能会造成可感知的不可交互时间：

CSR：可交互但是没有数据（还在异步请求数据，可能会持续很长）
SSR：有数据但是不可交互（拉到 JS 后开始 hydrate 的过程，能看到内容但是不可交互，一般不会持续很长）

富交互的场景下，后者不一定比前者用户体验更好

难题 6：数据请求

服务端同步渲染要求先发请求，拿到数据后才开始渲染组件，那么面临 3 个问题：

数据依赖要从业务组件中剥离出来
缺失客户端公参（包括 cookie 等客户端会默认带上的 header 信息）
两边数据协议不同：服务端可能有更高效的通信方式，比如 RPC

目前主流的 CSR 模式下，数据依赖与业务组件存在紧耦合，要由服务端发起的数据请求全都掺杂在组件生命周期函数中，剥离数据依赖意味着需要同时改造 CSR 代码。公参、数据协议等差异对代码复用、可维护性也提出了一些新的挑战

四.应用场景

无论首屏加载性能还是可访问性，都是对内容密集型页面才有意义，而对于交互密集型的页面，SSR 所能提前渲染的内容不多，对用户意义不大，SEO 的必要性也值得商榷。因此，SSR 适用于偏静态的内容展示场景，典型的，商品详情、攻略、文章等图文混排的场景

另一方面，不一定非要 100% SSR，渲染特定页面，甚至只渲染个页面框架也是不错的应用：

“Application Shell” is an excellent concept. But sometimes, we might need to render a part of the page in the server. It could be the header with user info. In such cases, you need server-side rendering.

参考资料

A PAIN IN THE REACT: CHALLENGES BEHIND SSR
Why it’s tricky to measure Server-side Rendering performance：angular SSR 与 CSR 对照实测，数据可参考
Hey Next.js, Is Server Side Rendering Dead?

联系我

如果心中仍有疑问，请查看原文并留下评论噢。（特别要紧的问题，可以直接微信联系 ayqywx ）

本文分享自微信公众号 - 前端向后（backward-fe）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

微信关注我们

原文链接：https://my.oschina.net/u/4581386/blog/4669142

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

原创 | codeforces 1425E，一万种情况的简单题

点击上方蓝字，关注并星标，和我一起学技术。大家好，欢迎阅读周末算法题专题。我们今天选中的是codeforces 1425场比赛的E题，这是一场印尼多校联合的ICPC的练习赛。ACM赛制，难度也比较近似。我们今天选择的是其中的一道Medium难度的题，由于ACM赛制参赛人数相对较少，全场只有157人通过。但实际难度并不大，大约和一般比赛的C题接近。链接：https://codeforces.com/contest/1425/problem/E 废话不多说，我们来看题意。题意有一个人在玩一个离子激活的游戏，题目的背景是模拟的化学当中的离子能量跃迁。在化学当中，离子吸收能量可以从低能态跃迁到高能态，并且放出一定的能量。现在有N粒离子排成一排（下标1-N），每一个离子都有自己的能量参数。也就是吸收多少能量可以跃迁，并且跃迁之后会放出多少能量。还有一个特殊的性质就是这些离子之间带有连带关系，默认的连带关系是第i个离子与第i+1个离子连带。当i离子跃迁的时候，即使i+1的离子没有吸收能量也会发生跃迁。其中第N个离子无法建立连带关系。现在这个人获得了K次改变离子之间连带关系的能力，它必...

2020-10-10

486

点击蓝色“Java建设者”关注我哟加个“星标”，及时阅读最新技术文章扉页解读：特拉法尔加·罗和贝波，于两年前作者自己的 Githubhttps://github.com/crisxuan/bestJavaer 已收录此文见文末原文链接这是Java建设者的第 123 篇原创文章汇编代码是计算机的一种低级表示，它是一种低级语言，可以从字面角度去理解它，包括处理数据、管理内存、读写存储设备上的数据，以及利用网络通信等。编译器生成机器码经过了一系列的转换，这些转换遵循编程语言、目标机器的指令集和操作系统。指令集指令集就是指挥计算机工作的指令，因为程序就是按照一定执行顺序排列的指令。因为计算机的执行控制权由 CPU 操作，所以指令集就是 CPU 中用来计算和控制计算机的一系列指令的集合。每个 CPU 在产出时都规定了与硬件电路相互配合工作的指令集。指令集有不少分类，但是一般分为两种，一种是精简指令集，一种是复杂指令集。具体描述如下精简指令集精简指令的英文是 reduced instruction set computer， RISC，原意是精简指令集计算，简称为精简指...

2020-10-12

492

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。