WordPresssの速度テストは、サイトが落ち着いている状態で実行されることがほとんどです。つまり、バックグラウンドでほとんど処理が行われていない状況で、ページの読み込み速度を測定しています。
実際の本番環境はそう単純ではありません。
運用中のWordPressサイトでは、訪問者へのページ配信と並行して、cronジョブの実行、商品データのインポート、バックアップの作成、注文データの同期、プラグインによる定期タスクの実行、システムアップデートなど、さまざまなバックグラウンド処理が行われています。ユーザーがこれらの処理を目にすることはありませんが、ページの表示が遅くなったり、フォームの反応が鈍くなったり、検索結果の表示に時間がかかったり、決済手続きに通常より時間がかかったりと、その影響を体感することがあります。
そのため、パフォーマンスの問題は予測しにくく感じられることがあります。朝に実施したテストでは良好な結果だったのに、数時間後にはページの表示速度が低下していることも。これは、フロントエンドには何も変化がなくても、その裏ではさまざまな処理が動いているためです。
この記事では、cronジョブやデータのインポート、バックアップなどのバックグラウンド処理がWordPressパフォーマンスに与える影響や、問題の兆候を見つける方法をご紹介します。また、こうした処理が実行されている間も安定したユーザー体験を維持するには、サーバー環境が重要な役割を果たします。これについても触れていきます。
バックグラウンド処理中にWordPressサイトが遅くなる理由
バックグラウンドで実行される処理はユーザーの目には見えませんが、それでもサーバーリソースを消費します。cronジョブ、データのインポート、バックアップ、プラグインによるタスクはいずれも、PHPの実行環境を利用し、データベースへのクエリを発行しながら、メモリ、CPU、ディスクI/O などのリソースを消費します。その間も、訪問者はサイトを利用しています。
パフォーマンスの問題が発生するのは、こうした処理が同時に実行されるためです。ページの表示、フォームの送信、商品検索、アカウントへのログイン、決済などを行う訪問者は、バックグラウンド処理と同じサーバーリソースを必要とすることがあります。
キャッシュは、この負荷をある程度軽減できます。ページがすでにキャッシュされていれば、WordPressを最初から実行しなくても、サーバーはページをすばやく配信できる場合があります。動的なリクエストの場合は、事情が異なります。決済ページ、アカウントダッシュボード、管理画面、会員向けポータル、検索結果、フォーム送信などは、多くの場合、新たにPHPやデータベースの処理を実行する必要があります。そのため、バックグラウンド処理がサーバーリソースを使用していると、こうした機能は真っ先に影響を受け、動作が遅くなりがちです。
そのため、ECサイトや会員制サイト、LMSプラットフォーム、メディアサイト、アクセス数の多いサイトでは、こうした影響を受けやすくなります。これらのサイトでは、注文処理、ユーザー情報の更新、サブスクリプションの管理、コンテンツの公開、在庫の同期、通知の送信、ログインユーザー向けの機能提供など、さまざまな処理が一日を通して継続的に行われています。
多くのパフォーマンステストでは、こうした要因は考慮されません。サイトの負荷が低い状態では優れた結果が得られても、本番環境で通常どおりのアクセスやバックグラウンド処理が増えると、パフォーマンスが低下することがあります。本当のWordPressのパフォーマンスは、フロントエンドのアクセスとバックグラウンド処理を同時に処理しながら、どれだけ安定して動作できるかによって決まります。
パフォーマンスに影響を与える主なバックグラウンド処理
WordPressのバックグラウンド処理は、さまざまな場所で実行されています。WordPressコアによるものもあれば、プラグインやテーマ、EC機能、マーケティングツールとの連携、サーバー環境によって実行されるものもあります。
これらの処理の多くは、それ自体は正常かつ必要なものです。問題になるのは、実行頻度が高すぎたり、処理時間が長すぎたり、訪問者のアクセスと重なって実行されたりする場合です。
代表的なバックグラウンド処理には、以下のようなものが挙げられます。
- WP-Cronイベント：WordPressやプラグインが、コンテンツの公開、不要データの削除、更新確認、通知送信などの定期処理
- 商品やコンテンツのインポート：投稿、商品、画像、カテゴリー、タグ、カスタムフィールド、メタデータの更新（大規模なインポートの場合）
- データベースの更新：プラグインの更新や定期メンテナンスに伴う、データベーステーブルの作成・変更・クリーンアップ
- プラグインやテーマの更新：ファイルの変更、データベースのマイグレーション、キャッシュの削除、更新後の確認処理など
- サイト全体またはデータベースのバックアップ：ファイルのスキャン、データベースのエクスポート、アーカイブの圧縮、ストレージへの保存など
- WooCommerceの注文処理：メール送信、在庫更新、支払いステータスの変更、税額計算、配送処理、CRMとの連携など
- サブスクリプションの更新：定期決済、アクセス権の更新、支払い失敗の通知、アカウント情報の更新など（会員制サイトやサブスクリプションサイト）
- 在庫の同期：倉庫、POSシステム、マーケットプレイス、仕入先などと商品在庫を同期（ECサイト）
- CRMまたはメールマーケティングとの同期：フォーム送信、購入、ユーザー情報の更新、配信リストの変更などをきっかけにした、外部サービスとのデータ同期
- 検索インデックスの再構築：検索・絞り込みプラグインによるインデックスの再構築、商品、投稿、ドキュメント、各種コンテンツの検索
- 画像処理：画像のアップロードやインポート時のサムネイル生成、圧縮、画像形式の変換、メタデータの更新など
- スケジュールされた公開：投稿、ランディングページ、新商品の公開、キャンペーンコンテンツなどの日時指定公開
- プラグインのクリーンアップ処理：期限切れのtransient、古いセッション、ログ、リビジョン、放棄されたカート、一時ファイルなどの削除
特に注意したいのが、インポート処理と同期処理です。一見すると目立たないバックグラウンド処理ですが、実際には大量の作業を実行することがあります。たとえば商品のインポートでは、何千件ものデータベースへの書き込みに加え、画像のダウンロード、サムネイルの生成、タクソノミーの更新、メタデータの変更、キャッシュの削除などが行われる場合があります。また、同期処理も小規模に見えて、数分ごとに実行される設定になっていると、一日中データベースに負荷をかけ続ける可能性があります。
パフォーマンスへの影響は、処理の実行方法によって異なります。アクセスが少ない時間帯に実行される小規模なバッチ処理であれば、ほとんど影響はありません。一方で、アクセスが集中する時間帯に大規模なインポートを実行すると、決済をはじめとする動的なページの応答速度が低下することがあります。バックグラウンド処理がどれほどパフォーマンスに影響するかは、実行するタイミング、一度に処理されるデータ量、プラグインの品質、データベースの健全性、そしてサーバー環境の性能によって左右されます。
WP-Cronがパフォーマンスの急な低下を引き起こす理由
WP-Cronは、投稿の予約公開、更新確認、通知の送信、一時データの削除、プラグインのワークフロー実行など、WordPressの定期タスクを実行するための仕組みです。
ただし、WP-Cronはデフォルトでは通常のサーバーcronのようには動作しません。固定されたサーバースケジュールに従って実行されるのではなく、誰かがサイトにアクセスしたときに、保留中のタスクがあるかどうかを確認します。つまり、通常のページ読み込みがバックグラウンド処理のきっかけになることがあります。
アクセス数の多いサイトでは、これによりトラフィックが多い時間帯にパフォーマンスが急に低下することがあります。訪問者がページを読み込んだり、フォームを送信したり、商品を閲覧したり、決済手続きを行ったりしている最中に、WordPressが同時に定期タスクを処理すると、応答が遅くなる可能性があります。特に動的なリクエストでは、ユーザー対応に必要なタイミングでPHPやデータベースの追加処理が発生するため、影響を受けやすくなります。
一方で、アクセス数の少ないサイトでは逆の問題が起こることも。訪問者が少ないと、WP-Cronが予定どおりに実行されない場合があります。その結果、タスクがたまり、次に誰かがサイトを読み込んだときにまとめて処理されます。WordPressが遅れていたタスクをまとめて処理することで、その訪問者に対してサイトが遅くなる可能性があります。
通常のサーバーcronを使用すると、WordPressの定期タスクをより予測しやすいスケジュールで実行できます。訪問者のアクセスをきっかけにタスクが実行されるのを待つのではなく、サーバーが一定の間隔で処理を実行します。これにより、すべてのバックグラウンド処理が軽くなるわけではありませんが、サイト利用中の予期しないタイミングで定期タスクが実行される可能性を減らすことができます。
バックアップがWordPressのパフォーマンスに与える影響
バックアップはサイトを保護するために欠かせません。アップデートやデータのインポート、デプロイ、セキュリティ上の問題などでトラブルが発生しても、最新のバックアップがあれば、迅速に復旧できます。
しかし、バックアップの実行にもサーバーリソースが必要です。その量は、バックアップの実行方法、サイトの規模、実行頻度、そして同じ時間帯にほかの処理が行われているかどうかによって異なります。
プラグインによるバックアップは、WordPress上で直接実行されることが多いため、特に負荷が高くなる傾向にあります。バックアッププラグインは、ファイルのスキャン、データベースのエクスポート、アーカイブの圧縮、一時ファイルの作成、バックアップデータのリモートストレージへの転送などを行います。その間も訪問者はサイトを利用しているため、PHPの実行環境、データベース接続、CPU、メモリ、ディスクI/Oなどのリソースが消費されます。
サイトの規模が大きいほど、その影響も大きくなります。長年にわたる注文データを抱えるWooCommerceストアや、数千件の記事を公開しているメディアサイト、多数の会員を抱える会員制サイトでは、処理すべきファイルやデータベーステーブル、ログ、セッション、メタデータが増えます。また、画像を多く扱うサイトでは、画像ライブラリのスキャンやアーカイブにも時間がかかるため、さらに負荷が高まります。
バックアップを実行するタイミングも重要です。アクセスが少ない時間帯であれば、訪問者への影響はほとんどありません。しかし、セール期間中や商品インポートの実行中、決済が集中する時間帯、管理画面で多くの作業が行われているタイミングでは、バックアップ処理が通常のアクセスとサーバーリソースを取り合い、動的なページの応答速度を低下させることがあります。
バックアップ自体が問題なのではなく、採用するバックアップ方法によってパフォーマンスへの影響が決まります。サーバー環境でバックアップを実行できる仕組みを利用すれば、WordPress内で負荷の大きいバックアッププラグインを動かす必要が減り、サイトを安全に保護しながら、フロントエンドへの影響も抑えやすくなります。
バックグラウンド処理によるパフォーマンスの問題が予測しにくい理由
バックグラウンド処理によるパフォーマンスの問題は、原因を特定しにくいのが特徴です。サイト運営者が表示速度の低下に気付いたときには、その原因となるcronジョブやインポート、バックアップ、同期処理などが、すでにバックグラウンドで動いていることが少なくありません。
そのため、こうした問題は一貫性がないように見えます。フロントエンドには何も変化がないにもかかわらず、バックグラウンドで実行される処理だけが変化しているためです。
キャッシュされたページは、こうした状況でも問題なく表示されることがよくあります。一方で、影響が現れやすいのは、アカウントページや管理画面での操作、フォーム送信、検索機能など、動的な処理が必要なページです。これらのリクエストは、PHPやデータベースのリソースをリアルタイムで利用するため、静的ページやキャッシュ済みのページよりも影響を受けやすくなります。
よく見られる兆候としては、次のようなものがあります。
- トラフィックの増加がないにもかかわらず、サーバーの応答時間が急に長くなる
- チェックアウト、ログイン、検索、管理画面での操作が遅くなる
- インポート、更新、バックアップ、プラグインの処理中にタイムアウトが発生する
- 「サイトの動作が安定しない」という報告がユーザーから寄せられる
- 問題が発生していない時間帯に実施した速度テストでは正常な結果が出る
- 毎日または毎週、同じような時間帯にパフォーマンスが低下する
多くの場合、問題があるのはページそのものではなく、サイトがバックグラウンド処理とサーバーリソースを取り合っていることにあります。
バックグラウンド処理によるパフォーマンスの問題を特定する方法
まず確認したいのは、「いつ」問題が発生しているかです。特定の時間帯だけサイトが遅くなる場合や、特定の操作中、あるいは定期処理の実行直後にパフォーマンスが低下する場合は、そのタイミングが原因を特定する手がかりになります。
定期タスクを確認する
cronのスケジュールを確認し、どのタスクがどれくらいの頻度で実行されているのか、また複数のタスクが同じタイミングで実行されていないかを確認しましょう。1つのタスクだけであれば大きな負荷にならなくても、複数のタスクが同時に実行されると、PHPやデータベースへの負荷が急激に高まることがあります。
バックアップ、インポート、同期を確認する
バックアップの実行時刻や、インポート・同期処理のログを確認しましょう。サイト全体のバックアップやデータベースのエクスポート、商品フィードの更新、在庫同期、CRMとの同期、メールマーケティングツールとの連携などとパフォーマンス低下のタイミングが一致している場合は、バックグラウンド処理が通常のアクセスとサーバーリソースを取り合っている可能性があります。
WooCommerceサイトでは、スケジュール済みアクションも確認しましょう。注文処理、サブスクリプションの更新、決済の再試行、メール送信、Webhookの実行、在庫更新などもバックグラウンド処理として実行されます。保留中や失敗したアクションが大量に残っている場合は、処理が正常に完了していない可能性があります。
パフォーマンス低下とアクセス状況を比較する
パフォーマンスが低下した時間帯とアクセス状況を比較してみましょう。アクセス数の増加と同時に応答時間が悪化している場合は、サーバー性能の強化やキャッシュの改善が必要かもしれません。一方、アクセス数が通常どおりにもかかわらず応答時間だけが悪化している場合は、バックグラウンド処理が原因である可能性が高くなります。
サーバーとアプリケーションの情報を確認する
PHPスレッドの使用状況を確認し、動的なリクエストが待機状態になっていないかを調べます。また、データベースの低速クエリ、エラーログ、タイムアウト、メモリ不足、外部サービスへのリクエスト失敗、プラグインから繰り返し出力される警告なども確認しましょう。
APM（アプリケーションパフォーマンス監視）ツールを利用すると、これらの情報を関連付けて分析できます。問題が発生した時間帯に、どのPHPトランザクションやデータベースクエリ、外部HTTPリクエスト、長時間実行されているプロセスがパフォーマンスに影響していたのかを把握できます。原因を推測するのではなく、サイトがどこで時間やリソースを消費していたのかを可視化できるようになります。
バックグラウンド処理の多いWordPressサイトに適したサーバーの条件
サーバー環境は、WordPressがフロントエンドのアクセスとバックグラウンド処理を同時にどれだけ安定して処理できるかに大きく影響します。サイト自体の設計が優れていても、本番環境の負荷に対応できるだけの余裕がサーバーになければ、パフォーマンスは低下してしまいます。
cronジョブやインポート、バックアップ、同期処理、ECサイトの運用など、バックグラウンド処理が多いサイトでは、以下のような機能を備えたサーバーを選ぶことが重要です。
- リソースの分離：バックグラウンド処理が過密な共有環境の影響を受けたり、他のサイトの負荷に左右されたりしないこと。
- 十分なPHP実行環境：バックグラウンド処理がPHPの実行環境を使い切ると、動的なリクエストが待機状態となり、訪問者の応答時間が長くなる。
- サーバーcronへの対応：訪問者のアクセスをきっかけにするのではなく、決まったスケジュールで定期タスクを実行できること。
- 強力なキャッシュ機能：ページキャッシュやCDN、エッジキャッシュによって、PHPやデータベースを必要とするリクエストを減らせること。
- データベース性能：インポート、注文処理、検索インデックスの更新、サブスクリプションの更新、クリーンアップ処理などを安定して処理できること。
- 信頼性の高いバックアップ：WordPress内で負荷の大きいバックアップ処理を実行しなくても、サイトを保護できる仕組みがあること。
- パフォーマンスの可視化：アクセス解析、PHP使用状況、キャッシュの利用状況、レスポンスコード、ログ、APMツールなどを利用して、パフォーマンス低下時の状況を把握できること。
- WordPressに詳しいスタッフによるサポート：cronの動作、プラグイン、PHPの制限、データベースクエリ、キャッシュ設定、外部API連携、WooCommerceの設定済みアクションなど、WordPress特有の問題に対応できること。
こうした機能は、注文処理やログイン、データのインポート、サブスクリプションの更新、外部サービスとの同期、コンテンツの公開、管理画面での作業などに依存するサイトほど重要になります。バックグラウンド処理が増えるほど、フロントエンドとバックエンドの処理を同時に安定して支えられるサーバーが求められます。
Kinstaでバックグラウンド処理中もWordPressの応答性を維持
Kinstaは、静かな環境での速度テストだけでなく、実際の本番環境での運用を想定して設計されたWordPress専用のサーバーを提供しています。
各WordPressサイトは、Linux、NGINX、PHP、MySQLなど必要なコンポーネントを含む専用のソフトウェアコンテナ内で実行されます。この完全に独立した環境により、定期タスクやインポート、バックアップ、同期処理などが通常のアクセスと同時に実行されても、リソース使用量を安定して管理しやすくなります。
PHPの実行環境も柔軟に管理できます。決済、ログイン、検索、管理画面での操作、インポート、会員向け機能などの動的な処理は、いずれもPHPに依存しています。MyKinstaでは、サイトごとにPHPのパフォーマンス設定を確認・調整できるため、サイトの負荷に合わせて実行環境を最適化可能です。
キャッシュもサーバーへの負荷を軽減するのに役立ちます。Kinstaでは、ページキャッシュにNGINX FastCGI Cacheを採用し、キャッシュ可能なページはPHPを実行することなく配信します。これにより、PHPの処理能力を決済やログインなど、PHPを必要とする動的なリクエストにより多く割り当てられます。
定期タスクについては、Kinstaはサーバーレベルのcronジョブに対応しています。これにより、サイトへのアクセスをきっかけに実行されるWP-Cronだけに頼るのではなく、より予測しやすいスケジュールでバックグラウンド処理を実行できます。
Kinstaは、パフォーマンスの問題を把握しやすくするための機能も提供しています。MyKinstaの分析機能では、リソース使用状況やパフォーマンスデータ、レスポンスコード、キャッシュの利用状況、CDNの利用状況、トラフィックの推移などを確認できます。さらに、Kinsta APMを利用すると、PHPプロセスやMySQLクエリ、外部HTTPリクエスト、処理に時間のかかっているトランザクションなどを詳しく分析できるため、バックグラウンド処理に起因するパフォーマンス低下の原因を特定しやすくなります。
バックアップについては、毎日の自動バックアップに加え、システムによって自動生成されるバックアップも標準提供しています。MyKinstaからいつでも復元できるため、日常的な保護のために、WordPress内で負荷の大きいバックアッププラグインを常時実行する必要を減らすことができます。
これらの機能により、バックグラウンド処理が実行されている間も、WordPressは快適な応答性を維持しやすくなります。cronジョブやインポート、バックアップといった処理は引き続き必要になりますが、Kinstaでは、それらを管理するためのより高い柔軟性と可視性、そして実運用に適した環境を手にすることができます。
バックグラウンド処理中もWordPressを快適に動作
WordPressサイトは、何も処理していないときだけでなく、本番環境でさまざまな処理が実行されている間も快適に動作する必要があります。
KinstaのWordPress専用マネージドクラウドサーバーは、インフラ、キャッシュ機能、PHPのパフォーマンス管理、バックアップ、cron対応、パフォーマンスの可視化機能を備えており、アクセスの多いサイトでも安定した運用を支援します。
