我正在使用 xdebug 和 webgrind 来分析我的 WordPress 安装,因为它有点慢。 由于激活了大约 20 个插件,我认为 xdebug 将能够找到瓶颈。
然而,令我惊讶的是,本地化例程似乎占用了大部分执行时间。 是的,我使用的是 WordPress 的本地化版本。 请查看单个 ajax 页面加载的 webgrind 的以下输出:
我可以看到我的一些插件每个执行时间不到 1%(以执行时间的百分比衡量)。 但是翻译套路, Translation_Entry
, MO
, POMO
使用总量的30%以上。
我想知道为什么会这样,我是否应该阻止使用本地化版本? 还是我使用了错误的方法来分析性能?
对于每个翻译文件,WordPress 必须将其解压,然后每个条目将被转换成一个 Translation_Entry
目的。
短字符串 “caller_get_posts”已弃用。 请改用“ignore_sticky_posts”。 翻译时将需要三倍的内存:
'"caller_get_posts" is deprecated. Use "ignore_sticky_posts" instead.' =>
Translation_Entry::__set_state(array(
'is_plural' => false,
'context' => NULL,
'singular' => '"caller_get_posts" is deprecated. Use "ignore_sticky_posts" instead.',
'plural' => NULL,
'translations' =>
array (
0 => '"caller_get_posts" ist veraltet. Bitte nutze stattdessen "ignore_sticky_posts".',
),
'translator_comments' => '',
'extracted_comments' => '',
'references' =>
array (
),
'flags' =>
array (
),
)),
这就是为什么正确编写的插件和主题不会无条件地加载它们的语言文件的原因。 不幸的是,没有多少正确编写的插件和主题……
WordPress 翻译分为管理部分和前端部分,以减少内存影响。 仍然很多。
您可以使用 mu-plugin 阻止加载特定语言文件:
add_filter( 'override_load_textdomain', 'stop_language_files', 10, 2 );
function stop_language_files( $bool, $domain )
{
if ( 'textdomain_you_do_not_want' === $domain )
return TRUE;
return $bool;
}
本地化对 WordPress 的性能有很大影响,问题不在于插件,而在于 WordPress 的本地化实现(尽管编写好的插件可以减少影响)。 WP Performance Pack Plugin 提供了一种解决方案,因为它具有不同的优化功能,理想情况下几乎可以抵消本地化对性能的影响。