SSR服务器端渲染的优缺点是什么？何时使用它，何时选择其他？

照片由 Daniel H. Tong 在 Unsplash 上拍摄

什么是 SSR？为什么你应该关心它？

SSR 代表服务器端渲染。我将主要讨论 React，但我想它对其他框架也同样适用。

如果您关心以下情况，则需要 SSR：

SSR 就像一个新维度。无论你使用什么，都需要重新配置以适应 SSR。

你用什么componentDidMount来获取数据？你需要使用类似getInitialPropsnext.js 或 after.js 之类的工具，或者像 Redux 这样的状态管理库来让它在服务器上工作。
你使用路由器吗？你需要在服务器上进行配置
你使用国际化吗？你需要在服务器上进行配置
你使用 HMR 吗？你需要重新加载浏览器和服务器的代码。
你使用 React-helmet 吗？你需要在服务器上进行配置
你使用 react-loadable 了吗？你需要配置服务器来传递使用的模块，以便客户端可以预加载它们。
你使用 Redux 吗？你需要序列化 store 并将其传递给客户端
你使用 CSS-in-JS 吗？你需要配置它，让它在服务器上生成关键 CSS，并将其内联到 HTML 响应中。

别误会，这些都是可以解决的。Next.js 和 Razzle 解决了大部分问题。我想向你展示的是，SSR 在某种程度上把所有东西都翻了一番（另一个维度），而且大多数时候都需要所有东西都使用样板代码。

好的。现在我们来谈谈福利。

如果您正在进行 SSR，这并不意味着您将获得良好的开箱即用的有意义的首次绘制。

你的设置是否设置了良好的“首字节时间”？如果你的服务器速度慢或过载，就会出现问题。确保使用最新节点，压缩服务器代码，使用流式渲染，并优化子查询（数据库或网络）。
您是否提供了关键 CSS？否则，浏览器无法开始渲染页面。
您使用网页字体吗？如果是，您对其进行了优化吗？
你的服务器离客户端近吗？如果你的服务器在欧洲，而客户端在日本，那么 SSR 就帮不上忙了。从 CDN 提供“shell”服务可能比 SSR 更快（从印象角度来看）。如果由于法律限制，你无法将服务器移近客户端，该怎么办？
你确定没有不必要的重定向吗？否则，在慢速 3G 网络上重定向会毁掉你辛苦争取到的几毫秒。

SSR 并非解决首次有效渲染问题的灵丹妙药。如果你的后端很慢或很远，你需要检查“shell”和 CDN 是否能更好地工作。你可以使用类似react-snap 的工具来预渲染静态页面，并为其他页面生成“shell”。

如果您的网站更倾向于静态化，您可以使用预渲染而不是 SSR。查看react-static、gatsby或react-snap。

这里有 3 个选项：

如果可以，请选择预渲染。如果你只关心 SEO，那么按需预渲染功能随时都可以轻松添加。

这个问题比较棘手。这真的取决于你想达到多大的降级吗？

有些功能没有 JS 的话会很难实现，比如组合框或地图

SSR 很好，不妨一试。另外，请确保你的用户确实能从中受益。
如果你无法使用 SSR，可以尝试预渲染器，有时它是最简单的选择。

在twitter和github上关注我。