分布式持久渲染 (DPR)

与 Jamstack 类似，Netlify 正在创造这个术语。

如果您想：太好了，我又要学习一个新东西，那么请您知道，尽管分布式持久渲染 (DPR) 确实包含一些新事物，但这实际上是一种简化的推动，并利用了与网络一样古老的理念，就像 Jamstack 一样。

从 Netlify 的首席执行官 Matt Biilmann 的口中听到这方面的内容可能会有所帮助。

在那个简短的视频中，他指出 React 最初非常简单，并解决了许多与 JavaScript 架构相关的明确问题，随着时间的推移，它试图解决更多用例，它变得越来越复杂，并且有失去曾经的简单性吸引力的风险。

Jamstack 也面临着这个问题。它最初的简单性非常吸引人，但随着它不断发展以适应更多用例，事情变得复杂起来。

其中一个复杂之处在于拥有数千个页面的网站。这样的网站可能会有非常缓慢的构建时间。很高兴看到框架解决了这个问题（谷歌“增量构建 {您最喜欢的框架}”），但是，如果您更改网站页脚中的一个链接，您将根据该更改重建整个网站。

因此，与其在构建过程中构建数千个页面，不如您只是… 不构建。反正直到页面被请求一次。这就是DPR.

Zach Leatherman 正在这样操作。他发现他的网站上的一个地方，每次构建时都会生成大约 400 个页面，并告诉 Eleventy，与其在正常的构建过程中构建它，不如将其推迟到云端（实际上，当需要时，lambda 将运行并构建页面）。

推迟这 400 个页面可以节省七秒的构建时间。假设您的网站更戏剧性，例如 16,000 个页面。粗略估计您将节省四分钟。这不仅是时间问题，尽管这是一个大问题。我认为通过这种方式构建可以节省所有电力和长期存储。

这里是 Netlify 的博客文章

就像创造“Jamstack”这个术语并不意味着从头开始发明一个全新的架构一样，将这个概念命名为“分布式持久渲染”并不意味着我们正在创建一个全新的解决方案。

“DPR”这个术语对我们来说是新的，但在很多方面，我们从过去有效的解决方案中汲取灵感。我们只是对它们进行了重新设计，以适应现代 Jamstack 最佳实践。

我喜欢它不像是一件全新的东西。我相信 Netlify 的实现方式绝非易事，但对我们来说，思考它非常容易

• 一些页面照常预构建
• 一些页面没有构建（延迟）
• 当第一次请求未构建的页面时，然后它们才会被构建并缓存，因此无需再次构建它们。

就是这样，真的。

它让我想起了旧的 WordPress 缓存插件的工作方式。当第一次请求一个页面时，它会运行 PHP 和 MySQL 查询以及所有这些内容，然后将结果保存为一个 .html 文件到磁盘以提供后续请求。并非新鲜事物，但仍然高效。

在 Netlify 上使用 DPR 架构的诀窍是使用它们的（测试版）按需构建器，因此 这里是解释所有内容的博客文章，它将带您进入文档等。