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

确认缓慢出现在哪里

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

检查服务器资源

打开 WPML支持。顶部的警告面板会提示 PHP 内存是否低于 WPML 推荐的 256 MB。内容较多的站点需要 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。当性能调查需要支持团队介入时，请通过与支持团队共享调试信息打包您的发现。