WPML 性能问题排查 – 管理后台缓慢、翻译仪表板超时、前端卡顿

确认缓慢出现的位置

• 前端缓慢，管理后台正常 → 可能是全页缓存配置问题或前端负载较重的插件所致。
• 管理后台缓慢，前端正常 → 可能是 wp_options 自动加载臃肿、仅限管理后台使用的重度插件或服务器性能不足所致。
• 翻译仪表板特别缓慢 → 可能是仪表板查询中的文章数量庞大，且 PHP 内存或执行时间不足所致。
• 翻译操作缓慢 → 可能是与翻译服务的连接问题；请检查 WPML > 支持中的通信日志（有关哪个日志对应哪种症状，请参见日志）。

检查服务器资源

打开 WPML > 支持。顶部的警告面板会标记低于 WPML 推荐的 256 MB 的 PHP 内存。内容较多的网站需要 512 MB 或更多内存。

其他服务器资源症状：

• 数据库查询缓慢。 拥有大量翻译的大型网站可受益于基于 SSD 的数据库服务器、充足的 innodb_buffer_pool_size 以及 wp_icl_translations 表上的索引（这些由 WPML 添加；极少需要手动干预）。
• PHP 执行时间。 如果 max_execution_time 低于 60 秒且仪表板超时，请将其提高。
• CPU。 共享主机计划通常有严格的 CPU 限制；请向您的主机提供商确认您是否受到限制。

对象缓存

如果没有对象缓存，WordPress 会在每次请求时从数据库加载许多 WPML 设置。请添加 Redis 或 Memcached 作为对象缓存（大多数托管型 WordPress 主机都提供此功能；如果没有，可以通过 Redis Object Cache 或 WP Redis 插件启用它）。

性能提升通常非常显著。以前需要查询数据库的设置现在会直接从内存中提供。

全页缓存

全页缓存（WP Rocket、W3 Total Cache、主机提供商的边缘缓存）是提升前端速度最有效的性能优化手段。

如果您已经配置了全页缓存但页面仍然感觉缓慢，请检查您的缓存是否正确处理了每种语言的 URL。WPML 的 URL 结构（无论是语言作为目录、语言作为子域名，还是语言作为域名）需要缓存根据 URL 区分内容。大多数缓存会自动执行此操作，但值得验证的是，法语版本没有从英语缓存中提供，反之亦然。

冲突或缓慢的插件

网站会不断积累插件；有些构建良好，有些则不然。要找出缓慢的插件：

1. 安装 Query Monitor（一个调试插件）。
2. 重新加载缓慢的页面。
3. 查看 Queries by Component。产生最耗时查询的插件就是可疑对象。

如果查明是某个插件导致的问题，请将其替换或禁用其中导致缓慢的功能。

翻译服务缓慢，而非网站缓慢

如果翻译任务感觉缓慢，但网站本身运行正常，则瓶颈在于您的网站与 WPML 的翻译基础设施之间。

请检查 WPML > 支持 > 通信日志。该日志显示每个 API 调用的延迟。如果单个调用需要数秒，则问题在于连接（网络路径、DNS 或主机提供商的出站限制），而不是网站。如果罪魁祸首是 WPML 自身的缓存，安全层故障排除工具中包含 Clear the cache in WPML。当性能调查需要支持团队介入时，请通过与支持团队共享调试信息打包您的发现。