随着WordPress 6.3发布,本文总结了该版本的性能改进。虽然WordPress 6.2显著提高了Core的加载时间性能,树立了很高的标准,但WordPress 6.3性能改进已经超越了这些结果:根据进行的性能基准测试,与WordPress 6.2相比,基于最大内容绘制 (LCP)指标,WordPress 6.3块主题的加载速度提高了27%,经典主题的加载速度提高了18%主题。对于 WordPress 6.2,这些改进分别达到18%和5%,因此可以公平地总结WordPress 6.3在性能方面是一项重大成就。
要分解 6.3 中的性能改进,了解不同的加载时间性能指标以及它们之间的关系至关重要。最全面的指标是最大内容绘制 (LCP),因为它捕获总体加载时间性能。因此,本文引言中提到的百分比是专门测量的 LCP 改进。
LCP 的一个重要部分是首字节时间 (TTFB)指标,它捕获服务器端加载时间性能,从而直接影响 LCP:实际上,TTFB 是对 LCP 结果做出贡献的服务器端部分。对于客户端加载时间性能,没有专用的独立指标。然而,由于客户端性能实际上就是其他一切,因此可以得出结论,客户端加载时间性能可以通过 LCP 和 TTFB 之间的差异来表示,即“LCP-TTFB”。
网址: WordPress 6.3性能改进 - 易服客工作室
目录
客户端性能
服务器端性能
数据库性能
关于所使用的基准的说明
自动化基准测试工作流程
在 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 网站禁用了相关的表情符号功能,否则您应该会注意到由于此增强而带来的性能改进。
客户端性能改进的另一个显着部分源于添加对fetchpriority="high"
图像属性的支持。因此,此改进仅与首屏上带有图像的内容相关,但鉴于图像是迄今为止网页上最常用的媒体,您很可能也会注意到此增强功能带来的性能改进。有关如何作为开发人员利用和修改新功能的全面概述,请参阅有关图像性能改进的 6.3 开发说明。有关更改的其他上下文,请参阅#58235
最后但并非最不重要的一点:这里应该强调的一个值得注意的开发人员功能是引入脚本加载策略,它增加了对使用defer
或加载脚本的支持async
。总的来说,这是性能的一个重要里程碑,但是到目前为止,仅引入了API本身,这意味着它尚未对性能产生实际影响,这就是为什么本文前面没有提到这一更改的原因。随着 WordPress 核心和生态系统开始采用 API(例如,延迟块视图脚本和异步评论回复),预计将来我们也将看到它的显着性能改进。请阅读6.3 有关使用 async 和 defer 注册脚本的开发说明,了解有关如何作为开发人员利用 API 以及相对于直接操作脚本标记的方法的优势的更多信息。有关此更改的更多背景信息,请参阅#12009
虽然 6.3 中的服务器端性能改进总体上并没有带来那么多的性能提升,但该版本仍然包含一些显着的增强功能,特别是对于块主题,其中服务器响应时间加快了 19%。许多服务器端性能增强都是优化 WordPress 核心内部低级逻辑的结果。虽然这使得这些改进很难单独描述,但这意味着它们不需要在 WordPress 生态系统中进行任何采用或修改即可生效。
块主题最显着的性能增强之一是低级更改,它优化了 WordPress 核心块样式的注册方式。这是相关的,因为核心块样式的处理方式与自定义块的处理方式略有不同。然而,在 6.3 之前,所有块都使用相同的通用逻辑,其中包括相当多的灵活性,因此也有性能成本,这对于核心块来说是不必要的。这一变化引入了一个专用函数来以更有效的方式注册核心块样式。
块主题性能的另一个重大胜利是功能的改进get_block_templates()
。该函数中的逻辑经过优化,不再处理所有块模板,而仅处理那些与当前查询匹配的块模板。
对块主题和经典主题具有显着性能影响的最大变化是函数中的性能优化wp_maybe_inline_styles()
,避免不必要地调用相对昂贵的函数来获取样式表文件的大小和内容。
WordPress 6.3 对延迟加载元数据进行了多项增强,可以避免某些情况下的数据库查询。
虽然本文中共享的指标基于使用 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 相比的以下性能改进: