今年早些时候，一项深入的 WordPress 性能分析显示翻译可能会影响服务器响应时间，经过初步基准测试显示，根据所使用的主题和插件的不同，使用了翻译的 WordPress 站点的加载时间可能比没有使用翻译的站点慢 50%。
在很早之前的版本，WPJAM Basic 就有一个功能通过前台不加载语言包来提高博客速度，但时候后来很多用户使用了该功能，前台出现了英文，反而来说插件有问题，后面就取消了，?，当然现在还可以在当前主题的 functions.php 文件添加下面的代码实现：（注意：部分主题使用该代码后首页、登录页面等其他地方会出现英文）
- add_filter('locale', function($locale) {
- $locale = ( is_admin() ) ? $locale : 'en_US';
- return $locale;
- });
WordPress 官方性能团队现在则有更好的方法，首先使用了翻译 WordPress 站点大概有大约 56%，为了改善这 56% 站点的性能，WordPress 性能团队已将解决方案缩减为 6 个可能的优选方案，以提高使用了翻译功能的网站速度，并列出了每个方案的优缺点：
- 解决方案A：使用不同的文件格式
- 解决方案B：原生gettext扩展
- 解决方案C：缓存翻译
- 解决方案D：延迟评估翻译调用
- 解决方案E：优化/重写现有的 MO 解析器
- 解决方案F：拆分翻译文件
当前 WordPress 网站会下载包含翻译内容的 .po 和 .mo 文件，第一个建议的解决方案是将翻译存储在 .php 文件中，并将 .mo 文件作为备选方案，这是因为 PHP 加载并执行另一个 PHP 文件将是一种更快的方法。
对现有翻译解析器（方案E）进行优化和重写可能会为使用了翻译的 WordPress 站点带来最大的性能提升，结合新的 PHP 翻译文件格式 Ginger MO（方案A），这种改进会使 i18n（国际化）的开销变得微不足道，从而提高网站性能，然而，在引入新文件格式时，也需要考虑可能带来的风险，如兼容性问题或对现有功能的影响。
此外，使用了 Ginger MO 这样改进后的 i18n 库，还可以考虑与其他解决方案相结合，例如缓存技术或动态加载.mo文件。这样的组合可能会带来更大的性能提升。然而，目前这些结合方案尚未被充分研究和实践，因此在实际应用前仍需进一步探讨和评估。
具体怎么实现，性能团队在收集更多的反馈之后，通过其 Performance Lab 插件对这些想法进行更广泛的测试，最后在之后的版本中集成到 WordPress 内核中。
