原文链接:Understanding SSR with Hydration: Pros, Cons, and Scenarios for Software Architects

  • 渲染:将模板和数据结合起来创建网页内容。
  • 水合作用:通过客户端交互增强服务器呈现的 HTML。

Hydration 是什么

image.png

一个初始的服务器渲染的HTML文件并不具有交互性。必须执行 JavaScript 代码以附加时间监听器,初始化状态,并将页面动态化。将这种交互性添加到静态HTML 的过程称为 hydration 水合

SSR 架构工作流程:

SSR

  1. 客户端请求Web应用程序
  2. 请求触发服务器执行视图的初始渲染,在此过程中,服务器可能会获取一些数据。
  3. 服务器随后发送回初始呈现的静态视图,以及 JavaScript 捆绑包(通常是单页面应用程序框架)和样式资产
  4. 客户端(浏览器)读取静态 HTML 并加载 JavaScript 捆绑包
  5. 加载了 JavaScript 捆绑包后,浏览器可以在客户端上 “水合 Web 应用程序”。水合涉及将事件处理程序附加到现有的 DOM 元素并恢复应用程序状态

通过整个过程,静态 HTML 被转换为单页面应用程序 SPA,这意味着DOM 结构被重复使用,事件处理程序附加到DOM元素,并且应用程序状态在客户端上被恢复,Web 应用程序能够充当SPA

SSR 与水合的优点

  • SEO 优化:确保初始内容易于被搜索引擎爬取和索引,提高可见性和搜索排名。
  • 快速初始加载:服务器端渲染向客户端提供完整的 HTML 文档,从而使加载时间更快。
  • 增强用户体验:水合作用使得丰富的互动性和动态内容更新成为可能,提供了流畅而引人入胜的用户体验。
  • 改进的性能:通过将初始渲染卸载到服务器,客户端设备,特别是那些资源有限的设备,可以更高效地处理应用程序。

水合通过避免重复创建DOM 节点来提高应用程序性能。如果没有启用水合,服务器渲染的 HTML 将销毁并重新渲染应用程序的DOM 这可能导致可见的 UI的闪烁。

这种重新渲染可能会对核心WEB 要素(如LCP)产生负面影响,并导致布局偏移,启用水合作用允许重用现有的DOM ,并防止闪烁

哪些场景可以使用 SSR

  • 电子商务网络应用
    • 产品页面:这些需要被搜索引擎索引以增加可见性,并且应该快速加载以吸引用户注意力。SSR 可以在服务器端呈现产品细节,而 hydration 可以启用动态功能,如添加到购物车、产品放大和评论。
    • 分类页面:分类或列表受益于 SSR 以实现快速加载和 SEO,同时,Hydration 允许在无需完全重新加载页面的情况下进行排序、过滤和分页。
  • 社交媒体平台
    • 用户动态:社交媒体动态受益于 SSR,可实现快速初始加载和公共内容的 SEO,而 hydration 则实现实时更新、交互元素(点赞、评论、分享)和无限滚动
    • 个人资料页面:SSR 可以首先呈现用户资料和帖子,以便进行 SEO 和快速加载,而 hydration 则允许动态内容更新和互动。
  • 内容管理系统(CMS)
    • 博客文章和页面:SSR 可以在服务器端呈现博客文章,加载速度快且有利于 SEO,而水合支持动态功能,如评论、点赞和内容编辑。
    • 着陆页面:营销和信息着陆页面可以使用 SSR 实现快速加载时间和 SEO,而水合作用使交互元素如表单、动画和动态内容更新成为可能。
  • 用户仪表板和门户
    • 个性化仪表板:SSR 可以在服务器端呈现基本布局和静态数据,实现快速加载,而 hydration 处理动态数据检索、实时更新和交互式小部件。
    • 内部网络和企业门户:SSR 可以确保公共区域的快速加载时间和 SEO,而水合作用可以实现内部消息、通知和数据驱动应用等交互功能。
  • 渐进式网络应用程序(PWAs):
    • 离线优先应用程序:SSR 可以呈现服务器优先内容,以确保快速加载时间,同时水合处理离线功能、缓存和后台刷新。
    • 实时数据应用程序:SSR 可以处理初始应用程序状态的渲染,而 hydration 管理实时数据更新、用户交互和动态内容加载。
  • 复杂形式和多阶段过程
    • 注册和结账流程:SSR 可以在服务器端渲染初始表单或步骤,以减少加载时间,而水合作用则允许验证、动态字段更新和步骤之间的平滑过渡,无需重新加载整个页面。
    • 交互式调查:SSR 可以在服务器端呈现初始调查布局,而 hydration 管理动态问题加载、用户输入验证和进度跟踪。

水合带来的缺点

  • 增加的复杂性:SSR 与 hydration 结合会增加状态管理、服务器和客户端之间的同步以及处理边缘情况方面的复杂性。这可能导致更高的开发和维护成本。
  • 额外的性能开销:由服务器呈现的 HTML 进行水合处理的过程可能导致性能下降,特别是在较慢的网络或较弱的设备上。这可能会抵消 SSR 的一些初始加载时间优势
  • 复杂的开发和调试:由于服务器呈现的 HTML 和客户端 JavaScript 之间的不一致性而引起的问题可能很难解决。开发人员需要精通服务器端和客户端技术,这增加了学习曲线和错误风险。
  • 资源管理:需要一个强大的基础设施,以确保服务器能够处理每个请求的 HTML 渲染负载。