我想知道无头 WordPress 会落在哪里。 这里所说的“无头”指的是仅使用 WordPress 管理界面，并通过 WordPress REST API 构建面向用户的网站，而不是传统的 WordPress 主题结构。
它是... 大的？ WordPress 的未来？ 还是相对小众的？
需求在哪里？
当然，对它有需求。 我认识很多在做这件事的人。 例如，Gatsby 有一个 gatsby-source-wordpress 插件，允许您从 WordPress 网站获取内容，以一种使用 WordPress REST API 消费内容并将其缓存为 GraphQL 以用于 React 支持的 Gatsby 网站的方式。 正如我所写的那样，它本月已被下载了 59,000 次，总共被下载了 851,000 次。 对于一种特定的网站构建技术来说，这是一个健康的用量。 实际上，每次使用 gatsby-source-wordpress 都在无头方式使用 WordPress - 这正是它的本质/功能。 如果你对此感兴趣，这里有 Ganesh Dahal 深入探讨它.
而这仅仅是一件事，它没有考虑致力于此理念的整个公司和产品。
无头方式的改进目标是什么？
Gatsby 集成很好地解释了为什么任何人都应该考虑使用无头 WordPress 网站。 我会谈到这一点。
许多人主张原因是架构上的。 它将后端与前端分离。 它拆除了单体架构。 作为一个分离的系统，后端和前端可以独立发展。 但是，随着时间的推移，我对这个想法越来越不热衷。 例如，我认为，在像这样的无头设置中简单地替换 WordPress 并用另一个 CMS 替代它，说起来容易做起来难。 此外，我将使用 WordPress API 不仅为网站提供动力，而且为原生阅读应用程序和一些数字互联网连接高速公路广告牌或其他东西提供动力，在我看来，这不是一个流行度暴涨的用例。
我认为人们为 Gatsby 驱动的前端选择 WordPress 后端的主要原因实际上是：他们喜欢 React。 他们喜欢用组件构建东西。 他们喜欢快速页面过渡。 他们喜欢能够将东西托管在 Jamstack 式的地方，并附带所有不错的开发人员预览等。 他们喜欢热模块重新加载。 他们喜欢 Prettier 和 JSX。 他们只是喜欢它，我并不怪他们。 当你享受这种类型的开发人员体验时，回到编写 PHP 模板，需要手动刷新浏览器并维护某种手动构建过程，并不那么吸引人。
Frontity 是另一个产品，旨在将 React + WordPress 整合在一起。 Geoff 和 Sarah 分享了去年在 Vue/Nuxt 方面的实现方法。
但是，无头 WordPress 会比基于与明确结构对齐的 PHP 模板的传统 WordPress 主题模型更受欢迎吗？ 不会。 当然，如果 WordPress 本身支持这个想法，并提供指导、培训和文档，让开发人员更容易采用这种方法，也许会这样。 如果 WordPress 说无头架构是新的方向，我会支持它。 但这些都没有实现。 因此，在某种程度上，它是一件小众的事。
无头方式究竟有多小众？
WP Engine 是一个大型 WordPress 主机，并且有一个名为 Atlas 的东西。 并且他们的努力表明他们正在认真对待这个利基市场。 我不确定 Atlas 的全部功能，但它看起来像一个用于使用一些看起来很有趣的代码即配置来启动网站的仪表板。 无头 WordPress 的一个难题是，现在你必须处理两个网站。 你需要处理托管和运行 WordPress 的地方，以及托管和运行使用 WordPress API 的网站的地方。 也许这能将这两者结合起来。 从 Git 提交部署的功能很有吸引力，我认为这在当今的现代托管中是必不可少的。
人们使用无头 WordPress 的另一个原因是，最终结果可以是静态的，即预生成的 HTML 页面。 这意味着您的网站服务器可以高度 CDN 化，因为它实际上只是静态资产，可以立即下载。 没有用于服务器端渲染内容的 PHP 或数据库，这可能会很慢（而且公平地说，可以解决），因为它在渲染之前添加了一个过程。
什么是“WordPress 方式”的无头方式？
我会将任何构建 WordPress 网站静态版本的服务归入无头 WordPress 类别。 这是因为，最终，这些网站都在使用 WordPress API 来构建这些静态文件，就像 Gatsby 或其他任何东西一样。
这就是 Strattic 所做的。 他们为您启动一个 WordPress 网站，他们认为这是暂存环境。 您可以在那里进行 WordPress 工作，然后使用他们的发布系统将网站的静态版本推送到生产环境。 这很有说服力，因为它解决了一些其他无头 WordPress 使用方式没有解决的问题：以 WordPress 方式做事。
例如，自定义 WordPress 块或插件可能会产生不只包含自定义 HTML，还包含 CSS 和 JavaScript 的输出。 想象一个“轮播”块或插件。 如果您只是从 API 获取帖子内容并将其放到页面上，那么这个轮播将无法工作。 您要么需要从其他地方提取 CSS 和 JavaScript 并包含它，要么以某种方式知道这不再是您的处理方式。 您可能会将图像作为元数据附加，在客户端获取它们，并自行实现轮播。 使用 Strattic，理论上，它将起作用，因为 HTML、CSS 和 JavaScript 仍然存在于静态网站上。 但值得注意的是，您没有使用 PHP，因此 Strattic 必须 手动构建表单集成，他们使用客户端 Algolia 进行搜索，使用 Disqus 进行评论，等等，因为没有可用的服务器端语言。
Shifter 是另一个参与者。 它类似于 Strattic，您在 WordPress 管理界面中处理您的网站，然后发布到静态网站。 我认为 Shifter 甚至在不使用时会关闭您的 WordPress 网站，这是有道理的，因为输出是静态的，没有理由运行一个带有 PHP 和 MySQL 的服务器。 作为替代方案，Shifter 有一个仅用于无头方式的 WordPress 设置，它可能始终处于运行状态，以便外部 API 使用。
思考这些东西很有趣
但是，当我这么想的时候，我意识到围绕无头 WordPress 的想法和讨论主要集中在开发人员身上。 WordPress 拥有庞大的市场，这些市场里的人们并不是开发人员。 但是，他们管理 WordPress 网站，利用插件和主题生态系统。 这很酷，WordPress 能如此出色地服务于这两个市场令人印象深刻。 我想，WordPress 网站所有者中，非开发人员的数量远超开发人员，所以仅凭这一点，在一段时间内，无头 WordPress 就不可能成为比相对小众的概念更重要的东西。 但是，你知道，如果他们想将 GraphQL 加入核心，我仍然会接受它 kthxbye。
这篇文章对这个主题的理解很棒。
我认为一个有趣的讨论应该是关于无头何时有意义。WordPress 本身就是如此，我认为重点应该始终放在那些管理和创建内容的人身上。无头使得这变得更加困难。
说清楚一点，我喜欢无头，我希望我创建的每个新 WordPress 主题都可以是无头的。它很有趣，而且设置工作流程很容易（或者说）更容易，它也是
#thefuture。请给我注册吧。但是，如果我不能提供一个对于每天在仪表盘中工作的人来说简单直观的网站，那么意义何在呢?
此外，我认为，为非无头网站设置 webpack 或 gulp 构建比创建一个系统来确保无头结果始终与用户在网站后端构建的内容相匹配要困难得多?
我的意思是，也许吧。所以，这就是为什么围绕何时无头是比非无头更好的解决方案的对话会很有趣。
“关于无头 WordPress 的想法和讨论主要集中在开发人员身上。”
我对此表示异议。交付没有膨胀、没有不必要的静态资源、甚至没有 PHP 引擎的标记，速度更快、更安全，并且对可访问性和 SEO 更好。基本上，它对客户和用户更有利。
魔鬼代言人
由经验丰富的开发人员使用最新的 PHP 构建的干净的 WordPress 网站，以及优化的缓存系统，可以
快速
安全
可访问
强大的 SEO
这并不是说你通过不使用 WordPress 的无头方式来让你的客户/用户处于劣势。
嗯…… 至少在我的国家，无头 WP 的影响并不大。
大多数“开发人员”只是使用它，因为使用其他人已经创建的主题或插件非常方便。商业模式只是收取更低的费用，交付更快，因为你不需要花太多时间在开发本身。
如果 WordPress 变得无头，它会失去很多便利性。在插件支持无头之前，我认为无头 WP 很难走出其利基市场。
很棒的文章！我很高兴你将 Strattic 上的 WP 网站归类为无头的。我当然同意，但有些人认为我们的方法不是无头的，因为静态网站的部署和渲染方式。但 IMO 最终结果才是最重要的，在我们的案例中，实时静态网站确实是无头的。
我们在 Strattic 的目标之一是将无头世界带给非开发人员。目前，围绕无头的许多方法都是超级面向开发人员的，这很好，但忽略了那些实际上每天使用网站来管理内容等的人。使用 Strattic，营销人员和开发人员都很满意，因为他们获得了他们想要/需要的环境。
（顺便说一下，在 Strattic 上，当 WP 网站不用时会关闭。）
我完全同意这一点：“此外，我认为我要使用 WordPress API 不仅仅是为网站提供支持，还要为本机阅读应用程序以及一些数字互联网连接的高速公路广告牌或其他东西提供支持，这不是一个正在流行的用例，据我所知。”
我一直看到这作为使用无头的理由，就像你说的那样，这种类型的功能没有很多用例。此外，即使 WP 网站以标准方式运行，它仍然具有内置的 REST API，可用于将内容发送到该广告牌。
我对 Strattic 非常感兴趣，因为我从未听说过这项服务，它解决了 UX 与 DX 之间的矛盾。
使用无头，你必须选择将重点放在哪一个上，这是一个非常巧妙的方法来解决问题。
很高兴你喜欢我们的方法 Jamie！
在我们的公司，我们计划转向无头。我们的网站已经使用 Elementor 运行了一年半，在进行快速定制和与读者进行实验方面非常棒。最大的缺点是 Elementor 带来的页面速度和体积问题。我们的想法是使用 sveltekit 并慢慢地将网站的部分内容转换为由 sveltekit 提供的服务器端渲染的网站。我们计划覆盖 nginx 代理的位置，以便在不花费数月时间进行全面重新发布的情况下，慢慢地按网站和分类方式测试过渡站点 :)
我们目前最大的问题是永久链接只包含帖子别名，因此我们无法一次性解决所有单个帖子……
我们有很多 Elementor 网站在 Strattic 上运行，以解决你描述的这些问题。例如，这里有一个案例研究，讲述了一家将 Elementor 网站迁移到 Strattic 的公司，它获得了 50% 的速度提升：https://www.strattic.com/coralogix-got-50-faster-on-strattic-without-an-extra-line-of-code/
我们有免费试用版，这样你就可以将网站的副本迁移到 Strattic，发布静态版本，并将其速度与当前网站进行比较。
嗨 Miriam Schwab，感谢你的评论！
我们目前使用 w3t total cache 和我们自己的 redis 实例（WordPress 和 redis 都运行在同一个 vps 上）。TTFB 已经达到大约 60-90 毫秒，而不是 1-2 秒（登录时）。目前我们页面最大的问题是 Lighthouse 得分，这是由 Elementor 造成的。所以 Jamstack 路线是不可避免的……
感谢你发表这篇很棒的文章！
一个更正
Gatsby 的
gatsby-source-wordpress插件不使用 WordPress REST API。这在以前的源插件版本中是正确的，但当前版本专门使用 WPGraphQL 从 WordPress 获取数据。我同意你的观点 @KellenMace。
另一方面，该插件已完全改进，以增强无头 WordPress 的可信度！
我同意将 WordPress JSON 数据提取到原生应用程序/电子广告牌/等可能并不常见。不过，我认为还有另一个值得考虑的用例——
我曾与希望能够从 WordPress、Salesforce、Shopify 和其他任何 API 中提取数据，然后使用所有这些数据构建最终交付给用户的 HTML 页面的公司合作。这就是 Gatsby 所谓的“内容网格”。
在传统的 WordPress 中，你需要从 WordPress 服务器 ping 这些第三方服务，缓存响应数据，编写自定义代码来清除缓存并定期重新生成这些数据，等等。
通过无头方法，更易于管理来自多个 API 的数据来源。借助 Next.js 中的增量静态重新生成等功能，最终用户无需等待过时的缓存数据重新生成——这是异步定期执行的，以保持数据新鲜。
这当然不适用于仅使用 WordPress 数据的网站。对于那些需要从多个外部服务获取数据的人来说，我认为它可以提供 UX 改进。
很遗憾，这篇文章没有进行更多的研究，我认为让读者了解所讨论的服务的作用，而不是猜测，这一点非常重要……
除此之外，我们运行一个托管的无头主机，我们的主要客户是那些希望在他们的 Shopify 商店中拥有 WordPress 博客的人。这是一个庞大的受众。我们的目标也是针对非 WP 开发人员，并专注于 JavaScript 开发人员，为他们的客户提供最佳的 CMS，而无需了解 WP。
人们往往认为 WordPress 是一个网站构建器。首先，WordPress 是一个很棒的博客系统。借助新的无头插件，我们现在可以将这个经过深思熟虑的系统外包，而无需使用 WordPress 作为前端。
你给出了一个完美的例子：wordpress 作为电子商务系统中的 CMS。你将两个世界合二为一。
毫无疑问，无头和云计算正在成为趋势。很多时候，许多开发人员只是追随炒作因素。
不要误会我的意思，我喜欢无头，我更喜欢用 JS 编码而不是 PHP，而且我非常乐意使用 View.js、无服务器等。
然而，有时你只需要一个显示内容的网站，也许可以接受订单。而 WordPress 原生非常适合这种情况。
正如 CSS Tricks 是一个 WordPress 海报网站 文章中所解释的那样，带有自定义主题/编码的 WordPress 通常是解决当前任务的完美答案。
你需要多少个外部服务（分散你的内容）和粘合代码来维护内容页面、博客文章、论坛和电子商务？
WP 几乎开箱即用地完成所有这些。你只需要添加一些自定义模板和 CSS，在需要时稍微编辑一些逻辑，就可以了。
看看人们都在做什么：他们在 Shopify 上托管他们的商店，最终还是为他们的博客部署一个 WordPress。
WP 远非总是最好的答案，但如果我要使用无头，那么这意味着我可能应该找到另一个后端。
我将我的 WP 博客切换到无头 w/React，几乎完全是因为你提到的原因——我喜欢 React。实际上，这是我去年封锁期间第一次学习 React 时（我知道，我迟到了），我想在一个真实世界的项目上工作。我对结果感到满意，我的下一步是使用 NextJS 重写它。