最初に発生範囲を測る
全ページか一部か、初回だけか、管理画面も遅いか、未ログインとログインで違うかを確認します。発生時刻、応答時間、直前の変更、アクセス増加を記録します。利用者側の回線とサーバーの処理時間も区別します。
遅延の層を切り分ける
| 手掛かり | 調べる対象 |
|---|---|
| HTML応答開始が遅い | PHP、DB、外部API、同時実行 |
| 画像やJSだけ遅い | ファイル容量、配信、ネットワーク |
| ログイン時だけ遅い | キャッシュ除外、管理処理 |
| 一定周期で遅い | バックアップ、WP-Cron、バッチ |
サーバー側の状況を確認する
CPUだけでなくメモリ、I/O、容量、PHPプロセス、DB接続や遅いクエリを時刻で合わせます。外部APIのタイムアウトやキャッシュ失効が原因の場合もあります。詳細な調査ツールは負荷と情報露出を考え、検証環境または限定時間で使います。
改善を検証する
原因に合う変更を一つずつ行い、同じ条件で再計測します。キャッシュの追加で個別ユーザーの情報を誤配信しないよう除外条件を確認します。一時的に速くなったことより、再現条件と改善理由を説明できる状態を目指します。
昨日との差分から調査する
更新履歴、アクセス量、バッチ、データ件数、外部サービス、キャッシュ設定を時系列で並べます。昨日と同じアクセス量でも、検索対象データが増えたり、外部APIが遅くなったりすれば処理は遅くなります。平均値だけでなく、遅いURLと操作、時間帯を特定します。
キャッシュで隠れている問題
未ログインだけ速い場合は、キャッシュを通らない編集・検索・会員機能で遅さが残る可能性があります。HTMLの応答開始、DB、外部待ち、静的資産を分けて計測し、改善前後を同じ条件で比較します。
よくある質問
速度計測サービスの点数が下がったらサーバー障害ですか？
端末条件、ネットワーク、画像、実行するJSなどにも影響されます。点数と実測の応答、サーバー状況を合わせて判断します。
DBを整理すれば速くなりますか？
対象処理がDBに律速されているか確認が先です。根拠なくデータやテーブルを削除せず、バックアップと検証を行います。