我刚刚学会了最近的反应,打算将其用于下一个项目。我已经遇到过几次反应服务器端渲染,但是想知道为什么在“现代时代”我们仍然需要它。
在本文中,它认为通过服务器端渲染,用户不必等待从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的浏览器中使用该应用程序。那是否是一个需要考虑的重要市场是另一个争论。