随着
网站建设技术的不断发展，静态渲染已经不能满足现在高要求的网站建站了，在本文中我们将突破静态渲染的界限，并学习如何将其应用于个性化内容，这种新模式被称为“分段渲染”。
如果您认为静态渲染仅限于对您网站的每个用户都相同的通用公共内容，那么您绝对应该阅读这篇文章。分段渲染是 Jamstack 的一种新模式，可以让您静态渲染个性化内容，无需任何类型的客户端渲染或每个请求的服务器端渲染。有很多用例：个性化、国际化、主题化、多租户、A/B 测试……今天的工作是以最佳性能实现此功能。让我们看看如何做到这一点。提示：我们将介绍一种名为“分段渲染”的新模式。
使用现代 JavaScript 框架呈现网页的多种方式，Repairing Magazine 用户界面依赖于现代 JavaScript 库 React。与其他类似的 UI 库一样，React 提供了两种呈现内容的方式：客户端和服务器端。客户端呈现 (CSR) 发生在用户的浏览器中。过去，我们会使用 jQuery 来做 CSR。服务器端渲染发生在您自己的服务器上，无论是在请求时 (SSR) 还是在构建时（静态或 SSG）。SSR 和 SSG 也存在于 JavaScript 生态系统之外。例如，想想 PHP 或 Jekyll。
这样是有效的，但它是最好的方法吗？您的服务器必须为每位读者提供诙谐的笑话。如果有任何事情导致 JavaScript 代码失败，付费用户将无法获得乐趣，并且可能会生气。如果用户的网络速度慢或计算机速度慢，他们会在下载笑话时看到一个丑陋的加载程序。请记住，大多数访问者通过移动设备浏览！随着 API 调用次数的增加，这个问题只会变得更糟。请记住，浏览器只能并行运行少量请求（通常每个服务器/代理 6 个）。服务器端渲染不受此限制，并且在从您自己的内部服务获取数据时会更快。
我们不再依赖客户端 JavaScript。但是，为每个请求呈现文章并不节能。Time To First Byte (TTFB) 也增加了，因为我们必须等待服务器完成其工作才能开始看到一些内容。我们用更丑陋的空白屏幕替换了丑陋的客户端加载程序！现在我们甚至为此付出了代价！“stale-while-revalidate”缓存控制策略可以通过提供页面的缓存版本直到它被更新来减少 TTFB 问题。但它不适用于个性化内容，因为它只能缓存每个 URL 的一个页面版本，而不考虑 cookie，并且无法处理提供付费内容所需的安全检查。
在这一点上，您遇到了我所说的“富客/差客户”问题：您的高级用户获得了最差的性能，而不是获得了最好的。根据设计，与静态渲染相比，客户端渲染和按请求服务器端渲染涉及最多的计算，静态渲染在构建时只发生一次。我认识的 99% 的网站都会选择 CSR 或 SSR，并遭受富客/穷客问题的困扰。
