WordPress 6.3 即将发布，本文总结了该版本的性能改进。虽然WordPress 6.2 显着提高了内核的加载时间性能，设定了很高的标准，但 WordPress 6.3 已经超越了这些结果：根据RC3进行的性能基准测试， WordPress 6.3 块主题的加载速度提高了 24% ，块主题的加载速度提高了 18%对于经典主题，与 WordPress 6.2 相比，基于最大内容绘制 (LCP)指标。对于 WordPress 6.2，这些改进分别达到 18% 和 5%，因此可以公平地总结 WordPress 6.3 在性能方面是一项重大成就。
是什么让 6.3 速度如此之快？
要分解 6.3 中的性能改进，了解不同的加载时间性能指标以及它们之间的关系至关重要。最全面的指标是最大内容绘制 (LCP)，因为它捕获总体加载时间性能。因此，本文引言中提到的百分比是专门测量的 LCP 改进。
LCP 的一个重要部分是首字节时间 (TTFB)指标，它捕获服务器端加载时间性能，从而直接影响 LCP：实际上，TTFB 是对 LCP 结果做出贡献的服务器端部分。对于客户端加载时间性能，没有专用的独立指标。然而，由于客户端性能实际上就是其他一切，因此可以得出结论，客户端加载时间性能可以通过 LCP 和 TTFB 之间的差异来表示，即“LCP-TTFB”。
客户端性能
在 WordPress 6.2 中，大部分性能提升来自于服务器端性能 (TTFB) 的改进，正如前面提到的6.2 性能改进帖子中所强调的那样。在 WordPress 6.3 中，情况有所不同：大部分性能提升源于客户端性能改进 (LCP-TTFB)。事实上，与 WordPress 6.2 相比，WordPress 6.3 中的块主题的客户端性能提高了 40%，经典主题的客户端性能提高了 31% 。作为参考，WordPress 6.2 与 6.1 LCP-TTFB 的比较分别仅提高了 1.5% 和 2.5%。
绝大多数客户端性能改进来自于emoji-loader.js通过利用现代JavaScript API（例如 Web Workers、OffscreenCanvas和sessionStorage. 除非您的 WordPress 网站禁用了相关的表情符号功能，否则您应该会注意到由于此增强而带来的性能改进。有关此更改的更多背景信息，请参阅#58472和#56074
客户端性能改进的另一个显着部分源于添加对fetchpriority="high"图像属性的支持。因此，此改进仅与首屏上带有图像的内容相关，但鉴于图像是迄今为止网页上最常用的媒体，您很可能也会注意到此增强功能带来的性能改进。有关如何作为开发人员利用和修改新功能的全面概述，请参阅有关图像性能改进的 6.3 开发说明。有关更改的其他上下文，请参阅#58235和[56037]。
以下列表重点介绍了一些可以在某些情况下提高客户端性能的附加工单，其中一些工单增强了是否向loading="lazy"图像添加属性的启发：
- #54421
- #56588
- #58089
- #58211
- #58212
- #58213
- #58635
- #58680
- #58681
- #58704
最后但并非最不重要的一点：这里应该强调的一个值得注意的开发人员功能是引入脚本加载策略，它增加了对使用defer或加载脚本的支持async。总的来说，这是性能的一个重要里程碑，但是到目前为止，仅引入了API本身，这意味着它尚未对性能产生实际影响，这就是为什么本文前面没有提到这一更改的原因。随着 WordPress 核心和生态系统开始采用 API（例如，延迟块视图脚本和异步评论回复），预计将来我们也将看到它的显着性能改进。请阅读6.3 有关使用 async 和 defer 注册脚本的开发说明，了解有关如何作为开发人员利用 API 以及相对于直接操作脚本标记的方法的优势的更多信息。有关此更改的更多背景信息，请参阅#12009和[56033] 。
服务器端性能
虽然 6.3 中的服务器端性能改进总体上并没有带来那么多的性能提升，但该版本仍然包含一些显着的增强功能，特别是对于块主题，其中服务器响应时间加快了 15%。许多服务器端性能增强都是优化 WordPress 核心内部低级逻辑的结果。虽然这使得这些改进很难单独描述，但这意味着它们不需要在 WordPress 生态系统中进行任何采用或修改即可生效。
块主题最显着的性能增强之一是低级更改，它优化了 WordPress 核心块样式的注册方式。这是相关的，因为核心块样式的处理方式与自定义块的处理方式略有不同。然而，在 6.3 之前，所有块都使用相同的通用逻辑，其中包括相当多的灵活性，因此也有性能成本，这对于核心块来说是不必要的。这一变化引入了一个专用函数来以更有效的方式注册核心块样式。有关此更改的更多背景信息，请参阅#58528和[56044] 。
块主题性能的另一个重大胜利是功能的改进get_block_templates()。该函数中的逻辑经过优化，不再处理所有块模板，而仅处理那些与当前查询匹配的块模板。有关此更改的更多背景信息，请参阅#57756和[55687] 。
wp_common_block_scripts_and_styles()功能是另一个值得强调的优化功能。此增强功能仅与混合主题相关，特别是调用 add_theme_support( 'wp-block-styles' ) 的经典主题，对于这些主题，它会显着提高服务器端性能。有关此更改的更多背景信息，请参阅#58560和[56064] 。
对块主题和经典主题具有显着性能影响的最大变化是wp_maybe_inline_styles()函数中的性能优化，避免不必要地调用相对昂贵的函数来获取样式表文件的大小和内容。有关此更改的更多背景信息，请参阅#58394和[55888] 。
以下列表重点介绍了一些可以在某些情况下提高服务器端性能的附加工单：
- #57683
- #57814
- #57864
- #58321
- #58376
数据库性能
WordPress 6.3 对延迟加载元数据进行了多项增强，可以避免某些情况下的数据库查询。有关元数据 API 改进的 6.3 开发说明帖子中概述了这些更改。有关更多上下文，请参阅单独的票证#57227、#57645、#57901和#58185 。
此外，该get_pages()函数现在在内部使用WP_Query，这不仅意味着消除了重复代码，更重要的是，它导致了该函数的性能改进，因为它现在受益于相同的可靠缓存行为，这是以前的自定义实现中所缺少的功能。有关更多上下文，请参阅有关该函数的6.3 开发说明get_pages()和工单 #12821。
最后但并非最不重要的一点是，WP_User_Query类现在支持缓存查询结果，成为最后一个支持它的 WordPress 核心查询类。这样可以避免查询用户信息时查询数据库。有关更多上下文，请参阅有关缓存的 6.3 开发说明WP_User_Query和工单#40613。
关于所使用的基准的说明
虽然本文中分享的指标基于使用 WordPress 6.2 所用相同方法进行的基准测试，但任何基准测试都需要进行细微差别的解释：除了用于基准测试的 WordPress 网站的配置方式之外，基准测试在很大程度上取决于为了获得额外的参考点，一些不同的贡献者还基于该版本的稍早版本 6.3 RC1 进行并分享了他们的基准测试。所有基准测试结果均汇总在此电子表格中。
可以注意到，其他一些基准测试并没有看到突出显示的基准测试中注意到的那么高的改进（就上下文而言，这些基准测试是在作者的机器上运行的），但主要的结论是整体性能显着提升。目前，将重点放在性能基准上并使用本文中突出显示的数字是有意义的，以便与上述6.2 性能改进帖子中的数字保持一致，因为性能基准也使用相同的环境。对于相对改进不那么高的任何其他贡献者的基准，可以假设其环境中的 6.2 性能基准也会显示出同等较低的性能提升。
虽然这意味着我们无法得到 WordPress 6.3 到底快了多少的明确答案，但可以肯定地说，它比 6.2 快很多，而且相对而言，性能提升甚至比 6.2 和 6.1 之间还要高。
自动化基准测试工作流程
引用的一些基准测试是使用@ swissspidy最近实施的新的可重用自动化基准测试工作流程进行的，使用与手动基准测试相同的方法，但使用GitHub Actions。这些结果表明，由于使用相同的环境，使用此工作流程总体上可以获得更一致的结果，并且还减少了进行性能基准测试所需的工作量。将来，依赖该工作流程中的数字而不是来自特定贡献者的任意环境的数字可能是一个好主意。作为参考，自动化工作流程数字大致表明了 WordPress 6.3 与 6.2 相比的以下性能改进：
- LCP 对于块主题快 13.9%，对于经典主题快 9.3%。
- TTFB 对于块主题快 8.4%，对于经典主题快 1.1%。
- LCP-TTFB 对于块主题快 20.6%，对于经典主题快 11.5%。
参与其中
如果您有兴趣致力于提高整个项目的绩效，请务必加入#核心编辑器,#核心性能，并参加双方的会议。