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