之前介绍了文章【加快页面加载速度 Performant Translations插件上线】，不少小伙伴来问，Performant Translations插件是什么？Performant Translations插件加速效果怎么样？Performant Translations插件有没有冲突之类的。这里看到Performant Translations插件已经发布了，就顺便测试一下，顺便分享一下Performant Translations插件加速效果超详细图文评测。

Performant Translations插件是什么

Performant Translations插件采用了一种新方法来处理 WordPress 中的翻译文件，从而使本地化速度飞快。一项深入的 i18n 性能分析表明，本地化后的 WordPress 网站的加载速度明显慢于没有翻译的网站。

有了这个插件的本地化新方法，这种开销就会大大减少，从而使您的网站再次快速运行。该插件的主要目的是允许对这些增强功能进行更广泛的测试，其目标是最终在 WordPress 内核中实现这些功能。

Performant Translations 支持多种文件格式（.mo、.php 和 .json），以及同时加载多个文本域和本地语言。默认情况下，它会将现有的 .mo 文件转换为 .php，然后只加载 .php 文件中的翻译。

简单来说就是，WordPress是英文为主的CMS程序，如果用其他语言主题（如中文、德文），则页面加载速度总体上会比英文页面要慢，原因是中间增加了语言解析的步骤。这里使用直接把翻译的内容缓存到Opcache中，起到加速的作用。

加载速度分析

初始基准测试显示，本地化网站的平均加载时间可能比非本地化网站慢 50% ，具体取决于所使用的主题和插件。这是使用wpp-research CLI 工具和专用基准环境进行测量的（如最后的比较部分所述）。

WordPress i18n 系统基于gettext，它使用源.po（可移植对象）文件和二进制.mo（机器对象）文件来存储和加载翻译。它不使用 C gettext API本身，而是使用自定义用户区实现，无需任何外部依赖即可工作。

除了核心本身之外，每个插件和主题都有自己的翻译文件，必须在每个请求时加载和解析该文件。加载和解析所有这些翻译文件是一项昂贵的任务。

过去，人们已经讨论和探索了各种解决方案来提高 WordPress 的国际化性能。一个非详尽的列表：

• 使用更轻量级的MO解析器
• 通过使用 MO 文件中的哈希映射（例如使用DynaMo）改进翻译查找
• 在对象缓存中缓存翻译
• 在 APCu（ PHP的内存中键值存储）中缓存翻译
• 其他更详细的缓存形式（例如每个请求）
• 使用本机 PHP gettext 扩展
• 使用自定义 PHP 扩展来处理 MO 文件解析）
• 使用延迟评估的翻译调用
• 使用与文件不同的文件格式.mo，例如纯.php文件

WordPress非英文页面加速的解决方案

关于从哪些方面着手，官方进行了大量的测试及研究，以下是官方的研究方向。

解决方案 A：使用不同的文件格式

使用不同的文件格式进行翻译而不是 .mo 文件，以避免加载和解析二进制文件的开销。

设计注意事项

使用此解决方案，翻译将存储在.php返回翻译字符串关联数组的纯文件中。只要.php文件可用，它将优先于.mo仍用作后备的文件。架构的其余部分保持不变。

当本地化 WordPress 网站从translate.wordpress.org翻译平台下载语言包时，它会下载.po包含.mo所有翻译的文件。这将被修改以包含.php文件。该平台所基于的GlotPress将进行更新以支持这种新的输出格式。此外，WordPress 核心本身可以修改为在 PHP 文件丢失时生成它们。

理论上，在 PHP 中没有什么比加载和执行另一个 PHP 文件更快的了。.json、.ini、 或.xml都会慢得多。

使用 PHP 文件的概念证明可以在swissspidy/wp-php-translation-files和swissspidy/ginger-mo中找到。

好处

• 初始基准测试显示出一致的显着性能改进
• 实施起来相对简单
• 通过优雅的回退保持向后兼容性
• 使用户更容易检查和更改翻译（无需编译.po为.mo）
• 避免加载和解析二进制.mo文件，这是主要瓶颈
• 让 PHP 将翻译存储在 OPcache 中以获得额外的性能优势
• PHP 生态系统中经过实战考验的方法（例如在 Laravel 中）

注意事项和风险

• 不仅需要更改 WordPress 核心，还需要 GlotPress 和WP-CLI等工具
• 在现有文件格式之上引入新的文件格式，增加了维护开销
  • 正如概念验证所示，开销是最小的
  • 从长远来看，.mo支持可能会被废弃
• 由于本质上是执行远程获取的 PHP 文件而导致的安全考虑
  • 与从WordPress.org下载插件/主题没有什么不同
  • WordPress 认为翻译是可信的
  • 托管提供商可能会阻止 PHP 在 wp-content/ languages 中执行
  • 可能在安装时使用校验和验证或静态分析来检测异常

计划表

使用 PHP 文件的概念证明已经非常可靠。还有 WP-CLI ( PR ) 和 GlotPress ( PR ) 更改的示例。这使得它适合功能项目，只需很少的努力即可扩展测试。即使是核心合并也会在相对较短的时间内非常简单，可能在 2023 年第 4 季度就已经完成。使用 PHP 文件时的安全方面可能是潜在的障碍，因此尽早让 WordPress 安全团队和托管提供商参与进来非常重要。

需要更多时间来测试其他文件格式并比较结果。

解决方案 B：原生 gettext 扩展

使用用 C 编写的本机 gettext PHP 扩展（如果可用），而不是 WordPress 中的自定义内置解析器。

设计注意事项

WordPress 一直使用自定义 MO 文件解析器，因为本机 gettext 扩展不一定在服务器上可用。通过此解决方案，现有系统可以在可用时使用扩展，如果不可用则回退到自定义实现。

之前已探讨过这一点，并在WP Performance Pack和Native Gettext中实现。这些实现可以作为初始设计的灵感。它们的工作原理都相似，即它们将翻译文件符号链接或复制到与 gettext 扩展兼容的新目录结构。

根据 WordPress 更新请求的信息，截至 2023 年 7 月，大约 66% 的本地化 WordPress 网站安装了 gettext 扩展。

好处

• 符合条件的网站的性能显着提高
  • 初始基准测试显示，加载时间和内存使用情况与非本地化站点基本没有区别

注意事项和风险

• gettext 扩展不常用
  • 实施激励较小，总体影响较低
• 需要在服务器上安装语言环境
  • 服务器很少有许多已安装的区域设置
    • 语言环境通常需要先编译并占用大量空间
    • 另一方面，WordPress 支持 200 多种语言环境
  • 与 WordPress 支持的自定义区域设置的潜在冲突
    • 例如，诸如pt_PT_ao90、de_DE_formal或 之类的区域设置roh甚至可能不受支持
  • 有必要联系托管提供商
• 通过本质上添加第二个 gettext 实现来增加维护开销
• 糟糕的API
  • 需要设置环境变量（例如LC_MESSAGES和LANGUAGE），这可能不可能或在某些服务器/站点上导致冲突
• 需要符号链接或硬文件副本
  • 符号链接可能无法在服务器上使用；复制所有翻译文件意味着磁盘使用量加倍
• 翻译文件由 PHP 缓存，因此任何翻译更改都需要重新启动 Web 服务器
  • 有一些解决方法，例如使用随机文件名或 fstat 进行缓存清除，但它们可能不适用于所有环境
• 尽管讨论了多年，但尚未进行更广泛的测试

计划表

虽然该解决方案可以利用现有的实现，但需要进一步的现场测试来评估该扩展是否在所有情况下都能正常工作。考虑到糟糕的 API 的限制和安装语言环境的要求，它看起来根本不是一个可行的解决方案。

解决方案 C：缓存翻译

以某种方式缓存翻译以避免昂贵的.mo解析。

设计注意事项

将翻译缓存在磁盘、数据库或对象缓存中，以避免.mo后续请求中昂贵的文件解析。这可以以通用方式完成，也可以基于每个请求来完成，以仅加载当前URL所需的翻译。

过去已经以各种形式探索了许多不同的缓存策略，每种策略都有自己的优点和缺点。有些甚至可以合并。定义确切的实现需要进一步的探索和测试，这需要它自己的探索文章。

好处

• 一次.mo解析后缓存翻译可能会提高未来请求的性能

注意事项和风险

• 使用持久对象缓存（例如 Memcached、Redis）或 APCu 进行缓存：
  • 大多数网站上不可用，因此这不是一个理想的解决方案
    • 根据 WordPress 更新请求的数据的可用性：
      • 内存缓存：~25%
      • Redis：~25%
      • APCu：~6%
  • 可能会显着增加缓存大小或超出缓存键限制
• 数据库缓存：
  • 将问题从磁盘读取转移到数据库读取
  • 可能会显着增加数据库大小
  • 或者，使用 sqlite 作为缓存后端
    • 未经测试的方法
    • 在大约 90% 的网站上可用
• 磁盘缓存：
  • 并不总是可行，具体取决于服务器环境
  • 仍然会导致文件读取，只是文件较少或有其他文件
• 多个缓存组（例如每个请求或前端/管理拆分）
  • 更智能的缓存逻辑，仅加载大多数请求所需的翻译
  • 可能会显着增加缓存大小
  • 不同的请求不太可能使用截然不同的翻译
• 缓存检索增加了开销
  • 确切的性能增益取决于实施方法，并且需要首先进行测量
  • 冷缓存没有性能提升
  • 缓存失效逻辑待定

计划表

鉴于生态系统中现有的解决方案，工程工作本身不会太大，但需要首先评估正确的缓存实现（例如磁盘缓存或对象缓存）。

然而，由于托管环境不同，可能不存在正确的缓存策略。由于核心支持多种类型的缓存是不现实的，因此该解决方案似乎更适合插件而不是核心。

解决方案 D：延迟评估翻译调用

在某些情况下，使用延迟评估的转换调用可以减少函数调用的数量，从而提高性能。

设计注意事项

延迟评估翻译调用的想法已在#41305中首次讨论。通过传递代理对象，它可以避免特定于字符串的昂贵翻译查找，直到实际需要翻译为止。

换句话说：除了即时加载翻译文件（WordPress 已经做到了）之外，这还将添加对翻译中各个字符串的即时查找。

它本质上可以通过两种方式集成，这两种方式都在核心票证上进行了解释：

1. 将所有翻译调用更改为默认延迟评估
2. 使用新函数参数或完全使用新函数来选择加入

好处

• 在某些情况下，大大减少翻译查找的次数
  • 在常规主页请求中，翻译调用减少了约 60%，节省了约 10 毫秒（由 XHProf 测量）
• 作为副作用，解决了诸如#38643之类的用户体验问题

注意事项和风险

• 根据实现的不同，这要么会破坏向后兼容性，要么会面临无法获得足够采用的风险
  • 文档、工具和开发人员教育可以在一定程度上帮助缓解这种情况
  • 采用可以逐步进行，例如从选择加入方法开始，最终使其成为默认方法
• 可能不会对典型的前端页面加载产生重大影响，因为它对于 REST API模式输出等区域最有用，在这些区域中进行大量翻译调用，但实际上并未使用翻译
  • 更多场景的需求分析以衡量影响
  • REST API 模式已经有一个解决方法，即在静态变量中使用缓存
• 不会改善实际加载翻译文件的情况
• 初步测试表明，由于创建了额外的数千个代理对象，这实际上会损害性能

计划表

逐步采用意味着需要多年的努力来建立延迟评估的翻译调用，而默认情况下启用此功能是一个重大的向后兼容性破坏，可能会影响生态系统中的数千个插件和主题。由于在某些情况下它确实会降低性能，因此该解决方案并不是一个很好的实施方案。

解决方案E：优化/重写现有的MO解析器

重构 WordPress 中现有的 MO 解析器以提高性能。

设计注意事项

全面检修 WordPress 中现有的 MO 翻译文件解析器，同时考虑到性能。例如，使用Ginger MO、WP Performance Pack或其他现有解决方案作为基础。

虽然Altis DXP (Human Made) 实际上已经用 Rust 编写的定制 PHP 扩展替换了现有的 MO 解析器，但这种方法对于核心显然是不可行的。新的解决方案需要在用户态 PHP 中编写。

使用更新后的 Ginger MO 分支进行的初步测试显示出一些明显的加速和更低的内存使用量。它还支持每个文本域多个翻译文件以及一次加载多个语言环境，这可能有利于改进WordPress 核心中的语言环境切换功能。

除此之外，WP Performance Pack和DynaMo等插件已经使用MO 哈希表或二分搜索实现了部分查找，避免读取整个文件并将其存储在内存中。这会稍微降低内存使用量和性能。

好处

• 无需引入其他文件格式即可使用
• 开启其他领域的潜在性能增强，例如区域设置切换
• 主要保持向后兼容性

注意事项和风险

• 仍然存在破坏向后兼容性的风险

计划表

该解决方案已经有了有效的概念验证，但需要更多测试来进一步完善它并改进其向后兼容性层。由于这样的努力是功能插件的理想候选者，因此可以在几个月内相对较快地实现这一目标。

解决方案 F：拆分翻译文件

将插件和主题的翻译文件拆分为更小的块，以提高加载效率。

设计注意事项

根据项目的大小，翻译文件可能会很大。这就是为什么 WordPress 本身为管理员和其他所有内容使用单独的翻译文件，这样就不会加载太多不必要的字符串。

这种策略也可以应用于插件和主题。要么允许他们使用多个文本域（这需要开发人员教育和工具更改），要么以某种方式自动执行此操作（确切方法待定）

好处

• 由于加载较小的文件，加载时间更快

注意事项和风险

• 破坏向后兼容性的风险
• 选择加入方法需要工具和分发更改，并且存在采用缓慢的风险

计划表

需要进一步的研究来正确评估这一点。

不同解决方案的对比

乍一看，解决方案 A（PHP 翻译文件）是一个相对简单的增强功能，它保持了向后兼容性并显示出有希望的改进。然而，它不仅需要改变核心本身，还需要改变翻译平台。安全方面仍然是一个风险，尽管尽早与利益相关者讨论并聚集更多测试人员将有助于减轻风险。

像解决方案 B一样利用本机 gettext 扩展显示了令人惊叹的结果，但缺乏可用性和不理想的 API 是一个问题。尽管如此，它仍然是一个不容忽视的渐进增强。特别是因为它几乎可以消除对额外缓存的需求，如解决方案 C 中那样。

像解决方案 C一样缓存已加载的翻译并不能消除 i18n 缓慢的根本原因，但可以加快后续请求的速度。不幸的是，持久对象缓存或 APCu 相当不常见，并且实现更复杂类型的缓存（例如每个请求缓存）在成为一个持久对象缓存之前需要大量的探索工作。切实可行的选项。

在某些情况下，延迟评估的翻译调用（解决方案 D）可以缩短翻译调用的时间，但总体而言实际上会降低性能。虽然它可以帮助解决一些实际的核心用户体验问题，但向后兼容性和采用问题使其更不是一个合适的解决方案。

现有的 Ginger MO 和 WP Performance Pack 等插件表明 WordPress 中现有的 MO 解析器可以进一步改进（解决方案 E）。

基准测试

说这么多，其实就是看最后的实际效果。

@wordpress/env这些基准测试由使用Playwright 的定制性能测试环境提供支持。该环境已配置了一些额外的插件和一些解决方案所需的 PHP 扩展。针对 6.3 RC进行了测试，方法是访问主页和仪表板各 30 次，然后使用中值。官方的测试结果如下：

使用默认的Twenty Twenty-Three主题

WordPress 后台加载

总体来说，在开启对象缓存后，安装了Performant Translations插件比不安装Performant Translations插件的网站页面加载速度要快20-30%这样。实际是不是这样呢？这里以实际的页面测试效果来试一下。

实际测试

首先，选择的主题是【Enfold 5.6.6完美汉化中文版|多用途自定义商业商店WordPress企业主题模板】，然后语言环境为中文。其他系统环境如下：

• 系统：Nginx 1.16.1
• PHP：7.4.3
• MySQL：5.7.26
• WordPress版本：6.3.1
• 加载主题：Enfold 5.6.6
• opcache：开启
• Performant Translations插件版本：1.0.1
• 测试浏览器：谷歌浏览器116.0.5845.111（正式版本） （64 位）

在只安装Performant Translations插件，不安装其他WordPress缓存优化加速插件的情况下进行测试。测试的就简单粗暴一点了，就直接浏览器测试加载时间，不启用本地缓存的情况下，不断用Ctrl+F5加载。

1、首页

测试加载时间

以上对比后，未启用Performant Translations插件的时候，首页加载速度一般在1.2-1.4s之间，启用Performant Translations插件后，发现在第一两次测试后进行了缓存翻译，然后加载速度确实有了30%以上的速度提升，首页加载速度一般在1s左右。

2、内页

测试加载时间

以上对比后，未启用Performant Translations插件的时候，内页加载速度一般在1-1.1s之间，启用Performant Translations插件后，内页加载速度一般在1s以内，基本在900ms左右。

因为以上是未启用WordPress优化加速插件进行测试的，有的小伙伴可能会问了，既然速度可以提升这么多，能不能和WordPress缓存优化加速插件一起使用，这里要告诉你的是，首先Performant Translations插件还不是很成熟，不适合直接用在生产站点上。再次，也进行了测试，在启用WordPress缓存优化加速插件后，基本都缓存了，至于Performant Translations插件的效果基本没啥区别。

因此，认为，如果你已经启用了WordPress缓存优化加速插件，如WP Rocket 【WP Rocket完美汉化中文版|WordPress网站缓存优化加速专业插件介绍】，各种对象缓存什么的都启用了的话，使用Performant Translations插件提升的意义不大。如果你自己的主题本来就是汉化主题，语言包也很大，加载很慢的情况下，可以尝试使用Performant Translations插件。