WordPressベンチマーク：ホスティングのパフォーマンスを再現性のある方法でテストする

WordPressのベンチマークが明らかにすること

A WordPressのベンチマーク まず具体的な質問から始まります。「特定のページは、定められた条件下で素早く読み込まれるか？」。ブラウザは、HTML、画像、スクリプト、その他のリソースを読み込み、ページを表示します。その結果は、ホスティングサーバーの速度だけでなく、これらの構成要素の相互作用によって決まります。

2つ目の質問は、以下の点に関するものです。 負荷下での応答特性: 所定のプロファイルに基づくリクエストが送信された場合、応答時間やエラーはどのように変化するのでしょうか？単一のページアクセスだけでは、その答えは得られません。逆に、HTTP負荷テストを行っても、ブラウザがページ全体を視覚的に表示できる状態まで構築するのにどれくらいの時間がかかるかは、直接的には分かりません。

公開ブログ記事の場合、ページキャッシュが完成したHTMLを配信したり、CDNがリソースやレスポンスを測定地点の近くで提供したりすることが可能です。同時に、テーマ、プラグイン、画像、外部スクリプトも結果に影響を与えます。ページの表示速度を低下させるその他の要因については、以下の記事で解説しています。 WordPressに潜むパフォーマンスの妨げとなる要因.

ホスティングの影響を把握するには、2つの比較質問が役立ちます。その スタックの比較 可能な限りウェブサイトと設定を統一し、残っている相違点を記録します。プランの比較では、提供されている構成（それぞれのキャッシュやサービスを含む）を確認します。これは購入判断において実用的ですが、純粋なサーバー性能だけを切り取って評価するものではありません。

そのため、どのページ、どの料金プラン、どの環境が結果に該当するかを明確に記録しておいてください。テスト対象のブログ記事の利点は、ログインしたアカウントでの閲覧では異なる結果となる可能性があります。この測定結果は、記録された条件および期間にのみ適用されるものであり、一般的な「テスト優勝者」を決定するものでも、パフォーマンスを保証するものでもありません。

ブラウザ測定とフィールドデータの理解

Lighthouse を使った WordPress の速度テストでは、 実験室での撮影 特定の測定条件下でのページ。したがって、ブラウザプロファイル、デバイスまたはエミュレーション、ネットワークプロファイル、測定場所、およびツールのバージョンは、ログに記録する必要があります。そうして初めて、後で2つの実行結果が実際に比較可能かどうかを判断することができるのです。

Lighthouseパフォーマンススコアは、複数の指標を重み付けして集計したものです。コンテンツや測定条件の変化によって変動する可能性があり、どの個別の指標が変化したのかが分かりにくくなります。同じプロファイルで測定を繰り返し、最高のスコアだけを選ぶのではなく、すべての実行結果の個別の値を記録してください。

重要な指標の一つにLCPがあります。これは、最も重要なコンテンツ要素が視認可能な状態で読み込まれるタイミングを示すものです。CLSは、利用中に発生する予期せぬレイアウトのずれを測定します。INPは、ユーザー操作に対する応答性を表す指標であり、これを測定するには実際に記録されたユーザー操作が必要であり、単なるページの読み込みだけでは決定されません。

一方、Chrome UX Report（略称：CrUX）は、利用可能な場合、 フィールドデータ 参加している実際のユーザーによるアクセスに基づくものです。これらの体験は、ユーザーのデバイスやネットワークなどの要因によって異なります。すべてのページで利用できるわけではなく、管理された条件下で実施される実験室でのテストとは異なる質問に対する回答となります。

各値について、それがラボ環境での測定結果か、実環境での測定結果かを明記してください。例えば、純粋なHTTPリクエストではステータスや応答時間を測定できますが、ブラウザのレンダリングやインタラクションは自動的に実行されません。そのため、このデータからはLCP、CLS、INPをブラウザ体験として読み取ることはできません。

キャッシュの階層を正しく区別する

A ページキャッシュ 繰り返し行われるリクエストに対して、完成したHTMLを保持しておくことができます。一方、オブジェクトキャッシュは、WordPressが処理を行う際に必要なアプリケーションデータを保存します。さらに、ブラウザはすでに読み込まれたリソースをローカルで再利用することができ、CDNは元のサーバーとは別のレベルでコンテンツをキャッシュすることができます。

ページキャッシュがウォームアップされている状態では、文書化されたウォームアップ期間を経た後、公開ページを繰り返し読み込みます。これはアクセス頻度の高いコンテンツには重要ですが、その動的生成にかかるコストについてはほとんど示唆しません。どのURLがウォームアップされたか、またその際に適用されていたキャッシュルールやCDN設定を記録しておいてください。

キャッシュされないリクエストを行うには、 キャッシュバイパス 単に受け入れるのではなく、納得のいく形で検証すること。登録済みのセッションは、別のルールに従ったり、パーソナライズされたコンテンツを提供したりする場合がある。そのセッションにおける実際の応答を確認すること。誤った情報や古い情報を返すような場合、高速な取得もほとんど意味がない。

新しいブラウザの状態での初回アクセスでは、サーバーやCDNのキャッシュが空であるとは限りません。同様に、CDNの失敗が必ずしもアプリケーションキャッシュのクリアを意味するわけではありません。キャッシュヘッダーは手がかりとなる場合がありますが、プロバイダーによっては、関与する各層の状態を証明するものではありません。そのため、利用可能な設定や検証方法についても記録しておく必要があります。

WordPressのオブジェクトキャッシュは、適切な永続化拡張機能がない限り、原則としてそのリクエストの範囲内に限定されます。定数 WP_CACHE これだけでは、Redisも自動で動作するキャッシュソリューションも有効化されません。永続的なオブジェクトキャッシュとして、RedisとMemcachedがどのような役割を果たせるかについては、以下の記事で解説しています。 WordPressホスティングにおけるRedisとMemcached.

比較と承認の準備

ホスティングサービスを比較するには、まず 同等のウェブサイトの状況. 同じコンテンツ、同じデータセット、同じテーマ、および同じプラグイン（そのバージョンを含む）を使用した、クリーンなコピーを作成してください。個人情報や本番環境のアクセス情報を削除または置換しつつ、テストサイトが依然として意図したユースケースを再現できるようにしてください。

PHPおよびデータベースのバージョンを同じにし、関連する設定も可能な限り統一してください。 解消できない差異、または契約したパッケージに固有の差異については記録しておいてください。各標準パッケージの比較と、可能な限り条件を揃えたスタックの比較では、得られる結論が異なります。その結果を、単にサーバーの性能のみに帰することはできません。

最初の実行前に、測定計画を策定してください。その計画は、他の人がその構成を理解し、再実行時に差異を認識できるほど具体的に記述する必要があります。以下のチェックリストでは、ホスティングサービスの特性と、ウェブサイトおよび測定の特性を区別しています。

• 両環境の料金プラン、リソース制限、サーバーの設置場所、およびソフトウェアのバージョン。
• テスト用URLおよびページの種類、ログイン状況、クッキー、ならびに使用されたテストアカウント。
• CDN、ページキャッシュ、オブジェクトキャッシュ（ルール、ウォームアップ期間、スケジュールされたバイパスを含む）。
• 測定場所、ツールバージョン、ブラウザおよびデバイスのプロファイル、ネットワーク環境、測定時刻、および測定回数。
• 負荷プロファイル、責任範囲、合意されたテスト期間、および具体的な中止基準。

負荷テストについては、以下の点を合意してください。 リリース 負荷をかける前に、すべての責任者および必要に応じてホスティング事業者との調整を行ってください。担当者、リソースの制限、および障害発生時の対応手順を明確にしておきましょう。第三者のサービスについては、その同意なしに利用を排除してください。特に、実際の支払い、注文、通知などが行われないよう防止してください。 テスト用コピーが実際にそのような処理を阻止しているかどうかを、事前に確認してください。

代表的なページの測定コンセプト

ツールは、個々の数値がどれだけ優れているかではなく、質問の内容に基づいて選択してください。A 測定コンセプト 各行にページタイプとキャッシュ状態を割り当てます。この表は、それぞれのアプローチによってどのような結果が得られるか、またその有効範囲がどこまでかを示しています。

公開ブログ記事については、特定のブラウザとネットワークプロファイルを使用して、同じ代表的なURLを複数回測定します。CDNやページキャッシュが有効になっているかどうか、また測定前にページがどのようにウォームアップされたかを記録しておきます。これにより、その公開ページの読み込み体験を評価することができ、ログイン状態での体験が自動的に評価されることはありません。

動的な検索やアカウントの表示には、共有されたテストデータと、必要に応じてテストアカウントを含む独自の測定シリーズが割り当てられます。ステータスコードだけでなく、レスポンスが検索クエリまたはログインしたアカウントと一致し、最新のものであるかどうかも確認してください。さらに、スケジュールされた キャッシュバイパス 実際に機能しているかどうか；クッキーだけではそれを証明することはできない。

応答時間に違いが見られるからといって、それで原因が特定されたわけではありません。アプリケーションロジック、データベースへのアクセス、永続的なオブジェクトキャッシュ、そしてホスティング環境のそれぞれが、結果に影響を与えている可能性があります。個々の遅いクエリを特定のボトルネックの証拠として扱うのではなく、違いを体系的に記録し、その後、的を絞って調査してください。

負荷テストを段階的に実施する

明示的に公開が許可されたテストページで、アクセス数を最小限に抑えて開始してください。ステータスとコンテンツを確認し、本番環境に悪影響が及ばないことを確認してください。その後に初めて、ショップの公開済み商品ページなどに対して、別途調整された負荷テストを実施します。 実際の注文、支払い、通知は一切行わないでください。

～を計画する 段階的な負荷 初期レベル、所要時間、および段階的な難易度設定を明記する。エラー、応答時間、その他の利用可能な運用指標について、事前に測定可能な中断基準を定め、中断時の連絡先も明確にしておく。明示的に許可された手順に厳守すること。製品画面の表示だけでは、テストされていないチェックアウトプロセスについて何ら示唆するものではない。

クローズド負荷モデルでは、仮想ユーザーインスタンスは、現在の反復が終了するのを待ってから、次の反復を開始します。アプリケーションの処理速度が低下すると、これにより提供される負荷が減少する可能性があります。 このモデルは、まさにこの「待機」が重要な要素となるプロセスに適していますが、一定の到着率を維持するものではありません。

A オープンロードモデル 一方、以前の反復が完了しているかどうかに関係なく、新しい反復を計画します。そのためには、負荷発生装置に十分な容量と利用可能な仮想ユーザーインスタンスが必要です。反復を開始できない場合、テストは計画されたプロファイルを達成できません。したがって、開始されなかったこれらの反復についても記録してください。

設定されたレートと実際に達成されたレートの両方を記録してください。1秒あたりの反復回数が1秒あたりのリクエスト数と一致するのは、各反復が正確に1つのリクエストを生成する場合に限られます。 さらに、応答時間の分布、エラー、タイムアウト、およびコンテンツの正確性の検証も記録してください。エラーを含む応答がある状態で高いスループットを達成しても、それは成功した負荷テストとは言えません。

測定データの系列を、その経緯が追跡可能な形で評価する

一連の測定結果は、その範囲と併せて初めて意味を持つ。 したがって、テスト対象の各ページおよび各負荷ステップについて、分析対象となったリクエスト数、エラー数、タイムアウト数を記録してください。成功したレスポンスと失敗したレスポンスを区別する際は、失敗事例をレポートから除外しないようにしてください。エラーが多い状態でレスポンスタイムが短いからといって、それが信頼性の高い高速なサービスであるとは限りません。

仝 中央値 ソートされた成功した測定値の中央値を表します。 95パーセンタイル（略してp95）は、補足として、これらの測定値の約95パーセントが下回る閾値を示します。クエリの数が少ない場合、p95は個々の観測値に大きく依存するため、常に標本サイズを明記し、差異の解釈には慎重を期してください。

各実行ごとに、負荷モデルと実際に達成されたレートも記録しておいてください。設定されたレートだけでは、ジェネレータが計画されたすべての反復を開始できたかどうかはわかりません。以下のテンプレートは測定が行われるまで空白のままにしておきます。複数の実行については、それぞれ個別のログが作成されます。

生データ、テストスクリプト、設定情報をログとともに確実に保存してください。そうすることで、後でどのクエリが分析対象となったか、また2つのデータ系列がそもそも比較可能かどうかを確認できるようになります。 後から単に最も処理が速かった実行結果だけを選んではいけません。結果が大幅に重なっている場合、観察された差異は変動の範囲内にある可能性があります。

指標に加えて、内容上の異常（例えば、期待されていた口座画面の代わりに予期せぬログイン画面が表示されるなど）も記載してください。 技術的に成功したステータスであっても、正しいページが配信されたことを証明するものではありません。このような逸脱はエラーの説明とは別に記載する必要があり、計画された意思決定のための測定データセットを無効にしてしまう可能性があります。

原因を絞り込み、再度測定する

まず、返されたレスポンスからトラブルシューティングを開始してください。内容、ログイン状態、テスト対象のURLは正しいでしょうか？その後、ドキュメントに記載されている内容を キャッシュの状態 および測定環境。Cookieの違い、測定場所の変更、あるいはCDNルールの変更などにより、実際のアプリケーションスタックのパフォーマンスに変化がないにもかかわらず、2回の実行結果が異なってしまうことがあります。

その後に初めて、利用可能な運用データが原因の絞り込みに役立ちます。リソースの使用状況やキューはボトルネックを示唆し、アプリケーションやデータベースの情報は処理に時間がかかっていることを示す場合があります。HTTPの応答速度が1回だけ遅いというだけでは、原因を特定することはできません。WordPressでは、ホスティングに加え、ソフトウェア、設定、コンテンツも影響要因として挙げています。

「前後比較」を行う際は、永続的なオブジェクトキャッシュの導入など、意図的に1つの設定のみを変更してください。ウェブサイトの状態、テストページ、負荷プロファイル、測定場所は可能な限り同一に保ち、それぞれのキャッシュのウォームアップ状況も記録してください。 WordPressのオブジェクトキャッシュは、適切な永続的な実装がない場合、個々のリクエストに限定されてしまうため、実際に機能しているかどうかを確認する必要があります。

変更の前後で複数の実行を行い、それらを時間的に分散させてください。そうすることで、その違いが繰り返し発生しているのか、それとも通常の変動と重なっている可能性があるのかをより正確に把握できます。 その際、中央値やp95だけでなく、エラー、回答内容、達成率も比較してください。そうしないと、一見加速しているように見える現象が、テスト条件の変更に起因している可能性があります。

たとえ入念に比較を行ったとしても、すべての要因を網羅できるわけではありません。共有ホスティングの場合、他のユーザーや確認できないインフラストラクチャが結果に影響を与える可能性があります。リソースやキューに関するデータが不足している場合は、その不足点を明確に記録し、推測される原因については「実証された事実」ではなく「仮説」として記述してください。

ホスティングの結果を正しく評価する

ホスティングの決定は、ウェブサイトにとって重要なページやプロセスに基づいて行いましょう。温かいページキャッシュを持つ公開ブログ記事は、ログイン後のアカウント閲覧とは異なる負荷を生み出す可能性があります。したがって、公開ページでのキャッシュヒット率が高いからといって、パーソナライズされた応答が高速であることや、チェックアウト処理が堅牢であることを示すものではありません。

比較を行う前に、各プロセスにおいてどの応答時間、エラー率、および負荷プロファイルが許容範囲内であるかを定義してください。 その後、記録された測定データが、合意された条件下でこれらの要件を満たしているかどうかを確認してください。これには、内容の正確性や処理の安定性も含まれます。単にリクエスト率が高いというだけでは、判断の根拠としては不十分です。

セット 仮想ユーザー 同時にアクセスしている実際の訪問者とは異なります。その挙動はテストスクリプトと負荷モデルに基づいており、クローズドモデルでは、各インスタンスは現在の反復処理が終了するのを待ってから、次の反復処理を開始します。したがって、適切な挙動モデルがなければ、その数から実際の訪問者数を推定することはできません。

結果について、料金プラン、ウェブサイトの状況、テスト対象のURL、キャッシュおよびCDNのルール、測定場所、ならびに測定期間を併せて報告してください。また、可能な限り同等のスタックを比較したのか、それとも各社が提供する総合パッケージを比較したのかについても区別してください。 パッケージ比較では、構成の違いが結果に影響を与える可能性があります。パッケージ比較だけでは、サーバーの純粋なパフォーマンスを自動的に特定することはできません。

各行の重なりが著しい場合や、周囲の環境を十分に制御できない場合、「信頼できる差は確認されなかった」という表現は、妥当かつ有用な結論となり得ます。これは、あらゆる条件下で両方の提案が同じ速度であることを意味するものではありません。単に、今回のテストでは望まれる区別が得られなかったことを意味するに過ぎません。

運用監視のためには、測定プロファイルを保存し、大規模な変更後や合意された間隔で、選択したブラウザおよび負荷測定を繰り返し実施してください。新しい結果は、対応する過去のデータ系列とのみ比較し、コンテンツ、バージョン、キャッシュルールの変更内容を記録してください。 負荷テストについては、引き続き承認済みの実施時間帯と、合意された中止基準を設定する必要があります。