WordPressサイトのパフォーマンス問題をデバッグする方法

WordPressは世界で最も利用されているコンテンツ管理システム（CMS）ですが、WordPressサイトを運営していれば、誰でもいずれ何かしらの問題に遭遇するものです。問題を効率的にデバッグするには、適切なツールや頼れるサポートを確保しておくことが重要です。

今回は、Kinstaが実際に遭遇した稀に発生するパフォーマンスの問題（おそらく100万件に1件あるかないか）とそのデバッグ方法、そして役立ったツールや戦略をご紹介します。一般にあまり見られない特殊なエラーも、トラブルシューティングの方法は基本的に同じになります。もしもに備えてこの記事をブックマークしておいて、以下にご紹介するパフォーマンスチェックリストを参考にしてみてください。

WordPressのパフォーマンスチェックリスト（問題発生時）

パフォーマンスチェックリストといっても、今回はWordPressサイトを高速化する方法ではなく、何かしらの問題が発生した際に、何を行うべきかをご紹介していきます。サイトがサーバーに過負荷をかけていることで、ホスティング会社から連絡が来た、あるいはadmin-ajax.phpリクエストなどがサイトの足を引っ張っていることに気がついた、などさまざまな状況が考えられます。

問題の原因をなかなか特定できない場合は、以下の手順に従ってトラブルシューティングを行ってみてください。

1. 稼働状況とパフォーマンスの監視

パフォーマンスの問題に関して言えば、備えあれば憂いなし。サイト訪問者よりも先にサイトの不備を検出するためにできることの一つは、稼働状況とパフォーマンスの監視を導入することです。Kinstaでは、お客様のすべてのウェブサイトを3分ごとにチェックしています。これは1日あたり480回に相当します。

必要に応じて、New RelicのSyntheticsとAPMを利用して、WordPressサイトに関する多くのデータポイントを監視する能力もあります。

• エンドユーザーの読み込み時間
• アプリサーバーの読み込み時間
• エラー率
• スループット
• 成功率（稼働率）
• Apdexのスコア

Kinstaを利用している場合、サイトがダウンするとKinstaがすぐに検出し、許容可能な内部パフォーマンスのしきい値を大幅に超えた場合は、お客様に通知を送信してトラブルシューティングのお手伝いを行います。

トラブルシューティングは、開発者に依頼することも可能です。状況によっては簡単に修正できることもあれば、ワーカープロセスを増やす必要があるかもしれません。

多くの場合、パフォーマンスの問題はプラグインの更新不良、コードの不具合、PHPの最新バージョンとの非互換性などに起因しています。

稼働状況監視とパフォーマンス監視ツール

Kinsta以外をご利用の場合は、以下のような稼働率とパフォーマンスの両方を監視できるサードパーティツールを使用してみてください。

• updown.io（稼働率監視）
• Pingdom（稼働率とパフォーマンス監視）
• Uptime Robot（稼働率監視）
• StatusCake（稼働率とパフォーマンス監視）
• ManageWP（稼働率とパフォーマンス監視）

2. New Relicのようなツールを使用する

New Relicのようなツールは、稼働率やパフォーマンスを監視するのに優れているだけでなく、パフォーマンスの問題がどこから発生しているのかをトラブルシューティングするのにも役立ちます。KinstaではNew Relicをサポートしているため、ライセンスキーを取得して統合することができます。必要に応じて、カスタマーサポートが問題の追跡をお手伝いすることも可能です。または、Query Monitorのような無料のプラグインを使用してもOKです。

New Relicには、パフォーマンスの問題を素早く絞り込むことができる領域がいくつかあり、1つは「WordPress」の「Plugins and themes」タブです。例えば、以下のスクリーンショットでは、利用中の「gp-premium」プラグインの応答時間が著しく遅いことがわかります。

注）このセクションの情報は、100%正確とは限りませんが、トラブルシューティングとして確認が推奨される画面です。

上の例の場合は、gp-premiumプラグイン（GeneratePress WordPressテーマの拡張機能）に原因があることが濃厚です。続いて「Transactions」タブを確認すると、admin-ajax.phpのトランザクションの数が急増していることがわかりました。

New Relicを利用していない場合、WordPressサイトでadmin-ajaxの使用量を確認する方法をご覧ください。また、WordPressのログには、常にadmin-ajaxリクエストが表示されます。Kinstaのお客様は、MyKinsta組み込みのAPMツールも便利です。

次のステップは、admin-ajax.phpトランザクションを掘り下げて、最も時間のかかっているデータベースクエリを確認します。「Trace Details（トレースの詳細）」または「Database queries（データベースクエリ）」タブで確認できます。

クエリ自体が問題を特定する指標になることもありますが、今回の例の場合はそうではありません。しかし、/gp-premium/フォルダーが手掛かりになりました。これは先ほど見た問題の原因であると思われるgp-premiumプラグインです。通常、「Plugins and themes」タブと「Trace Details」の両方に共通して表示されている場合は、良い指標になります。

...s/gp-premium/library/image-processing-queue/includes/wp-background-process.php

続いては、Googleを開きます。

「Image Processing Queue（画像処理キュー）」で検索すると、最初にヒットしたのはDelicious BrainによるImage Processing Queueプラグインでした。説明に目を通すと、WordPressテーマの画像処理に使用されているプラグインであることがわかります。一般に、画像サイズはWP Queueを使ってバックグラウンドで生成されます。

「GeneratePress」で検索すると、最近の変更履歴がヒットし、GeneratePressの画像リサイズツールが、Aqua ResizerからImage Processing Queueに変更されていることがわかりました。これは例のサイトがテーマを更新した頃に行われており、サイト自体には特に大きな変更はありませんでした。だからこそ、この変更履歴は貴重な手がかりとなります。このように、トラブルシューティングは時にこういう細かな欠片を集めていく作業になります。

不可解なことに、GeneratePressを動かしている他のサイトにはこの問題は見られませんでした。このため、何が起こっているかの手がかりは掴めたものの、 100％の確信はありませんでした。次のステップは、ステージング環境を作成してWordPressサイトのデバッグを行うことです。

3. 本番環境に影響を与えずにステージング環境でサイトをデバッグ

問題のトラブルシューティングには、ステージング環境を使用するのが便利です。Kinstaでは、各サイトに数回のクリックで簡単にステージング環境を作成可能です。MyKinstaにログインし、本番サイトをステージング環境にコピーします。ご利用中のWordPressサーバーでステージング環境を利用できない場合は、WP Stagingのようなプラグインを使って作成することも可能です（やや難易度が高くなるが）。

ステージング環境を作成したら、まずすべてのプラグインを無効にします。これは、コンピュータを再起動してみるくらい初歩的なステップですが、案外多くの人が見落としがちなトラブルシューティングです。

必ずまずはすべてのプラグインを無効にしましょう。WordPress管理画面の「プラグイン」ページを開いて、すべてのプラグインを選択し、「一括操作」ドロップダウンから「無効化」を選択するだけでOKです。

プラグインをすべて無効化すると、先ほど見たNew Relicの応答時間がすぐに通常値まで下がりました。これはつまり、プラグインに問題があり、懸念していたgp-premiumプラグインが原因である可能性が非常に高いことを意味します。

そこで、gp-premiumプラグインのみを再度有効化し、問題が再発するかを見てみます。結果は以下の通り、読み込み時間の異常はすぐに現れました。

これで、パフォーマンス問題の原因が、gp-premiumプラグインにあることが決定的となりました。問題は画像処理キューから発生しているように見えたため、続いてはcronジョブとTransientの確認です。これらはキューの種類を問わずチェックすることが重要です。自動読み込みされるデータもよく原因になりがちです。

関連記事：WordPressの「予約投稿の失敗」エラーの処理方法（2つの方法）

Transientとは、WordPressの簡易キャッシュ機能です。Transientは、Pippin Williamsonによる無料プラグインTransients Managerで素早く見つけることができます。このプラグインを有効化すると、wp_image_processing_queue_process_lockというTransientが目につきました。1分で期限が切れるように設定されており、次々と発見されました。

Transients ManagerプラグインでTransientを削除することはできますが、今回の場合はうまくいきませんでした。そこで、phpmyadminにログインしてデータベースを調査することに。Transientsはwp_optionsテーブルに保存されているため、「Search」タブでオプション名を含む行を検索してみます。

SELECT * FROM wp_options WHERE option_name LIKE '%wp_image_processing%'

その結果、%wp_image_processing%を含む行が、695,846行検出されました。

ここで再びステージング環境の出番です。本番サイトに影響を与えることなく安全にテストを行うことができます。「SQL」タブから以下のクエリを実行して、検出した%wp_image_processing%を含む行をすべて手動で削除しました。

DELETE FROM wp_options WHERE option_name LIKE '%wp_image_processing%'

すると、削除した直後から、サイトの応答時間が正常に戻りました。

先にも触れましたが、GeneratePressを使用していた他のサイトではこのような問題は見られず、データベースに余計な行も見られませんでした。開発者のせいではなく、Transientキャッシュの破損が原因で、更新時に何かが削除されずに残ってしまったことが原因と思われます。

この問題は、どのようなプラグインやテーマでも起こり得ます。

ここまでの作業を自分で行うことに抵抗がある場合は、このような問題を解決する別の方法として、以下のステップもご覧ください。

4. 業界トップクラスのサポートを受けられるサーバーに投資する

このような問題がいつ発生するかわからないからこそ、Kinstaのような高性能WordPressサーバーに投資することに価値があります。

不備のあるコードを劇的に改善してくれるアーキテクチャやホスティング会社は存在しません。Kinstaで稼働するサイトであっても、プラグインの更新不良や、Transientの破損などにより問題が発生することがあります。これを踏まえ、Kinstaでは、自動バックアップ、ステージング環境、New Relicサポートなどをデフォルトで提供しています。これらの機能は、サイトのセキュリティを強化し、問題を迅速にトラブルシューティングするのに役立ちます。加えて、WordPressに精通したエンジニアのみで構成されたカスタマーサポートを24時間年中無休で提供しています。

今回ご紹介したようなパフォーマンスに関する問題の解決も常時お手伝いしています。コードの修正はサポートの範囲外になりますが、解決に向けた道標を提示することは可能です。今回のような場合は、New Relicを有効にしてしばらく実行し、KinstaのサポートスタッフにWordPressサイトの調査を依頼するといった、似たようなプロセスが必要になるかもしれません。

Kinstaをご利用でなくても、24時間いつでも利用でき、手厚いサポートを受けられるホスティングサービスを利用することを強くお勧めします。Kinstaは、カスタマーサポートの質に徹底的にこだわり、厳しい審査の上、応募者の1%未満しか採用していません。

インフラストラクチャに関しては、パフォーマンスと負荷に柔軟に対応するものを選ぶことが重要です。Kinstaでは、パフォーマンスを重視した以下のような機能を揃えています。

• 隔離コンテナ技術（LXCソフトウェア）を採用し各サイト専用のリソースを確保
• 世界37箇所のデータセンターから訪問者に近い場所を選択してレイテンシを削減
• Google Cloud Platformのプレミアムティアネットワークのみを利用し、光速ネットワークを実現
• 常に最新・最速バージョンのPHPをサポート（KinstaはPHP 5.6よりも3倍高速なPHP 7.2を最初にサポートしたマネージドホスティング）
• Cloudflare統合によりCDNを追加料金なしで使用可能

その他、Kinstaが他のサービス異なる違いはこちらでご紹介しています。

5. ウェブ制作会社を利用する

最近では、ウェブサイトの制作から保守管理までを代行する、WordPress制作会社が増えています。Kinstaのようなホスティングサービスとは異なり、WordPressサイトで必要になる以下のような面倒な作業を丸投げすることができます。

• Google Search Consoleのセットアップ
• Google アナリティクスの統合
• 週間キーワードランキング＋分析レポート
• SNS分析ツール
• モバイル・タブレット最適化
• プラグイン開発
• 編集作業（ロゴの更新やWooCommerce商品の追加など、より細かな作業を行なってくれる会社も）

また、多くの制作会社や代行業者は、毎日または毎週の稼働率とパフォーマンス監視も行ってくれます。Kinstaの代行業者ディレクトリでは、信頼できるおすすめの会社をご紹介しています。

6. 開発者に連絡する

WordPressのパフォーマンス問題の原因を特定したら、開発者に連絡を取ってみるのも方法です。多くの場合は、問題の詳細を知りたがり、ヘルプを提供してくれます。

今回の例では、GeneratePressの開発者に連絡を取ったところ、すぐに以下のような返答を受けることができました。破損したTransientが原因であると予想していましたが、この問題を受けて、画像のキューイング（順番待ちの管理）方法が変更されることになりました。このように、利用者によるフィードバックは有益なものであり、開発者がプラグインやテーマで何を実装し、何を変更するのが良いのかをより良く判断するための貴重な情報になります。

7. WordPress開発者を採用する

最後に、WordPress開発者に依頼して、問題を解決してもらうということも可能です。使用中のプラグインにコードの不備が見つかったが、開発者がそれを修正できないか、または修正する気がない場合などは検討してもいいかもしれません。または、Kinstaのようなホスティング会社のサポート範囲を超えるパフォーマンスの最適化が必要かもしれません。

その他のリソース

Kinstaはパフォーマンスを常に重視しており、WordPressのデバッグに関する解説記事を多数公開しています。以下のような記事も参考にしてみてください。

• WordPressのレンダリングを妨げるリソースを除外する方法（CSSとJavaScript）
• WordPressでの「ブラウザキャッシュを活用する」という提案の修正・解決方法
• 「500 Internal Server Error」エラーの解決方法
• サイトで「504 Gateway Timeout」エラーを解決する方法
• 「502 Bad Gateway」エラーの解決方法

まとめ

専門知識を持つ方も、そうでない方も、WordPressのパフォーマンスに関する問題は必ず解決することができます。まずは、優れたホスティング会社を利用することが、問題発生の備えとなります。

また、New Relicのような優れたツールをうまく活用することで、問題のデバッグを効率化することができます。そして、WordPressコミュニティには有能な開発者が多数存在します。気兼ねなく質問したり助けを求めてみたりしてみましょう。開発者を雇用することも検討してみてください。