使用 JAMStack 回归静态：实现更佳用户体验和 Web 性能的范式转变

几年来，Web 技术领域涌现出一系列新的解决方案。静态网站生成器、无头 CMS、内容基础设施……这些解决方案共同构成了一股全球趋势。“静态趋势”、“JAMStack”等等，虽然有不少名称，但没有一个真正涵盖 Web 应用架构的全新方案，也没有一个真正体现出 Web 本质的回归。

我们从哪里来？

当用户尝试访问网页时，他们的浏览器会向托管该网页的服务器发出请求。服务器要么立即返回页面，完全按照存储的内容返回，要么根据需求执行代码生成页面。

尽管 Web 最初被认为是一堆静态文件的集合，但服务器端编程语言出现得很早，并且如今已被广泛使用。根据 W3Techs 的数据，超过 80% 使用服务器端语言的服务器运行的是 PHP。而提供不支持动态语言的服务器的托管服务提供商几乎为零。

然而，动态生成 HTTP 响应在 Web 性能方面存在显著劣势。动态网页通常基于 Web 服务器构建，该服务器会加载执行语言来分析 HTTP 请求，通常会请求数据库（有时位于数据中心的另一台服务器上）和第三方服务，并填充逻辑模型，该模型通过模板集合展现自身，最终生成 HTML 响应。因此，动态网页的首次字节时间(TTFB) 会更长。

为了优化服务器响应时间，多年来出现了许多缓存解决方案。第一个请求页面的用户需要承担缓存生成的成本，但结果会存储在一个或多个代理服务器上，有时还会在世界各地的不同位置同步。这些缓存页面随后会响应所有类似的请求，确保快速一致的交付。如今，我们可以找到软件缓存解决方案（例如Varnish）、平台和基础设施（内容分发网络）。所有这些解决方案都确保动态内容可以恢复为静态内容。江山易改，本性难移。

然而，使用静态内容还有其他优点。

如果要交付静态页面，必须事先对其进行编译。这个看似微不足道的事实，却改变了一切。事实上，编译正是静态页面的主要优势：将复杂性从生产环境转移到集成过程。

如果您的页面由 Web 服务器提供，而无需先生成，则无需执行服务器端语言。因此，许多攻击向量会消失。如果您既没有数据库，也没有服务器端执行语言，就无法通过注入恶意代码来窃取机密数据。

无需在服务器上执行代码也意味着每次 HTTP 响应的 CPU 消耗非常低，从而带来更佳的可扩展性。但请注意：正如我们将看到的，部署是一个关键因素，并且会消耗 CPU 时间。弹性是另一个优势。在最坏的情况下，错误可能在生成过程中发生，但可以在部署之前检测到。例如，由不良贡献导致的技术问题不再影响访问者浏览的网站。在最坏的情况下，网站并没有崩溃，只是内容没有及时更新。

然而，这些优势只是冰山一角。静态化趋势可以彻底改变网站的发布方式。难怪Smashing Magazine 已经迁移了！

静态是一种分发模式。它的技术栈是什么？

静态站点生成器 (SSG) 是一种在本地执行或作为服务执行的软件，它使用一些数据源进行模型和配置，以及包含业务逻辑的模板来生成（有时部署）静态网站。

SSG 市场蓬勃发展，每月都会推出两款新产品。大多数 SSG 会根据一组文件生成网站，这些文件通常使用Markdown或 Asciidoc 等轻量级语法编写。转换为 HTML 的任务由模板引擎（Liquid、Go Template、Nunjucks）负责逻辑，以及转换器（kramdown、commonmark、blackfriday、Asciidoctor等）负责将标记转换为 HTML。SSG 只不过是网站生成的技术协调器，因此，它主要为精通其工作原理的前端开发人员提供平台。

诚然，SSG 是技术工具，并非内容管理系统 (CMS) 的替代品。然而，当你关注外部数据源时，它们会变得非常有趣，因为这样一来，我们就可以讨论那些不用于渲染 HTML，而只用于存储和公开数据的 CMS。它们被称为 Headless CMS。

无头 CMS 是：

一种存储数据的方式
CRUD UI
数据 API
“什么是无头 CMS？ ”，Chris Coyier

而且它们通常可以通过你常用的系统获取。例如，WordPress 有一个REST API。Drupal有一个专门的工作组在开发 Headless。然而，软件和服务市场正在蓬勃发展。

我们究竟为什么要将贡献环境和生成工具分开呢？因为关注点分离。

开发团队摆脱了维护数据库的负担，可以专注于平台的技术发展和资产管道，而贡献团队可以完善​​其内容。

贡献者可以处理易于存储和修改的平面文件。他们与开发人员唯一的共同语言是每个文件中传递的元数据，通常使用Front-Matter编写。他们可以使用自己选择的编辑工具或服务，甚至可以使用能够确保协作的工具或服务。此外，当他们想要查阅文件历史记录、合并多个版本或创建分支以编写不想立即发布的内容时，源代码版本控制功能也为他们带来了便利。

内容贡献完成后，网站的生成和部署通常由基础设施的同一组件进行。为了监控此步骤的性能，您需要评估编译服务器在生成和部署过程中的性能（时长、CPU 消耗、内存）。但这还不是全部：请记住还要监控目标基础设施（由一台或多台服务器组成），因为复制任务可能非常繁琐。

这意味着我们不再处于一个以同时访问用户数量为主要可扩展性指标的系统。DevOps 必须彻底改变思维方式，创建一个能够适应贡献者所要求的生成和部署频率的系统。

这时，各种参与者又出现了。实际上，最知名、也可能是最有效的可能是 Netlify。它简洁的界面只需点击几下即可帮助您连接源代码存储库。然后，Netlify 将为每次提交动态生成并部署您的网站。

一个无头CMS、一个SSG和一个部署编排器：我们现在拥有了完整的后端堆栈。然而，我们生成的仍然是一个静态网站，没有任何个性化内容。鉴于用户对动态性或个性化的需求从未如此强烈，我们难道不应该犯一个错误吗？

静态的？没那么多。

我们已经看到，这个静态堆栈生成的标记非常标准化。为了引入动态性和个性化，我们需要导入通过 API 传递的数据，并在客户端进行处理，因此需要依赖 JavaScript。

这个新的“ JavaScript + 松散耦合的API +标记”堆栈有一个名称：JAMStack和几个主要参与者，每个参与者都提供一组特定的服务：用于支付的Stripe 、用于即时搜索的Algolia 、用于评论的Disqus或IntenseDebate 、用于电子商务的Snipcart 、用于媒体管理的Cloudinary或Twicpics 、用于表单的Formspree或Staticman ……请注意，并非所有这些产品都是为 JAMStack 设计的：您可以从服务器端完美地使用 Algolia 超快的 API。

JAMStack 带来了真正的范式转变。如今，网站比以往任何时候都更像是一个外壳，各种服务（无论是自托管的还是第三方的）都会动态注入其中。甚至可以依赖多个服务来实现同一目的，并在主服务不可用时切换到备用服务。

既然你把大量精力转移到了前端，为什么不更进一步，使用 Vue、Angular 或 React 等单页应用 (SPA) 框架构建你的网站，或者将其转换为一个完整的渐进式 Web 应用 (PWA)，并设计为“离线优先”？这并非 JAMStack 固有的特性，而是由开发范式的改变所促成的。

然而，对于用户来说，差异很小。尝试在这个网站上搜索产品。你的体验与 PHP 网站有什么不同吗？

对于贡献者来说，范式转变改变了一切，因为它将贡献平台与网站托管平台分离开来。有些人会倾向于使用具有写作辅助功能（例如批改、建议、文档贡献）的软件。而另一些人则会对可定制的在线贡献平台感到满意。假设内容的存储与解决方案无关，那么每个人都可以使用自己喜欢的工具，而不会干扰他人的使用。

但有些产品更进一步，将投稿体验提升到极致。投稿人可以享受量身定制的解决方案，享受丰富的多媒体投稿选项，同时又不会对发布流程或目标网站的性能造成任何影响。

动图

静态还是动态？Tomayto，tomahto

尽管 JAMStack 方法具有许多优势，包括安全性、性能、扩展性、开发和贡献经验，但它也意味着不容忽视的新风险。

第一个风险是迷失在琳琅满目的 Headless CMS、生成器和服务平台中。请花时间评估您的需求，因为每种解决方案都有其优缺点。例如， Jekyll是一个著名的 SSG，用 Ruby 开发，文档齐全，但速度相当慢。另一方面， Hugo是一个速度更快的 SSG，但对于新手来说，操作起来也更复杂。如果您不频繁发布内容，那么为了达到相同的效果，生成时间真的那么重要吗？

还请注意所选服务的使用条款。在 Dareboost，我们经常警告用户谨防第三方脚本滥用。如果您需要评论并使用 Disqus，您是否同意动态注入他们的广告？如果您遵循了我们关于内容安全政策的建议，希望您不必担心这一点。

另一个风险同样重要：即使您的网站不太容易出现安全问题，它仍然可能通过其依赖的 API 受到攻击。您绝对需要确保您使用的脚本未被篡改，并且与第三方服务的每次交互都是通过 HTTPS 安全的。确保您的自托管 API 符合所有安全最佳实践，并毫不犹豫地仔细检查您所依赖的第三方服务的 SLA。

最后，这些 API 还必须根据支持它们的组织的可持续性进行仔细选择。如果您将关键功能的责任转移给第三方服务，最好确保它们能够持续并保持稳定的质量水平。一个好方法是监控能够模拟与您的网站功能交互的用户旅程。

充满机遇的新土地

一旦你完全掌握了具体的风险并制定了适当的工作流程，JAMStack 仍然会为你带来机遇。从 Headless CMS 或 SSG 解决方案迁移到另一个解决方案的成本通常很低。你可以轻松地从本地文件贡献切换到 Netlify CMS、Forestry、Contentful 或 Prismic 等内容基础设施，这让你能够快速评估最适合你需求的解决方案。创建静态站点需要时间，并且需要一个涉及协调多个解决方案的架构。今天，它可能看起来很复杂，但回想一下你的第一个动态站点：选择主机、掌握 FTP、处理 Web 服务器日志……这一切都不容易。你将逐步学习这些逻辑。对于经验丰富的 JAMStack 用户来说，这变得水到渠成。

Netlify 等统一平台虽然存在集中化风险，但仍然提供了令人印象深刻的服务目录：网站生成和部署、DNS 注册、SSL 证书和表单管理、无服务器功能、内容分发网络……

足够多的开箱即用功能，让您的前端团队专注于前端开发和 Web 性能优化。如此短的首次字节响应时间 (TTO)，让团队能够通过速度指数的测量，完全专注于用户体验！

感谢 Erin Symons、Frank Taillandier和整个jamstatic.fr 社区、Bud Parr、Nicolas Hoffmann以及我的同事Philippe Guilbert和Damien Jubeau的时间和建议。

其他资源

• “为什么静态网站生成器是下一个大热门”，Matt Biilmann
• “不要把 Contentful 的内容基础设施称为‘CMS’ ”，Michelle Gienow

如果你喜欢这篇文章，欢迎点赞或骑上独角兽！你也可以在 Medium 上点赞。