WPML

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

WPML 性能问题（管理后台页面缓慢、前端卡顿、翻译仪表板超时）几乎总是由几个常见因素之一引起。在认定问题出在 WPML 本身之前，本页面将按检查顺序逐一说明这些因素。

  1. 确认缓慢发生的位置

    • 前端缓慢，管理后台正常：可能是全页缓存配置问题，或者是前端负载较重的插件所致。
    • 管理后台缓慢，前端正常：可能是 wp_options 自动加载臃肿、仅在管理后台运行的重负载插件，或是服务器性能不足。
    • 特定于翻译仪表板缓慢：可能是仪表板查询中的文章数量庞大，且 PHP 内存或执行时间不足。
    • 翻译操作缓慢：可能是与专业翻译服务商的连接问题；请检查 WPML支持 中的通信日志。

    请参阅日志以了解哪种日志对应哪种症状。

  2. 检查服务器资源

    打开 WPML支持。顶部的警告面板会提示低于 WPML 推荐的 256 MB 的 PHP 内存。包含较大目录的网站需要 512 MB 或更多内存。

    其他服务器资源症状：

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

  3. 对象缓存

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

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

  4. 全页缓存

    全页缓存（WP Rocket、W3 Total Cache、主机提供商边缘缓存）是提升前端速度的最大性能优势所在。

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

  5. 冲突或缓慢的插件

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

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

    如果原因是某个插件，请替换它或禁用其中导致缓慢的功能。

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

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

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