ホスティングプラン選択の際には、WordPressサイトの状態に最も合致するものを検討することが重要です。

たとえば、1か月あたり50,000人の訪問者がいるeコマースサイトでは、通常、同じ量のトラフィックが流入する普通のブログよりも多くのリソースが必要になります。

というのも、eコマースサイトはその性質上、動的であり、PHPとデータベースクエリのためにより多くのリソースを必要とする傾向にあります。

ここで大事になるのがPHPワーカーです。PHPワーカーとは何か、サイトでのリクエスト処理高速化のためにどのように使用されるかについては、以下をお読みください。

PHPワーカーとは?

WordPressサイトにおいては、PHPワーカーはページの作成、実行時間の決められたバックグラウンドでのタスクの処理などを行います。PHPワーカーは、サイトの訪問者に提供するHTMLページの生成に直接関わるため、これにより、サイトが同時に処理できるキャッシュされていないリクエストの数が決まります。

たとえば、WordPressサイトに2つのPHPワーカーがあり、 ページのキャッシュ設定がないとします。4つのリクエストがまったく同時にサイトに到着した場合、それらのうち2つはすぐに処理されますが、他の2つは最初の2つが処理を完了するまでキューで待機する必要があります。

Kinstaでは、ホスティングプラン階層ごとに、PHPワーカーの数が異なります。たとえば、ビジネス1プランにはサイトごとに4つのPHPワーカーがあり、エンタープライズ4プランには16のワーカーがあります。

当社ではサーバーレベルのキャッシュを実装していますが、キャッシュがバイパスされる時、または、ミスになった時のリクエストについては、リクエストごとに作業を行う必要があり、PHPワーカーが非常に重要になります。

通常、eコマースやフォーラムサイトでは、キャッシュされていないリクエストが数多く発生します。したがって、そのようなサイトでは、遅延やタイムアウトなしにすべてのリクエストが処理されるように、通常よりも多くのPHPワーカーが必要になります。

ただし、サイトが高度に最適化されていれば、またはPHPコード(例:複雑なテーマまたは多数のWordPressプラグイン)が多くなければ、各リクエストの処理はほぼ瞬時に行われるものです。2つのPHPワーカーと4つのリクエストであっても、4つすべてが迅速に処理されます。

簡単に言うと、PHPワーカーとは、PHPコードを実行するサーバー上のバックグラウンドプロセスです。

WordPressではどのようにPHPワーカーが使用されているのか

WordPressでPHPワーカーの使用を最適化する方法へと進む前に、まずはWordPressがPHPワーカーをどのように使用しているのか理解を深めましょう。

キャッシュの設定されていない環境での一般的なリクエストは次のようになります。

上記の手順の中で、ステップ3が最も時間とリソースを消費します(CPUとRAM)。データベースクエリを最小限に抑えた、効率的なPHPコードを備えた高度に最適化されたサイトであれば、比較的素早く3番目のステップをこなすことができます。

逆に、不必要なデータベースクエリを大量に実行する、最適化されていないPHPコードを持つサイトは、ステップ3の実行に多くの時間を費やします。この場合、リクエストがPHPワーカーを長時間占有することになります。

PHPワーカーとCPUの関係

WordPressのパフォーマンスとなると、PHPワーカーと利用できるCPUの関係性を考えることが重要です。

CPUリソースの不足が、あなたのサイトの懸念事項となっている場合、PHPワーカーの数を増やしてもサイトのパフォーマンスは向上しません。サイトで同時に処理できるリクエストの数が増える一方で、リクエストごとのパフォーマンスが低下するだけです。

これについてご説明します。

1本のホースが取り付けられた消火栓を想像してみてください。ホースが1本だけの時、消火栓からは十分な水圧で水が放出されます。では、この消火栓に10本のホースを取り付けたらどうでしょうか?

限られた水圧が、10本のホースに分散されます。そして、個々のホースにおける水圧は弱く、使い物にならないでしょう。この例では、消火栓そのものはCPUを意味し、ホースはPHPワーカーを意味します。

この例を念頭に置いて、もし、あなたのホストから(CPUについては触れることなく)ただPHPワーカーを増やすようにアドバイスされた場合には注意が必要です。

ちなみにKinstaのカスタムLXDコンテナは、CPUとRAMを自動スケーリングするように構成されています。また、Google Cloudの最高速CPUを搭載したコンピューティング最適化C2仮想マシンを使用して、サイトのPHPワーカーがより効率的に実行できるように配慮されています。この自動スケーリング機能により、WordPressサイトのPHPワーカーは、ピークパフォーマンスで動作するのに十分なCPUリソースを確保できます。

それでは、先ほどの消火栓の例に戻りましょう。

5本のホースで10箇所の火を消す必要がある状況を想像してください。5本のホースすべてを接続した後に、消火栓にはまだ十分な水圧があることに気付きます。

この状況では、消火栓の水圧がボトルネックではないため、さらに数本のホースを接続するという判断は、理にかなっています。

これと同様に、CPUとRAMのオーバーヘッドが十分にあってもサイトのパフォーマンスが低下している場合は、 パフォーマンスを改善するためのオプションとして、PHPワーカーの数を増やすことを検討する必要があります。

サイトにおけるPHPワーカーの使用を最適化する方法

PHPワーカーは、PHPコードを使用してHTMLページを生成するバックグラウンドプロセスであることは、前にご説明した通りです。そして、PHPワーカーの使用量を減らして最適化する最も明白な方法は、サイトへの要求を満たすために必要なCPUおよびPHPリソースの量を減らすことです。

この方法は以下の通りです。

1. WordPressサイトにキャッシュを設定する

PHPワーカーの使用を減らすための最初のステップは、WordPressサイトにキャッシュを設定することです。デフォルトでは、WordPressは動的CMSであり、すべてのページリクエストを要求があった時点で実行します。

ブログ、オンラインマガジン、ポートフォリオなど、多くのサイトでは、PHPを使用してすべてのリクエストに対して動的にページを生成する必要はありません。

ページのキャッシュ

現在読んでいるこの記事は、動的に生成する必要のないページの典型例です。他の多くの記事と同様に、ここにあるコンテンツは静的であるように設計されているため、同一のページを継続的に生成するためにCPUリソースを費やす必要はありません。

そこで、PHPでページを一度生成してから、その後はキャッシュをしてしまうことをお勧めします。ページのキャッシュには、PHPを使用してページを動的に生成するよりも明らかに多くの利点があります。

たとえば、サイトの記事が口コミで広がり、公開後数時間で10万ページビューを記録したとします。ページのキャッシュがないと、PHPワーカーに負荷がかかり、サーバーがクラッシュする可能性があります。

ページキャッシュを使用すると、初回のページビューのみが動的に生成されます。そして、他の99,999回のリクエストは、比較的少ないCPUリソースを使用するページキャッシュから提供されます。

WordPressサイトでページキャッシュを設定するには、2つの方法があります。

  1. Nginxなどのウェブサーバーによるサーバーレベルでのページキャッシュ
  2. WP-RocketなどのWordPressプラグインを用いたプラグインベースのページキャッシュ

最大のパフォーマンスを確保するためには、可能な限りサーバーレベルのページキャッシュを使用することをお勧めします。Kinstaでは、ホスティングしているすべてのサイトでNginxのFastCGIキャッシュモジュールを使用して、超高速のパフォーマンスを実現しています。

あなたのホストでサーバーレベルのページキャッシュオプションが提供されていない場合、次善の策として、 WordPressキャッシュプラグインを使用して、アプリケーションレベルでページキャッシュを実装できます。

オブジェクトキャッシュ

WooCommerceストア、フォーラム、その他ページキャッシュを効率的に使用できない種類のWordPressサイトの場合、MySQLデータベースの前にRedisなどの永続オブジェクトキャッシュを追加すると、パフォーマンスが向上し、PHPワーカーの負荷が軽減できます。

永続オブジェクトキャッシュがないと、結果が前のクエリと同じであっても、MySQLデータベースクエリはリクエストごとに実行されます。

たとえば、ページキャッシュをバイパスするフォーラムサイトは、ページを作成するために、データベースに対して複数の同一のクエリを実行して、投稿データを取得します。

トラフィックが多く、データベースの負荷が大きいサイトの場合でも、PHPワーカーを使用して、多数のリクエストに対して同一のクエリ結果が生成されるため、このようなデータベースのクエリ実行方法は非効率的だと言えます。そこで登場するのがRedisです。

Redisはデータベースクエリの結果をRAMに保存します。これにより、PHPはすでに実行されたクエリの結果をここから取得できるようになります。このオブジェクトキャッシュにより、繰り返しデータベースクエリを行う必要がなくなるため、PHPワーカーはCPUリソースを節約でき、リクエストの処理に費やす時間を短縮できます。

2. PHPコードを最適化する

ページキャッシュの設定に加え、PHPワーカーの使用量を減らす別の戦略に、PHPコードの最適化があります。WordPressでは「PHPコードの最適化」は実際には、様々な事柄を意味し得るため、詳しく見ていきましょう。

WordPressの最も愛され、同時に最も嫌われている(尋ねる人次第)特徴の1つが、プラグインとコードスニペットによる拡張性です。

WordPressサイトに株価ティッカーシンボル表示ウィジェットを追加したければ、そのためのプラグインがあります。同様に、カスタムフォントを追加する場合は、そのためのfunctions.phpコードスニペットが存在します。

追加機能でWordPressコアを拡張することは非常に簡単。そのせいで、サイトのパフォーマンスへの潜在的な影響を考慮せずに、やり過ぎてしまうことが多々あります。

というわけで、PHPコード最適化の最初のステップは、サイト全体にわたる監査を実行して、本当に必要なプラグインとコードスニペットだけを厳選することです。

質の高いプラグインを選ぶ

多くの場合、WordPressサイトのプラグインの数そのものは、プラグインの質ほど重要ではありません。プラグインが過去6か月更新されていない場合は、要件に合う別のプラグインを選択することをお勧めします。

というのも、WordPressは常に改善され続けています。プラグインが何年も更新されていないと、そのプラグインが最新のWordPress開発とセキュリティのベストプラクティスを利用していない可能性が考えられます。

逆に、プラグインが数週間ごとに絶えず更新されている場合、開発者が質を真剣に考えている可能性が高いため、よい選択肢だと言えるでしょう。

必要なときにだけプラグインを使用する

JavaScriptやCSSの追加など、サイトで簡単なタスクを実行する時、必ずしもそのためのプラグインが必要なわけではありません。代わりに、テーマのPHPテンプレートまたは子テーマのstyle.cssファイルに直接コードを追加することができます。

プラグインのインストールを検討する際には、少し時間をかけて、そのプラグインが100%必要かどうかを調べてください。プラグインのインストール以外に方法がない場合もありますが、それはそれで問題ありません。また、不要なプラグインをインストールしないことで、コードの肥大化を回避することもできます。

軽量のテーマを選ぶ

何千ものWordPressサイトを監査してきた経験がありますが、テーマがPHPのパフォーマンス低下の原因となるケースがあります。 汎用型CMSとしてのWordPressの多様性に対応するために、一部の開発者は、さまざまな用途で機能するようにテーマをコーディングしています。

多くの場合、これにより、PHPとデータベースクエリを効率的に使用しない、コードだけが肥大化したテーマが作成されます。

WordPressサイトを構築する際に最も重要なのは、パフォーマンスが高くカスタマイズ可能なテーマを選択することです。例としては、GeneratePress、OceanWP、Astraなどがあります。

3. パフォーマンス重視のWordPressホストを選択する

信じられないかもしれませんが、 適切なWordPressホストを選択するだけで、サイトのパフォーマンスに大きな違いで出ることがあります。PHPワーカーの効率はCPUとRAMに直接関係しているため、最新のハードウェアを備えた最新のサーバーでサイトをホストすると、PHPワーカーの使用を最適化できます。

WordPressサイトでパフォーマンス重視のホストを選択することが重要である理由として、2つの例をご紹介します。

高性能CPU

PHPはCPUリソースを使用してコードを実行します。CPUの性能が高ければ、コードの実行が高速になります。Kinstaでは、Google Cloud最高速のサーバーであるコンピューティング最適化C2仮想マシンを使用しています。

この仮想マシンには、3.8 GHzオールコアターボで動作する最新のIntel Xeonプロセッサが搭載されています。私たちの実施したベンチマークテストでは、C2マシンが従来のN1マシンを2〜4倍上回る性能であることが証明されました。

高速SSDストレージ

ディスクI/O速度も、コード実行とデータベースクエリに直接影響を与え得る要素です。データベースが十分なIOPS(1秒あたりの入出力操作)のないクラウドベースのSSDまたは低速のハードディスクに保存されている場合、PHPワーカーはリクエストの処理により多くの時間を費やすことになります。

Kinstaでは、Google Cloud Platformの高性能SSDストレージを採用し、WordPressサイトが高速ディスクI/Oを利用できるようにしています。

4. パフォーマンス改善のプロに協力を求める(任意)

サイトにおけるパフォーマンスの問題に対処する方法がわからない場合は、資格のあるパフォーマンスのプロに協力を依頼し、問題を診断してもらうことをお勧めします。

プロにお願いして、New RelicやWordPressプラグインQuery Monitorなどの高度なモニタリングツールを使用して、コード内の特定のボトルネックの特定をサポートしてもらいましょう。

個々のPHPプロセスとデータベースクエリを精査することにより、サイトのPHPワーカーに高い負荷をかけている特定のコードブロックやそれに関連する機能を特定することができます。

PHPワーカー最適化についてまとめておきます。以下のヒントが参考になるはずです。

  1. PHPワーカーとともに、CPUとRAMもスケールアップする必要があります。CPU使用率が100%に達している状態でPHPワーカーを追加してもパフォーマンスは向上しません。
  2. パフォーマンス重視のホスティングサービスを利用すると、数々のパフォーマンスの問題を解決できます。
  3. ページキャッシュオブジェクトキャッシュにより、PHPワーカーの負荷を大幅に削減できます。
  4. 質の高いWordPressプラグインとテーマを使用すると、サイトにおける不要なコードの膨張を減らすことができます。
  5. 必要に応じて、パフォーマンスに精通するプロと協力して、複雑な問題を特定、解決しましょう。

PHPワーカーが不十分だとどのようなことになるのか

WordPressサイトの高速かつ信頼性の高いパフォーマンス を実現するために、十分なPHPワーカーがあることを確認することが重要です。PHPワーカーが処理しきれないでいると、処理待ちの仕事がどんどんたまります。

PHPワーカーの制限に達すると、キューから古いリクエストが押し出され、504エラーやリクエスト処理の失敗が発生する可能性があります。

PHPワーカーの不足が原因で発生するもう1つの一般的なエラーが、502 Bad Gatewayです。PHPワーカーのキューでの60秒のタイムアウトによりこのエラーが発生するため、504エラーとは少し異なります。

このようなエラーは、訪問者のユーザーエクスペリエンスを低下させるだけでなく、サイトのSEOにも悪影響を及ぼすことがあります。

502(Bad Gateway)エラー

502(Bad Gateway)エラー

ページの読み込み低下やエラー発生の原因には、さまざまな要因が関係しています。たとえば、キャッシュされていないリクエストがデータベースから大量のデータを取得する必要がある場合、結果としてクエリが完了するまでに20〜30秒かかることがあります。

そんな状況では、PHPワーカーは少なくとも30秒間これにかかりっきりになります。サイトにPHPワーカーが2つしかない場合、このような非常に時間のかかるリクエストが2〜3あるだけで十分にエラーが発生し得ます。

これを解決するには、MySQLデータベースを最適化し、さらに、CPUが使い果たされていない状況ではPHPワーカーの数を増やすとパフォーマンスが向上します。

必要なPHPワーカーの数を見積もる

Kinstaの各ホスティングプランには、一定数のPHPワーカーが含まれています。それぞれに設定されるPHPワーカーの数は、過去数年間をかけて収集したリソース使用状況データに基づいています。一般的に、記事、静的ページ、ポートフォリオなど、主に静的なコンテンツを持つサイトでは、多くのPHPワーカーは必要ありません。

eコマースディスカッションフォーラムなどの動的な機能を備えた大規模なWordPressサイトの場合、4つのPHPワーカーが出発点として妥当であると思われます。ただし、サイトごとに独自のテーマ、プラグイン、データベースクエリ、そしてキャッシュと非キャッシュの比率の違いがあるため、サイトごとに状況は異なります。

場合によっては、高速かつ安定したパフォーマンスのために、普通よりも多くのPHPワーカーが必要になることがあります。Kinstaを利用する上でサイトに必要なPHPワーカーの数がわからない場合は、弊社セールスおよびサポートチームが調査をお手伝い致します。

PHPワーカー限度チャート

MyKinsta分析画面にはPHPワーカー限度チャート(「PHPワーカーのご利用限度」と表示されている項目)があります。ここでは、PHPエンジンが、予め割り当てられた最大ワーカー数に達した回数がエラーログとして確認できます。パフォーマンス最適化の施策がPHPワーカー使用状況に影響を与えているか確認するのに便利です。

上位のキャッシュバイパス

上位のキャッシュバイパス

たとえば、サイトのPHPバージョンを5.6から7.4に切り替えた場合、PHP 7.4は5.6よりはるかに高速であるため、PHPワーカーの限度が低下する可能性があります。

同様に、パフォーマンスの専門家に協力を依頼することで長いデータベースクエリを修正し、より軽量なテーマに切り替えた場合、PHPワーカー限度チャートを使用して、最適化の前後の違いを確認できます。

キャッシュ分析チャート

MyKinstaのキャッシュ分析レポートを使用して、キャッシュヒット、バイパス、ミス、有効期限を確認することもできます。ここから得られるデータは、サイトのPHPワーカーの使用状況を最適化するときに特に便利です。

クエリ文字列とキャッシュバイパス

デフォルトでは、 https://kinstalife.com/?query=123のようなクエリ文字列を含むURLは、ページキャッシュをバイパスします。場合によっては、このクエリ文字列により、PHPとCPUの使用量が大幅に増えることがあります。

たとえば、Facebookからリンクにアクセスすると、URLの末尾に?fbclid=というクエリ文字列が表示されることがよくあります。同様に、メールニュースレターのリンクをクリックすると、UTMトラッキングパラメータが表示される場合があります。

クエリ文字列のついたURL(?querystring=123)

クエリ文字列のついたURL(?querystring=123)

サイトの記事が口コミで広まり、クエリ文字列を伴った状態でアクセスされると、キャッシュ分析レポートで特定のURLを識別できます。

この情報を確認した上で、サポートチームまでお問い合わせ頂ければ、特定のURLを強制的にキャッシュして、PHPワーカーの負荷を軽減することができます。

リソースを多く消費するプラグインを特定する

場合によっては、キャッシュ分析チャートを使用して、リソースを多く消費するプラグインやプロセスを特定すること可能です。

たとえば、上位のキャッシュバイパスURLが特定のプラグインのディレクトリ内にあるファイルを指していることがわかった場合、そのプラグインがPHPワーカーの高い使用率に関与している可能性が高いでしょう。

キャッシュバイパスリストにプラグイン関連のリクエストが多数見られる場合には、デベロッパーと協力して問題に対処するか、使用するリソースが少ないプラグインに切り替えることができます。

まとめ

高速なWordPressサイト維持のためには、バックエンドの効率を最大化する必要があります。ワーカー数、CPU使用率、コード最適化のバランスを取り、PHPワーカーを適切に利用すれば、WordPressは非常にパフォーマンスの高いCMSとなり得ます。

必要なPHPワーカーの数についてご質問がございましたら、また、PHPワーカーの不足が原因でエラーが発生していると思われる場合は、サポートチームまでチケットを使ってお問い合わせください。

次はあなたの番です。WordPressサイトをスムーズに稼働させるためにどのような最適化戦略を使用していますか?コメント欄から教えてください!


この記事が面白いと思った方は、KinstaのWordPressホスティングプラットフォームも大好きでしょう。ウェブサイトをスピードアップし、当社のベテランのWordPressチームからの24時間365日のサポートを是非ご利用ください。Google Cloudを使用したインフラストラクチャは、自動スケーリング、パフォーマンス、およびセキュリティに重点を置いています。Kinstaの魅力をご案内させてください。当社のプランをご確認ください。