我正在开发一个项目，涉及到React、Redux和其他前端库。我读了很多关于服务器端渲染的好处，感觉很酷。所以我同时实现了服务器端渲染和客户端渲染。我对这两种方式进行了性能比较，但是我发现服务器端渲染存在性能问题，不确定我是否做错了什么。我发现服务器端渲染需要大量的CPU / 内存资源，会严重拖慢我的服务器。即使在简单页面上，每个请求都需要处理包含store初始化、虚拟DOM、CSS提取在内的复杂React、Redux逻辑。当流量高峰时，情况变得更糟糕，有时甚至停止响应。我的项目很复杂，页面有很多组件，还有很多reducers、middlewares。我知道我们可以通过使用缓存来缓解这个问题，但是在我的项目中，有数千个页面需要根据url参数进行动态渲染，并且不能变旧，因此缓存不是可行的解决方案。即使使用缓存，如果它命中缓存，渲染页面的速度也比客户端渲染快。一旦缓存过期，服务器再次变慢。此外，我感觉体验有点奇怪，因为从内容开始渲染到完成所需的时间比客户端渲染要长得多。总体上，客户端渲染感觉更流畅。有什么想法吗？
1个回答
3
仅作为客户端（CSR）库使用的React有效地使您的服务器从除了提供文件之外的所有工作中卸载出来。所有计算都在客户端（浏览器）上使用它们的CPU（解析和执行JavaScript，渲染React树）和网络资源（获取API端点，解析响应）进行。
请注意，即使流量增加，所有工作仍然良好分布在所有客户端和服务器之间，服务器只需要跟上文件服务即可。
此外，CSR解决方案至少还有一个可能会被轻易忽视的优点。一旦执行了初始JavaScript捆绑包并发现了资源，浏览器仍然可以在获取网络资源（如图像）的同时解析和执行其余代码。这样，代码流和数据流就可以（有点）并行执行。
这在服务器上发生了戏剧性变化。要呈现组件树（ReactDOMServer.renderToString/.renderToNodeStream），您需要首先获取初始呈现所需的所有资源（引入延迟），并将它们注入到应用程序的顶部。否则，React只会呈现不依赖于任何数据的应用程序部分。呈现大型组件树是受CPU限制的任务。
而且，注入的状态应该被序列化并与呈现的HTML一起传输到客户端，以便React可以进行水合。这需要将更多数据通过网络发送到客户端。
总之，在启用SSR的情况下，您的服务器所做的工作比仅使用CSR时要多得多。
- catchergeese
1
1感谢回复。根据我的经验，SSR实际上会因为将过多的工作放在服务器上而导致性能下降。在现实世界中，我无法想象需要多少台服务器来处理这样的负载。渲染React比纯HTML需要更多的资源。然而，我仍然想知道是否有任何优化方法或者我忽略了什么，因为很多人都推荐使用SSR。这项技术只是实验性的还是我漏掉了什么东西？ - undefined
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接