SSR vs SPA | 哪个该使用？

Source: Dev.to

介绍

本文的目标是指导您为您的应用程序选择最佳技术。

当我开始职业生涯时，我使用 JSF（JavaServer Faces），这是一种 MPA（多页应用），服务器向浏览器交付完全渲染好的 HTML，仅用于显示。用户的每一次交互都会产生一次新的请求，进而导致页面重新加载。

不久之后，Ajax 爆发式流行——与 jQuery 一起——并开始允许仅更新页面的部分内容。这为应用带来了更多的动态性，显著减少了完整 reload 的次数，提升了用户体验，同时仍保留了 server‑side 模型。

随后出现了一次突破。个人设备变得更强大，浏览器也在进化，这为使用客户端作为界面渲染的主要责任提供了空间。在这种背景下，SPA（单页应用）模型获得了人气，并开始主导前端开发。

SPA 将后端定位为 API 提供者，更清晰地分离了前端和后端。这一变化帮助降低了基础设施成本，提升了架构灵活性，但也带来了新问题：应用的首次加载变慢，公共页面的 SEO 明显下降。

正是在这种情形下，SSR 作为一种尝试出现，旨在解决 SPA 的问题，而不是简单回到过去的模型。页面在服务器端渲染，确保更快的初始加载和更好的索引，但在首次交付后，它在浏览器中表现得像一个 SPA。

随着时间的推移，变化的不仅是技术本身，还有我们在服务器、客户端、性能和用户体验之间平衡职责的方式。

我应该使用哪种？

在决定使用 SPA 还是 SSR 之前，首先需要回答一些关于项目的基本问题：

• 这个应用的目标用户是谁？
  是内部系统、管理后台、需要身份验证的工具，还是面向最终用户的公共应用？

• 我的预算是多少？
  我是否有资源维护更复杂的基础设施，包括服务器渲染、缓存以及可能的额外扩展成本？

• 我需要首屏渲染快速吗？
  首次可见内容的时间对用户体验是否至关重要？

• SEO 对页面重要吗？
  内容是否需要被搜索引擎索引，或在社交媒体上分享时需要合适的预览？

• 应用的规模有多大？
  即使首屏渲染需要快速，也并非所有规模和复杂度的应用都需要使用 SSR。

谁适合使用 SPA

当应用更像软件而不是网站时使用 SPA。在这些场景下，首次渲染时间和 SEO 不是关键因素。

示例

• 需要身份验证才能访问的内部工具或应用。
  功能和信息并非面向公众，而是限制给特定用户，例如内部团队、合作伙伴或已认证的客户。

谁适合使用 SSR

使用 SSR 当应用更像网站而不是软件。在这些场景下，首次渲染时间和 SEO 是项目成功的关键因素。

示例

• 企业站点、博客、内容门户、电子商务和着陆页。
  内容需要快速可用，易于被搜索引擎索引，并在社交媒体分享时生成正确的预览。

结论

在我的职业生涯中，我看到一些小型应用在验证单页应用（SPA）是否能满足需求之前，就采用了服务器端渲染（SSR）。我也见过一些访问量很大的小型应用需要 16 台服务器来处理请求，尽管只有一小部分内容是公开的，绝大多数内容需要身份验证。在这种情况下，可以将其拆分为两个独立的应用，从而减少服务器数量。

最终，最好的技术是能够满足业务需求的技术，能够在成本和收益之间取得正确的平衡。