无头 WordPress：它是什么？你需要它吗？

在 Servebolt，我们是 WordPress 及其生态系统的大力倡导者。 我们还将它用于我们自己的网站，因为我们确实发现它是最好的内容管理系统，因为统计数据年复一年地继续显示。 它是开源的、多功能的且简单地说，很容易看出为什么它为互联网上超过 40% 的网站提供支持。

围绕 WordPress 的生态系统和开发者社区有多大，人们以不同的方式使用 WordPress 也就不足为奇了。 一种这样的方法是将 WordPress 用作无头 CMS - 简而言之，称为无头 WordPress，它越来越受欢迎。

在本指南中，我们将从我们团队的第一手经验中分解您需要了解的有关无头 WordPress 的所有信息、其优点、缺点等。

什么是无头 WordPress？

要了解无头 WordPress，您需要知道什么是单体 WordPress。 Monolithic或传统形式的 WordPress 就是您所知道的 WordPress。 这是一个内容管理系统，您可以使用它来管理您网站上的所有内容。

通常，WordPress 具有后端（内容管理系统）和表示层，可让您设计您的网站。 但是，无头 WordPress 站点是那些仅依赖 WordPress 作为内容管理系统并使用不同的前端堆栈来显示内容的站点。

这允许在开发方面具有更大的灵活性。 本质上，借助 REST API，您可以将 WordPress 用于其内容管理功能，同时将其与在Vue.js或React等框架中单独构建的前端配对（仅举几例，还有一系列其他可用的框架和前端工具）。

WordPress 被认为是耦合的 CMS 架构，因为所有前端编辑工具和后端内容管理（编辑）功能都是耦合的。 这允许开发人员、编辑、文案等团队管理表示层和内容。 与遵循解耦架构的无头 WordPress 网站相反，其中表示层和内容（顾名思义）是解耦的。

REST、GraphQL 和平面文件集成

无头 CMS 设置使用 API 和 CDN 来呈现内容。 目前，有三个选项可用——REST API、平面文件集成和 GraphQL。

WordPress 使用 REST API 让您将前端连接到 CMS。 REST API 只是一个遵循 REST 架构约束的应用程序编程接口，提供了一个统一的接口，让服务器和客户端可以在彼此之间传输数据。 REST 允许开发人员公开和使用特定数据，如果 REST 端点没有直接可用的数据，则需要额外开发。

另一种选择是 GraphQL（QL 是查询语言的缩写）。 GraphQL 使查询具有特定字段和关系的 API 变得容易，就像使用数据库一样。 这是一项重大改进，并且有一个插件可以在 WordPress 上使用 GraphQL API 。 这可能意味着不需要额外的开发来利用 CMS 的内容，因为 GraphQL 已经可以访问它，更复杂的部分是要求正确的高效查询来获取它。

另一种选择是平面文件集成。 平面文件集成允许您将通常通过 REST 或 GraphQL 提供的数据导出为 .JSON 文件，从而允许服务器对其进行缓存，而无需在每次请求时生成，从而使其速度更快。 使用此方法将在每次更改数据库时自动生成一组新的 .JSON 文件。 这通常是一个定制的实现，而不仅仅是一个插件。 因此，需要开发人员进行设置。

无头 WordPress 的优缺点

既然您知道什么是无头 WordPress 以及它与传统的WordPress 设置有何不同，那么在您做出决定之前，您应该了解以下优点和缺点。

灵活开发，在仍然使用 WordPress 作为您的内容管理系统的同时，解耦 WordPress 使您的开发人员可以灵活地使用选择的前端技术进行构建——即像Next.js这样的框架。 从表面上看，这意味着更多的构建自由。

从表面上看，这很棒。 但这也意味着您最终要为基本功能（例如站点地图和永久链接）重新发明轮子，以确保帖子和页面内容的实时预览正常工作。

而且您失去了WordPress 众所周知的大部分编辑工作流程。 设置新页面通常会变得更加复杂，并且需要待命的开发人员在事情不正常时进行调试。

使用 WordPress 后端构建移动应用程序

一个经常被忽视的用例是，当您解耦 WordPress 时，仅将其用于后端，您就可以构建移动应用程序。

应用程序很复杂，比从头开始构建网站（即使用或不使用 WordPress）复杂得多——因此，如果您最终走这条路，虽然内容将由 API 驱动，但其余大部分将依赖于本机设备功能在 React Native 等框架的帮助下。 这是 AppPresser 的 Scott Bollinger对构建移动应用程序的不同方法的一个很好的比较。 正如您可能已经猜到的那样，其中之一是 AppPresser，对于那些想要开箱即用的人来说，这是一个很好的实现。 当然，它由 WordPress 提供支持，使用 WordPress 插件、主题和 REST API 为原生/混合 iOS 和 Android 移动应用程序提供支持。

从这样的解决方案开始可以为您节省数周甚至数月的开发时间，并且最终基于他们团队多年的内部经验，从多年从事客户项目并在生产中测试平台以改进它。

更好的性能，权衡取舍。

可以通过三种主要方式开发无头

1. 客户端：一切都使用 javascript 构建在浏览器上，访问时从服务器加载内容。 例如，使用 React 作为引擎通过例如 REST API 获取数据。 当页面发生变化时，会向 API 请求更多数据，并在客户端上构建一个新页面。 最常用于单页应用程序 (SPA)
2. 静态发布：所有内容都已构建并导出为服务器上的 HTML、CSS 和 JS。 因为它只提供静态文件，而不是动态生成页面，所以可以将其存储在功率非常低的服务器或 CDN 上。 这种方法快如闪电。 这通常使用 Next.js 之类的东西来完成。 当页面改变时，会从服务器下载一个新的 HTML 页面并显示出来。 最常用于不经常更改的网站，例如宣传册网站或文档。
3. 同构页面：访问的第一个网页是作为 HTML 的服务器端呈现 (SSR)，但如果客户端能够，则所有其他后续页面都在客户端生成。 如果客户端无法生成页面，它将向服务器请求。 最常用于渐进式 Web 应用程序 (PWA)、高度动态的站点或必须为旧版 Web 浏览器提供服务的站点。 通常为此使用诸如Svelte.kit 之类的框架。

方法 #1 和 #3 可以使用平面数据文件来生成 HTML，使它们与静态发布站点相媲美，但使用 REST 或 GraphQL 会减慢它们的速度，因为它可能必须为每个请求生成 JSON 内容。

如果需要用户生成的内容（表单或评论），这三种工作方式会比标准的 WordPress 复杂得多。

让我们以联系表​​单为例，表单需要构建为在客户端工作，并能够通过 Javascript/AJAX 将其信息发送回服务器，然后在服务器上对其进行检查、清理并插入到联系人中表单插件管理系统。 因为这是一种完全不同的工作方式，它不能依赖联系表单插件制造商来提供这个或那个像蜜罐和其他垃圾邮件保护这样的东西将继续工作。 它可能需要开发人员创建一个 REST 端点并根据需要使其全部工作。 复杂得多。

理论上，评论要容易得多，因为 REST 端点已经存在，但仍然需要开发人员能够检索已批准的评论并以线程布局呈现它们，将新评论上传到批准流程，当然还要处理垃圾邮件。

当以无头方式开发时，要实现与 WordPress 开箱即用的相同目标或使用一些插件可能实现的目标，还有更多工作要做。

对围绕无头 WordPress 的安全性有很多错误信息。 使用 CDN 运行静态站点设置是针对 DDoS 攻击的良好预防措施。 但最终，如果您没有安装必要的系统（例如 Cloudflare 等），任何服务器都可能成为 DDoS 攻击的受害者。 分离的 WordPress 设置与安装在单独域或子域上的 WordPress 一起使用，前端位于标准域上。

例如，如果我们要使用这个网站，我们将继续使用servebolt.com作为我们的可公开访问的网站，同时将例如，使用 Next.js 前端作为示例意味着您可以选择使用SSR （服务器端呈现），在每个请求时生成页面 HTML，或者使用SSG （静态生成），其中页面 HTML在构建时生成。 静态生成允许 HTML 被重复用于每个请求，允许它被 CDN 缓存。

在任何一种情况下，表示层仍然与运行 WordPress 的内容层通信并请求内容。 这意味着您为无头 WordPress 设置托管内容管理层的区域仍将运行 WordPress。

总而言之，无头 WordPress 网站与在传统设置上运行的网站相比安全性是否更好的答案是可以的。 简而言之，因为这是一种不太常见的设置。 我们的意思是，有些人试图描绘运行 WordPress 的站点存在安全问题的真正原因是，有很多站点运行 WordPress，而且事情是完全灵活的，所以当然，您可以构建或安装一些不可靠，如果您使用无头和几乎任何其他堆栈构建，情况也是如此。

当您与像我们在Servebolt一样在安全性、扩展性和性能方面提供能力的 WordPress 托管服务提供商合作时，仍然很有可能在不牺牲您可以使用 WordPress 做的所有事情的情况下确保您的网站安全——不得不承担昂贵的开发费用从头开始重建的成本。

您可能会遇到无头的更多缺点

无头 WordPress 的成本

我们已经简要地谈到了这一点，但简而言之，无头 WordPress 可能会变得非常昂贵。 不仅仅是在开发成本方面，也许更重要的是时间方面。

您的团队失去了快速行动和迭代的能力，而无需依靠内部（或代理机构）的工程师。

对于不认为他们的网站是静态的快节奏团队来说，这是一个最终不值得的权衡。 我们已经亲眼目睹了 8 位数的公司（显然拥有内部管理无头 WordPress 的资源）如何选择转向无头设置并最终退回，因为他们无法承受的是时间损失，快速行动的灵活性，最终让他们团队中的少数人控制在他们的网站上工作。

很难找到知道自己在做什么的优秀开发人员

无头 WordPress 仍然是一个相对较新的设置。 因此，尽管找到熟悉 JavaScript（以及 React、Vue、Svelte、Gatsby 等框架）的 JavaScript 开发人员绝不是特别困难 - 甚至可能比现在找到优秀的 WordPress 开发人员更容易，他们实际上熟悉将前端层与遵循所有最佳实践的传统方式的 WordPress 往往更难获得。

并不总是比整页边缘缓存快

有更简单（可能更好）的路径可以通向更快的网站。

大多数考虑无头架构的公司应该先修复他们的托管，然后再做出更复杂的决定。 这样做不仅容易得多，而且您还可以很快看到显着的改进，而无需大量的前期投资。 无需投资重建您的网站并权衡当前状态下 WordPress 安装的所有好处。

什么时候应该避免使用无头 WordPress？

作为一般经验法则，无头 WordPress 不适合大多数使用 WordPress 构建的企业。 简而言之，那些：

• 希望避免维护两个单独的层（内容层和表示层）。
• 不想放弃 WordPress 闻名的编辑和内容管理工作流程。
• 让他们的团队拥有控制力和灵活性来工作，而不必经常依赖您的开发人员。
• 想要节省资源（时间和金钱）。
• 没有经验丰富的开发人员可以对系统的构建方式做出正确的选择。
• 是否正在寻找雇用临时工或让代理机构开发您的网站，着眼于后续的未来发展？

无头 WordPress 适合谁？

在以下情况下，无头 WordPress 对您的团队来说可能是一个不错的选择：

• 您的开发团队擅长使用 JavaScript 框架进行构建，并且找不到 WordPress 开发人员（无论出于何种原因）。 但也想继续使用 WordPress 作为内容管理系统，无头 WordPress 可能是一个不错的选择。
• 您的团队希望实现特定的目标，例如已构建的 SaaS 平台设计之间的连续性，这将使重建这些和在 WordPress 中维护它们的工作量更大。 在这种情况下，分离内容层和表示层可能是一个不错的选择。
• 您不会在 WordPress 主题的范围内进行构建，也不会专门依赖插件提供的任何附加功能。
• 作为雇主，您希望不断培训您的技术人员掌握最新技能，并知道通过向他们提供这些知识，他们更有可能在您身边待得更久。
• 您的目标是对堆栈的所有部分执行n次优化。

使用无头 WordPress 构建的网站示例

健康热线

TechCrunch

前沿

反向链接

鲁迪斯

行动后报告——评估无头作为解决方案

有些人想探索无头，因为它是很少有人使用的闪亮的新事物。 并不是因为它确实是解决特定问题的最佳解决方案，否则无法实现。 作为副产品，大多数采用无头方法的站点都属于不必要的过度工程类别。

不用说，无头 WordPress 也有令人兴奋的实现，在这些场景中它可能是一个不错的选择。 选择是允许团队构建令人难以置信的网站来推动他们希望实现的结果的选择。

仍然想知道无头 WordPress 是否符合您的团队正在寻找的东西？ 请随时与我们联系，我们很乐意与您讨论您遇到的问题，并正在考虑实施无头 WordPress 来解决。

或者，如果本指南已经回答了您的所有问题并且您已准备好尝试使用 Servebolt 方法：

对经验上更快的托管主机感兴趣？ 试试我们的WordPress 托管方法：

• 可扩展性：在实际用户工作负载测试中，Servebolt 的平均响应时间为 65 毫秒，比第二好的响应时间快 4.9 倍。
• 最快的全球加载时间： 1.26 秒的平均页面加载时间使我们在全球 WebPageTest 结果列表中名列前茅。
• 最快的计算速度： Servebolt 服务器提供了前所未有的数据库速度，每秒处理的查询比平均速度高 2.44 倍，运行 PHP 的速度比第二好的服务器快 2.6 倍！
• 完美的安全性和正常运行时间：所有显示器的正常运行时间为 100%，并且我们的 SSL 实施获得 A+ 评级，您可以确保您的网站在线且安全。