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