WordPressサイトの表示速度を継続監視する方法｜制作会社の保守業務に組み込む手順

「サイトが遅い」はダウンと同じくらいクライアントを怒らせる

WordPressサイトの保守担当者が直面する問題の多くは「落ちている」ではなく「遅くなっている」です。サイトは返答しているが3秒・5秒かかる——ユーザーは待たずに離脱し、制作会社はクライアントから「サイトが重い」という連絡を受けて初めて気づくことになります。

外形監視で「ダウン検知」はできますが、応答時間の劣化は監視設定なしでは見えません。本記事では、WordPressサイトの表示速度劣化に特化した継続監視の方法と、保守業務への組み込み手順を解説します。

死活監視の基本的な組み込みは「WordPress保守サービスに死活監視を組み込む方法」を、応答時間監視の汎用的な設定は「応答時間監視ガイド（レスポンスタイムの閾値と設定）」をあわせて参照してください。

WordPress固有の速度低下要因

汎用的なサーバー負荷とは異なるWordPress固有の速度低下パターンを把握することが、継続監視を効果的にする前提条件です。

1. WP-Cronによるリクエスト時の同期負荷

WordPressは標準で「疑似Cron」を使っています。通常のcronとは異なり、ユーザーがページにアクセスしたタイミングでスケジュール済みの処理（メール送信・投稿予約・プラグインのメンテナンスタスク）を実行します。

トラフィックが少ないサイトでは特定のアクセス時のみ重い処理が走るため、応答時間が不規則にスパイクします。

# WP-Cronが頻繁に実行されているかを確認するNginxログの確認
grep "wp-cron.php" /var/log/nginx/access.log | \
  awk '{print $1, $7}' | tail -20

# 実行時間を計測（サーバーに直接アクセスできる場合）
time curl -s -o /dev/null "https://example.com/wp-cron.php?doing_wp_cron=1"

対策: wp-config.php で DISABLE_WP_CRON を true に設定し、サーバーのcrontabで直接実行することでリクエスト時の負荷を排除できます。

// wp-config.phpに追加（WP-Cronを無効化する）
define('DISABLE_WP_CRON', true);

# サーバーcrontabでWP-Cronを5分ごとに実行する
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron=1 > /dev/null

2. プラグイン追加・更新による応答時間の劣化

WordPressサイトへのプラグイン追加や更新は、直接的な「壊れ」が発生しなくても、応答時間を静かに増加させます。

プラグインA追加前の平均応答時間: 320ms
プラグインA追加後の平均応答時間: 850ms（+530ms）

このような変化は、モニタリングなしでは気づきません。月次の保守作業（WordPressコアアップデート・プラグイン一括更新）後に応答時間の変化を確認する習慣が重要です。

3. 画像最適化設定の劣化

WebP変換・遅延読み込み（Lazy Load）を担当するプラグインが、更新後に設定がリセットされることがあります。次の月次点検まで気づかず、ページ重量が増加し続けるケースがよく見られます。

Miterlの応答時間監視は、このような劣化を「応答時間が閾値を超えた」という形で検知します。

4. DBクエリの蓄積・肥大化

WordPressの投稿リビジョン・スパムコメント・プラグインのログテーブルは放置すると大量に蓄積します。SELECT文の実行時間が増え、ページ生成が遅くなります。

一般的に、500ms以下が快適なTTFBの目安であり、1秒を超えると調査が必要です。

Miterlで応答時間を継続監視する

モニターの作成

HTTP監視を作成するだけで、自動的に応答時間が記録されます。通常の死活監視と同じモニターで応答時間も取得できます。

# WordPress本番サイトの応答時間監視モニターを作成する
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "クライアントA - WordPressサイト（速度監視）",
    "type": "http",
    "url": "https://client-a.co.jp",
    "interval_seconds": 60,
    "alert_contact_ids": [1]
  }'

応答時間データの取得

# モニターの現在の応答時間を取得する
curl -s "https://miterl.com/api/v1/monitors/1" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq '{name, avg_response_time_ms, status}'

出力例：

{
  "name": "クライアントA - WordPressサイト",
  "avg_response_time_ms": 420,
  "status": "up"
}

複数クライアントの応答時間を一括確認する

# 全モニターの応答時間を一覧表示して、遅いサイトを特定する
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq -r '
    .data[]
    | select(.type == "http")
    | "\(.avg_response_time_ms // 0) ms\t\(.name)"
  ' | sort -n | tail -10

このコマンドで応答時間が遅い順に10件を抽出できます。月次保守作業前に実行し、速度劣化が起きているサイトを優先的に確認します。

保守業務フローへの組み込み方

月次作業チェックリスト

月次のWordPress保守作業（コア・プラグイン・テーマの更新）の前後に、応答時間を記録しておくことで「更新で遅くなっていないか」を確認できます。

#!/bin/bash
# wp_maintenance_check.sh
# 月次保守作業前後に実行して応答時間を記録する

API_KEY="YOUR_API_KEY"
MONITOR_ID=1

echo "=== 保守作業 応答時間チェック（$(date)）==="
curl -s "https://miterl.com/api/v1/monitors/${MONITOR_ID}" \
  -H "Authorization: Bearer ${API_KEY}" \
  | jq -r '"現在の応答時間: \(.avg_response_time_ms) ms \n 稼働状態: \(.status)"'

• 更新作業前に応答時間を記録した
• コア・プラグイン・テーマの更新を実施した
• 更新後5〜10分後に応答時間を再確認した
• 更新前後で500ms以上の増加がないことを確認した

アラート設定（閾値の目安）

応答時間が一定値を超えた場合のアラートは、月次の定期確認よりも早く異常を検知するための仕組みです。WordPressサイトの規模・サーバー環境にあわせて閾値を設定します。

月次報告への組み込み

応答時間を月次報告書に含めることで、「速度監視も含めた保守」を提供していることをクライアントに示せます。

【今月の表示速度状況】
- 月間平均応答時間: 420ms（前月: 380ms）
- 最大応答時間（1分間隔での記録）: 1,240ms（プラグイン更新直後）
- 状態: 更新後に一時的な増加あり。翌日に通常値へ回復。調査済み。

月次報告の自動化全体は「制作会社向け｜クライアント月次稼働率レポートを自動化する方法」で解説しています。

WP-Cron・プラグイン更新と応答時間の関係を可視化する

Miterlの応答時間の時系列データと、WordPressの更新履歴・作業ログを照らし合わせることで、速度劣化の原因を特定できます。

典型的なパターン：

12/03 10:00 - プラグイン一括更新実施
12/03 10:05 - 応答時間: 320ms（正常）
12/03 10:15 - 応答時間: 1,840ms（急上昇）
→ 更新されたプラグインのどれかが競合していると判断

このような時系列の変化はダッシュボードで視覚的に確認でき、どの作業が影響したかの切り分けに役立ちます。

SSL証明書と組み合わせた「WordPress保守フルセット」

応答時間監視・死活監視・SSL証明書監視を一つの監視体制として整備することで、WordPressサイトのリスクをほぼ網羅できます。

SSL証明書の一括管理については「WordPress制作会社向けSSL証明書期限を一括管理する方法」を、メール認証の継続監視は「SPF・DMARC・DKIM・MXを常時監視する方法」をご覧ください。

まとめ

WordPressサイトの表示速度劣化は、サイトのダウンと同様にクライアントとユーザー体験を損ないますが、監視なしでは気づけません。

• WP-CronをDisabledにしてサーバーcronへ移行することで、リクエスト時の応答時間スパイクを防げる
• プラグイン更新・追加の前後に応答時間を記録する習慣で、速度劣化の原因を即座に特定できる
• MiterlのHTTP監視は死活確認と同時に応答時間を自動記録するため、追加設定なしで速度監視が実現できる
• 月次報告に応答時間の推移を加えることで、保守の価値をより具体的に示せる

まずは無料プランでHTTPモニターを作成し、応答時間の変化を確認してみてください。設定の詳細はドキュメントをご覧ください。制作会社向けの活用シナリオはユースケース一覧でも紹介しています。よくある質問はFAQにまとめています。