WPML

WPMLパフォーマンストリアージ – 管理画面の遅延、翻訳ダッシュボードのタイムアウト、フロントエンドのラグ

WPMLのパフォーマンス問題（管理画面の遅延、フロントエンドの動作の重さ、翻訳ダッシュボードのタイムアウト）は、ほとんどの場合、いくつかの一般的な要因のいずれかに起因します。このページでは、問題がWPML自体にあると判断する前に確認すべき順序で、これらの要因について説明します。

  1. 遅延箇所の確認

    • フロントエンドが遅く、管理画面は正常 → フルページキャッシュの設定、またはフロントエンドの負荷が高いプラグインである可能性があります。
    • 管理画面が遅く、フロントエンドは正常 → wp_optionsの自動読み込みの肥大化、管理画面専用の重いプラグイン、またはサーバーの能力不足である可能性があります。
    • 翻訳ダッシュボードのみが特に遅い → ダッシュボードのクエリに含まれる投稿の数が多く、PHPメモリまたは実行時間が不足している可能性があります。
    • 翻訳の操作が遅い → 翻訳サービス会社への接続に問題がある可能性があります。WPMLサポートにある通信ログを確認してください（どのログがどの症状に対応するかについては、ログを参照してください）。

  2. サーバーリソースの確認

    WPMLサポートを開きます。上部の警告パネルでは、PHPメモリがWPMLの推奨する256MBを下回っている場合にフラグが表示されます。より大きなカタログを持つサイトでは、512MB以上が必要です。

    その他のサーバーリソースに関する症状は以下のとおりです。

    • データベースクエリの遅延。多数の翻訳を持つ大規模なサイトでは、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のキャッシュをクリア」が含まれています。パフォーマンスの調査にサポートの確認が必要な場合は、サポートとのデバッグ情報の共有を通じて、これまでに判明した情報をまとめて送信してください。