WordPress 托管的存在是为了更好地运行 WordPress。它提供了一个针对 WordPress 在高负载下的表现、缓存处理方式以及 PHP 执行进行优化的环境。
区块主题不会改变托管的基本原理，但确实改变了性能瓶颈出现的位置。这正是网络托管商角色变得更加清晰的地方。仅有基础设施不足以让网站快速运行；配置不当的基础设施在现代 WordPress 工作流中会暴露无遗，特别是涉及动态区块、Site Editor、预览以及已登录会话时。
要理解其中的原因，我们需要了解页面请求实际发生了什么，以及当使用基于区块的架构时，托管配置如何影响用户体验。
当 WordPress 页面被请求时会发生什么
让我们逐步分析一个返回 200 OK 响应的简单请求。
1. 浏览器发送请求
用户输入 URL 或点击链接。如果服务器的 IP 地址尚未缓存，浏览器会执行 DNS 解析。然后它建立 TCP 连接并完成 TLS 握手。
在 WordPress 介入之前，请求会通过 Web 服务器以及任何已配置的层（如防火墙或反向代理）进行传递。
2. 缓存检查
服务器检查请求的页面是否存在有效缓存。
如果存在有效的全页面 HTML 缓存，WordPress 不会执行，缓存的响应会立即返回。
如果不存在缓存条目，或者为已登录用户、预览或特定端点故意绕过缓存，请求会继续传递到 WordPress。
3. WordPress 启动
WordPress 加载其核心文件、已启用的插件和主题。它初始化钩子并准备解析请求。
在这个阶段，WordPress 尚未渲染输出，只是确定正在请求什么内容。
4. 主查询解析
只有在此时，模板选择才会开始。
5. 模板解析
这是区块主题和经典主题在结构上开始出现差异的地方。
经典主题
WordPress 评估模板层级并选择相应的 PHP 模板文件，如 single.php、page.php 或 archive.php。该文件包含直接输出 HTML 的 PHP 逻辑。
区块主题
WordPress 检查数据库中是否存在自定义的区块模板。如果存在，则优先使用。如果不存在，WordPress 会回退到主题中包含的区块模板文件，如 single.html 或 index.html。
然后，所选模板会通过区块渲染系统进行处理。
6. 布局组装
经典主题
布局通过 PHP 模板构建。这些模板组合标记、逻辑和函数调用来生成 HTML 输出。
区块主题
布局由区块模板、模板部件和文章内容组装而成。区块标记会被解析，每个区块都会在最终输出生成之前被渲染为 HTML。
7. 内容结构
经典主题
文章内容主要存储为数据库中的 HTML。在输出期间，WordPress 会在渲染前应用过滤器、简码和其他处理。
区块主题
区块内容存储为带有嵌入区块元数据的 HTML，例如：
<!-- wp:image {"id":123} -->
<img src="logo.png">
<!-- /wp:image -->
当 WordPress 处理此内容时，它会解析区块结构，理解属性和嵌套关系，并在生成最终 HTML 之前应用区块级别的属性和样式，如间距、对齐和排版。
8. 动态渲染
动态渲染在经典主题和区块主题中都存在。许多经典主题依赖自定义查询、小部件或简码来在运行时生成输出。
在基于区块的架构中，动态行为通过动态区块被正式化。例如，Query Loop 区块在请求期间使用 PHP 生成其标记，而不是在数据库中存储静态 HTML。
当全页面缓存被绕过时，此渲染工作流会在每个请求上发生。
9. 样式
对于经典主题，样式通常通过主题入队的静态 CSS 文件传递。
对于区块主题，在 theme.json 和区块元数据中定义的全局样式允许 WordPress 自动生成一致的 CSS。这减少了对大型手写样式表的需求，并将设计配置集中化。
10. 最终输出
在处理完模板、内容、区块和样式后，WordPress 生成最终的 HTML 响应。
服务器将内容发送到浏览器。如果已配置，该响应随后可能会被缓存以供将来请求使用。
区块主题如何改变负载
您刚才浏览的请求生命周期适用于经典主题和区块主题。WordPress 仍然会解析查询、选择模板、执行 PHP 并返回 HTML。
区块主题改变的不是基础，而是工作发生的位置以及何时无法跳过。
首先，模板可以存放在数据库中。当用户在 Site Editor 中编辑模板时，WordPress 会存储该版本并优先于主题目录中的文件。这增加了灵活性，但也意味着部署和缓存失效需要考虑存放在数据库中的模板。
其次，动态区块使运行时渲染更加明显。经典主题可以通过自定义查询、小部件或简码生成动态输出。区块主题通过动态区块（如 Query Loop 区块）将这一模式正式化。当全页面缓存被绕过时，这些区块会在请求期间执行 PHP。
第三，编辑器工作流严重依赖 REST API。保存模板、更新全局样式、预览更改以及与模式交互都会产生未缓存的请求。这些路径直接依赖 PHP 执行、数据库性能和对象缓存。
最后，theme.json 中定义的全局样式将设计决策集中化。当样式或模板结构发生变化时，缓存协调变得更加重要，以确保访问者和编辑器立即看到更新的输出。
这些转变都不需要不同类型的托管。但它们确实使某些基础设施弱点更加明显，特别是在未缓存和已登录的场景中。
考虑到这一点，下一步是了解在基于区块的设置中，配置良好的托管环境应该处理什么。
基于区块网站的托管注意事项
区块主题不会引入新的托管要求。它们只是使现有要求变得更加重要。
配置良好的环境应该同时考虑缓存和未缓存的路径，特别是对于编辑者和已登录用户。
各层之间的协调缓存
全页面缓存对于匿名流量仍然是最有效的性能层。公共页面应该被积极缓存，而预览、已登录会话和特定端点会自动被绕过。
对象缓存也发挥着重要作用。通过将重复的查询结果和计算出的数据结构存储在内存中，对象缓存可以减轻数据库负载并改善前端和后端的响应能力。
缓存失效需要协调。当内容、模板或全局样式更新时，相关页面应及时刷新。糟糕的缓存协调可能导致过时的布局、不一致的样式或令人困惑的预览行为。
CDN 通过缓存更靠近访问者的静态资源（如图像、字体和脚本）来补充这一设置。
缓存不是单一层的问题，而是这些层如何协同工作的问题。
PHP 容量和运行时性能
当全页面缓存被绕过时，WordPress 会执行 PHP 来解析查询、渲染模板和处理动态区块。
这使得 PHP 容量规划变得重要。环境应提供足够的 PHP 线程来处理预期的并发，而不会造成队列积压。内存限制应配置为防止在负载下发生交换。
OPcache 应被启用并正确调整大小，以便 PHP 字节码不需要重复编译。在部署期间，OPcache 应刷新以使更新的代码立即运行。
这些实践适用于所有 WordPress 站点，但基于区块的工作流在渲染是动态的时会使性能问题更加明显。
数据库和对象缓存
在 Site Editor 中自定义的区块模板存储在数据库中。区块内容包含 WordPress 在输出前解析的结构化元数据。虽然这种处理很高效，但在缓存被绕过时仍然依赖于数据库响应。
持久的对象缓存可以减少重复查询，并有助于稳定访问者和在仪表板内工作的编辑者的性能。
可观测性和监控
随着更多活动转移到运行时路径，可见性变得更加重要。托管商和站点所有者应监控：
- 缓存命中率
- PHP 工作进程利用率和队列长度
- 数据库查询性能
- REST API 响应时间
- 缓存和未缓存请求的首字节时间
区块主题不需要专门的基础设施。它们确实使配置薄弱的基础设施更容易被察觉。
按照 WordPress 如今的工作方式运行
区块主题不会改变 WordPress 对托管的需求。它们只是使这些需求未得到满足时更加明显。
当模板存放在数据库中，当动态区块在运行时渲染，当编辑者依赖未缓存的 REST 请求时，基础设施不再是无形的。它要么顺利支持工作流，要么碍事。
这正是 WordPress 托管服务与众不同的地方。
在 Kinsta，整个技术栈专门针对 WordPress 如今的工作方式而构建，从协调缓存和持久对象缓存，到调整好的 PHP 性能和基于强大云基础设施的全局 CDN 交付。目标是确保访问者和编辑者都能获得一致的性能，即使在动态渲染发生时也是如此。
基于区块的 WordPress 并不更重。它更加透明。而当基础扎实时，这种透明会对你有利。
