ワードプレス

クエリモニタWordPressを正しく使うパフォーマンスの問題を可視化する

プラグイン クエリーモニター 私は、遅いSQLクエリ、欠陥のあるフック、高価なHTTPリクエストを即座に視覚化し、特定のコンポーネントに割り当てます。これにより、WordPressの読み込み時間が遅い本当の原因を見つけ、コード、プラグイン、テーマ、ホスティングに的を絞った最適化を実施することができます。.

中心点

インストール 最初のステップ管理バーを読み、パネルを理解する
クエリ 分析: SQLクエリ、呼び出し元、コンポーネントが遅い
資産とリクエスト：JS/CSSと外部APIの効率化
ホスティング 評価: メモリ、PHPのバージョン、データベースの待ち時間
ワークフロー 確立：測定、最適化、再チェック

クエリ・モニターとは何か？

をセットした。 クエリーモニター を使用して、ページの内部処理を透明にすることができます：データベースクエリ、フック、PHPエラー、HTTPコール、スクリプト、スタイル。このツールは、ページ生成時間、クエリー数、メモリ消費量がどのように構成されているかをリアルタイムで表示してくれる。数回クリックするだけで、どのプラグインやテーマが時間を食っているのか、外部サービスがどれだけ貢献しているのかがわかる。こうすることで、推測を避け、確かなデータに基づいて決断を下すことができる。指標. .これはトラブルシューティングの時間を節約し、次のステップへの明確なプランを与えてくれる。.

インストールと最初のステップ

インストールする クエリーモニター バックエンドのプラグイン検索から、他のプラグインと同様に有効化してください。すると、ロード時間、クエリー数、必要メモリがコンパクトに管理バーに表示される。ワンクリックで現在ロードされているページのパネルが開くので、コンテキストから離れる必要がない。ログインした管理者だけがこのデータを見ることができ、訪問者は影響を受けず、何も気づきません。 フェードイン. .ページビューを何度か重ねると、自分のインストレーションの典型的な値がわかるようになり、異常値をより早く認識できるようになる。.

最も重要な見解を正しく読む

概要 "タブでは、ページ生成時間、データベースクエリの数、そして、"データベースクエリ "のピーク値を見ることができる。 メモリ. .クエリ」タブでは、各SQL文の実行時間、呼び出し元、コンポーネントが一覧表示され、コードの場所について直接的な結論を導き出すことができる。HTTPリクエストのエリアでは、APIやライセンスへの高価なブロック呼び出しに気づく。スクリプトとスタイルの登録では、どのファイルが登録され、ロードされているかがわかるので、使用していないアセットのスイッチを切ることができる。総合的な診断のために、私はしばしばこれらの洞察を短いパフォーマンス監査, ターゲットを絞って優先順位を設定する。.

その他のパネルと機能の一覧

クエリとHTTPコールに加えて、クエリ・モニターは、私が特に使用しているその他の領域についても貴重な洞察を提供してくれる：

テンプレートと条件: どのテンプレートファイルが実際にレンダリングされているのか、どのテンプレート部分が含まれているのか、どの条件タグ（is_singular、is_archiveなど）が適用されているのかがわかります。これにより、パフォーマンスが重要なロジックをテーマ内の適切な場所に移動させることができます。.
PHPエラーと非推奨ノート通知、警告、古い機能は、微妙にページを遅くする。不必要な出力やエラー処理は時間を浪費し、後の更新を難しくするので、私はこれらのメッセージを修正する。.
フックとアクションどの関数がどのフックにアタッチされているかを認識し、initやwpのデータベースクエリなど、実行が遅すぎるオーバーロードされたアクションを見つける。.
言語とテキスト・ドメインロードされた.moファイルとテキストドメインは、翻訳が不必要なI/Oを引き起こすか、複数回ロードされるかを示してくれる。.
周辺環境PHPのバージョン、データベースドライバ、サーバー、アクティブな拡張機能の詳細によって、OPcacheの最適化が欠けていたり、PHPの設定が不適切であったりといったボトルネックを発見することができる。.

系統的分析：症状から原因へ

私はゆっくりと認識することから始める ページ を開き、パネルを開いた状態でロードします。そして、相対的な違いを見るために、より速いページと読み込み時間とクエリー数を比較します。時間が大きく異なる場合は、クエリタブを開き、期間でソートして最悪のクエリをチェックします。クエリー数が正常に見える場合は、外部リクエストとロードされたアセットを調べます。これらのパズルのピースから明確な絵が浮かび上がり、実際の原因へと一歩ずつ導いてくれる。.

ターゲットフィルタリング：コンポーネント、呼び出し元、重複

フィルター機能を一貫して使うことで、細部に迷わないようにしている。クエリパネルでは、まず高速なクエリをすべて非表示にし、内部限界値以上のクエリに焦点を絞る。次に コンポーネント (特定のプラグインなど）または 発信者 (関数/ファイル)でソースを分離する。繰り返し同じクエリを重複を使って、キャッシュされた単一のクエリに統合します。テーマのデバッグのために、私はWP_Queryのクエリーバリアント（orderby、meta_query、tax_query）を見ています。.

低速クエリの発見と緩和

私は、遅いクエリは、その長い時間、多くの戻り行、または目立つ呼び出し元によって認識する。 コード. .典型的なパターンは、WHEREなしのアスタリスク付きSELECT、ループ内のN+1アクセス、インデックスなしフィールドのメタクエリである。データ量を減らし、WHERE条件を制限し、出力に必要なデータレコードが少ない場合はLIMITを設定する。定期的なデータについては、トランジェントやオブジェクトキャッシュに結果を保存し、データベースでの不要なラウンドトリップを避ける。クエリがプラグインから来たものであれば、設定をチェックするか、その動作を著者, コンフィギュレーションが十分でない場合.

オブジェクト・キャッシュとトランジェントを正しく使用する

私は特に、繰り返し実行されるクエリーや高価な計算をキャッシュしている：

トランジェント定期的に変化するデータ（ティーザーリストなど）には、適切な間隔のトランジェントを使う。ランタイムは技術的に適切なもの（数分から数時間）を選び、適切なイベント（投稿の公開後など）で無効にします。.
永続オブジェクトキャッシュRedisやMemcachedのキャッシュが有効な場合、Query Monitorにヒット率が表示される。ヒット率が低ければ、キーに一貫性がない、TTLが短すぎる、あるいは頻繁に無効化されることを示している。キーを統合し、不要なフラッシュを減らす。.
シリアルデータオプション・テーブルの大きな直列化された配列は取り除かれる。オートロードオプションはすべてのページに負荷をかけるので、私は批判的に精査する。可能な限り、大きなオプションは小さな、特に負荷のかかる単位に分割する。.

キャッシング戦略を導入してこそ、サーバーリソースを増やす価値がある。そうでなければ、症状を覆い隠し、副作用をコントロールできなくなるだけだ。.

SQLチューニングの実際：制限値の表

決断には具体的なものが必要だ しきい値. .以下の表は、私が異常をより迅速に分類するために使用している実用的な値を示している。これは個々の分析に取って代わるものではないが、優先順位付けのための確かな指針を与えてくれる。私は常に、期間、頻度、テンプレートへの影響の組み合わせを評価する。これに基づいて、私は無作為に実験するのではなく、的を絞った対策を講じる。.

信号	しきい値	典型的な原因	緊急措置
個別のクエリー期間	> 100ミリ秒	WHERE/LIMITの欠落、不適切インデックス	列の制限、インデックスのチェック、結果のキャッシュ
クエリー総数	> ページあたり200	N+1パターン、多数のメタクエリを持つプラグイン	データのプリロード、ループのカスタマイズ、プラグイン設定の合理化
リターンライン	> 1,000行以上	フィルタリングされていないリストページネーション	WHERE/LIMITの設定、ページネーションの有効化
メモリーピーク	> 80% メモリ制限	大容量アレイ、未使用データ、画像処理	データ量を減らし、オブジェクトを解放し、必要に応じて制限を増やす。
長い合計時間	サーバー時間 > 1.5 s	外部 API, I/O待ち時間、弱いサーバー	リクエストのキャッシュ、サービスのチェック、ホスティングパフォーマンスの向上

私は制限値を厳格なルールとしてではなく、出発点として扱う。100回実行される80ミリ秒のクエリは、200ミリ秒の単一のクエリよりも重くなります。テンプレート内の位置も重要で、ヘッダーでブロックされるクエリは、フッターで頻繁に呼び出されるクエリよりも強い影響を与えます。クエリモニタでは、これらの相関関係を時間をかけて評価し、最も効果的な対策を最初に講じます。 レバレッジ効果.

REST API、AJAX、管理者リクエストを測定する

多くのボトルネックは、古典的なページビューではなく、バックグラウンドプロセスにある。そのため、私はターゲットを絞ったチェックを実施している：

RESTエンドポイント使用頻度の高いエンドポイント（検索サジェストなど）については、クエリ、メモリ、レスポンスタイムを個別に測定します。目立つエンドポイントは、より厳しいWHERE条件、より狭いレスポンスオブジェクト、レスポンスキャッシュの恩恵を受けます。.
AJAXコールN+1クエリはしばしば管理者やフロントエンドのAJAXルーチンに忍び込む。私はデータアクセスをバンドルし、結果をキャッシュし、ページネーションに厳しい制限を設けています。.
管理ページ過負荷のプラグイン設定ページは、しばしば何百ものクエリを生成する。私はそこで重複を特定し、チームやプラグインプロバイダーと調整について話し合います。.

キャッシュや並行プロセスは数値を歪める可能性があるため、同様の条件で測定を繰り返すことが重要である。.

HTTPリクエスト、スクリプト、スタイルの最適化

私は、対応するパネルにある外部からの要請を、その期間、終了点、および回答. .目立つサービスがあれば、キャッシュが理にかなっているか、時間的にクエリを切り離せるかどうかをチェックする。スクリプトやスタイルについては、ページが本当に必要としているアセットをチェックし、特定のテンプレートで不要なものをブロックする。ライブラリを統合し、重複するバリアントを削除すれば十分なことが多い。インターフェイスのトピックについては、私は REST API のパフォーマンス, なぜなら、バックエンドの待ち時間はフロントエンドの印象に強く影響するからだ。.

キャッシュトラップとCDNの影響を正しく分類する

アクティブなページキャッシュでクエリモニタが高いサーバー時間を計測した場合、ほとんどの場合、問題は次のようになります。曩にキャッシュ（PHP、DB、外部サービス）。私は 未キャッシュ ビュー（ログイン中、キャッシュの破壊）。逆に、CDNとブラウザのキャッシュは、フロントエンドの認識を歪める：高速配信は、遅いサーバー生成を隠し、キャッシュが空になったときに復讐する。これが、私がウォームとコールドの両方の状況をテストする理由だ。.

ウォームキャッシュ期待されるサーバー時間は非常に短い。それにもかかわらず高い場合は、高価なHTTPコールや大規模でダイナミックなブロックが原因であることを示している。.
コールドキャッシュ最初のピーク、たとえば最初の電話で画像が変換されたり、大きなメニューが設定されたりするときには注意しています。可能であれば、そのような仕事はバックグラウンドの仕事に移します。.

ホスティングとサーバーレベルを賢く評価する

さらにクリーン コード 環境が遅くなると限界に達する。クエリモニタでクエリは少ないが時間が長いと表示された場合、CPUパフォーマンス、データベースのレイテンシ、PHPのバージョンを調べます。メモリの上限が低すぎる場合、ピークロード時に頻繁にピークが発生し、ページが失敗することになります。データベースエンジンとキャッシュレイヤーも、最適化が効果的かどうかを判断します。下部構造が弱い場合は、レスポンスタイムの向上が他のすべての指標を補強するので、アップグレードを計算します。.

測定方法：外れ値の代わりに比較可能な数値

有効な判断を下すために、私は測定ノイズを最小限に抑える。問題のあるページを何度か連続して読み込み、その時間の幅を観察し、同一の状態（ログインとログアウト、空キャッシュとウォームキャッシュ）を比較する。また、次のことも記録する。 ビフォー／アフター 一貫して：時間、ページ、サーバー負荷、特別なイベント（デプロイ、クーロン、トラフィックのピーク）。このようにして、ランダムヒットから本当の改善を見分けるのです。.

クエリモニタのベストプラクティス

私はプラグインを有効にしておく。 見本市, そして、分析が完了したら、それを無効にする。変更を加える前に、ステージング環境で作業し、明確な前後比較のために実際の値を記録します。プラグインを更新するたびに、管理バーを簡単にチェックし、新しい負荷のピークを早い段階で検出します。その結果を文書化し、実際の訪問者数と定期的に照合しています。常時監視のために、„ワードプレスの速度を測定する“バックエンドの外側で測定することで、その傾向を確認することができる。.

マルチサイト、ロール、セキュリティ

マルチサイトのセットアップでは、プラグインやテーマが異なるロードイメージを生成する可能性があるため、サイトごとにQuery Monitorを使用しています。疑わしいサイトを個別にチェックし、管理バーの値を比較することで、異常値を素早く切り分けることができます。セキュリティは保証されたままです：出力はデフォルトで管理者のみが見ることができる。管理者権限のない同僚が計測する場合は、別のステージング・インスタンスや一時的な共有を使って作業し、完了後に再び削除します。これにより、デバッグ出力は管理下に置かれ、一般に公開されることはありません。.

実践的ワークフロー：測定値をどのように扱うか

私はまず、最も重要な測定ラウンドから始める。 テンプレート スタートページ、アーカイブ、チェックアウトなど。そして、異常値をクエリ、外部リクエスト、アセット、サーバーといった原因に割り当てる。各原因に対して1つの対策を定義し、それを実施し、また測定する。効果が目に見えるようになったら、集中力を維持できるよう、すぐに次の工事現場に取り組む。このリズムは、同時に多くの調整をすることを防いでくれる。.

アンチパターンの認識と排除

私はいくつかのパターンをよく目にするので、それを積極的に探している：

ポストメタにN+1各投稿ごとにループで個別にメタデータをロードする代わりに、必要なメタデータを（フィールドとmeta_queryを使ったget_postsなどで）収集し、事前にマッピングしておく。.
orderby=meta_value インデックスなしインデックスのないメタ・フィールドをソートするのはコストがかかる。tax_queryに切り替えるか、スコープを縮小するか、適切なインデックスを追加するかを確認します。.
不要なオートロードオプションautoload=’yes'の大きなオプションは、’no'にして必要なときだけロードするようにすると、動作が遅くなります。.
スポンジ状の検索クエリwp_postsを使った広いLIKEフィルターは、データベースを凝縮します。私はより厳しいWHERE条件、特定の投稿タイプ、絞り込みフィールドを使っています。.
ダブルロード資産複数回登録されているライブラリ（スライダーやアイコンなど）を削除または統合して、1ページにつき1つの最新バージョンしかロードされないようにしています。.

日常生活のエラー画像

典型的な例：スライダーのアドオンが ページ 3つのスクリプトと2つのスタイルで構成されています。サブページでアンロードした後、レンダリング時間は顕著に減少します。また、ループでポストメタをロードする際にN+1クエリが頻繁に発生しますが、プリロードすることで解決しています。レスポンスタイムの長い外部ライセンスサーバーは、ページロードをブロックすることがある。すべての例において、Query Monitorは最初にどこから始めるべきかを明確に示してくれます。.

簡単にまとめると

と一緒に クエリーモニター 私はWordPressのインストールのX線画像を取得し、回り道をせずにブレーキを認識します。クエリ、HTTPコール、スクリプト、メモリ消費量をサイトの文脈で評価し、影響と労力を考慮して決定を下します。測定、適応、チェックという明確なワークフローが、結果を永続的なものにします。さらに、高速な下部構造と整頓されたプラグインが、最適化が一貫して効果を発揮するよう助けてくれる。ツールを定期的に使用すれば、パフォーマンスの問題を最小限に抑え、ユーザー・エクスペリエンスを顕著に向上させることができる。.