我刚刚学会了最近的反应，打算将其用于下一个项目。我已经遇到过几次反应服务器端渲染，但是想知道为什么在“现代时代”我们仍然需要它。
在本文中，它认为通过服务器端渲染，用户不必等待从CDN或其他地方加载这些js即可看到初始静态页面，并且该页面将在js到达时恢复功能。
但是在使用webpack生产配置和gzip构建之后，整个捆绑包（包括react，我的代码和许多其他东西）仅占用40kb，而我使用的是aws CDN。对于我的情况，我不太清楚使用服务器端渲染的原因。
所以问题是，如果在gzip之后生成的javascript包是如此之小，为什么人们仍然使用服务器端渲染？
可以在初始HTTP请求的响应中交付应用程序的渲染视图。在传统的单页Web应用程序中，第一个请求将返回，浏览器将解析HTML，然后对脚本进行后续请求- 最终将呈现页面。这些请求仍然会发生，但是它们永远不会妨碍用户查看初始数据。
这对于快速的Internet连接并没有太大的影响，但是对于网络覆盖率较低区域中的手机用户而言，这种最初的数据渲染可以使应用程序渲染速度提高20-30秒。
具有静态数据的视图也可以在网络级别缓存，这意味着可以以很少的计算开销为React应用程序的渲染视图提供服务。
当搜索引擎搜寻器到达网页时，将提供HTML并检查静态内容并建立索引。在纯客户端Javascript应用程序中，没有静态内容。一旦加载并运行了适当的脚本，就会动态创建和注入所有文件。
与React不同，大多数框架无法将其组件图序列化为HTML，然后对其进行重新充气。他们必须使用更复杂的方法，该方法通常涉及在服务器的无头浏览器中呈现其页面，然后在搜寻器请求时提供该版本。
React可以将组件树从服务器端JS环境（例如Node.js）呈现为HTML字符串，然后立即将其提供。无需无头浏览器或其他复杂功能。
它还允许您编写可以正常降级并最终可用作瘦客户端的应用程序。这意味着处理在服务器上进行，并且可以在禁用Javascript的浏览器中使用该应用程序。那是否是一个需要考虑的重要市场是另一个争论。
