WordPress Speed Monitoring for Web Agencies

"The Site Is Slow" Is Almost As Bad As "The Site Is Down"

Most WordPress incidents that damage client relationships are not clean outages. The site responds — just slowly. Three seconds, five seconds, eight seconds. Users bounce. Clients call. And without response time monitoring in place, the agency finds out after the fact.

Standard uptime monitoring detects when a site fails to respond. It does not tell you when a site responds too slowly to be usable. Response time degradation is invisible without monitoring configured to track it.

This guide covers WordPress-specific causes of response time degradation and how to integrate continuous response time monitoring into a recurring maintenance service. For the broader framework of adding monitoring to WordPress maintenance plans, see "How to Add Uptime Monitoring to WordPress Maintenance Services." For general response time monitoring configuration, see the response time monitoring guide.

WordPress-Specific Causes of Response Time Degradation

Generic server performance problems aside, WordPress has failure modes that produce response time spikes in patterns different from non-WordPress stacks.

1. WP-Cron Firing on Visitor Requests

WordPress uses a pseudo-cron system by default. Rather than running on a real system schedule, WP-Cron piggybacks on incoming HTTP requests — when a visitor loads a page, WordPress checks whether any scheduled tasks are due and runs them synchronously during that request.

On low-traffic sites, this means specific visitor requests trigger heavy background operations (sending scheduled emails, running plugin maintenance tasks, processing post scheduling), causing irregular response time spikes that look like intermittent slowdowns.

# Check whether WP-Cron is running frequently (Nginx log)
grep "wp-cron.php" /var/log/nginx/access.log | \
  awk '{print $1, $7}' | tail -20

# Measure WP-Cron execution time directly
time curl -s -o /dev/null "https://example.com/wp-cron.php?doing_wp_cron=1"

Fix: Disable WP-Cron in wp-config.php and move it to a real server cron job.

// Add to wp-config.php
define('DISABLE_WP_CRON', true);

# Server crontab: run WP-Cron every 5 minutes instead
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron=1 > /dev/null

2. Plugin Additions and Updates Silently Adding Latency

Plugin installations and updates that do not break anything visibly can still add significant latency. A plugin that introduces an external HTTP call or a slow DB query on every page load may increase average response time from 320ms to 850ms — a change that only monitoring will catch.

Average response time before plugin install: 320ms
Average response time after plugin install: 850ms (+530ms)

This pattern makes it essential to record response time before and after each monthly maintenance run (core updates, plugin updates, theme updates).

3. Image Optimization Settings Resetting After Updates

Plugins that handle WebP conversion and lazy loading can reset their settings after an update, silently restoring unoptimized behavior. Page weight grows back toward pre-optimization levels while the site continues to respond normally in uptime terms. Response time monitoring catches this regression.

4. Growing Database Query Times

WordPress post revisions, spam comment accumulation, and plugin log tables grow without active cleanup. SELECT queries slow as table rows accumulate, and page generation time increases gradually. 500ms TTFB is a comfortable target; anything over 1 second warrants investigation.

Monitoring Response Time with Miterl

Creating the Monitor

An HTTP monitor automatically records response time — no separate configuration needed beyond creating the standard uptime monitor.

# Create an HTTP monitor for a WordPress client site
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Client A — WordPress Site",
    "type": "http",
    "url": "https://client-a.example.com",
    "interval_seconds": 60,
    "alert_contact_ids": [1]
  }'

Retrieving Response Time Data

# Get current response time for a monitor
curl -s "https://miterl.com/api/v1/monitors/1" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq '{name, avg_response_time_ms, status}'

Output:

{
  "name": "Client A — WordPress Site",
  "avg_response_time_ms": 420,
  "status": "up"
}

Finding Slowest Sites Across All Clients

# List all HTTP monitors sorted by response time, slowest first
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 -rn | head -10

Run this before each monthly maintenance cycle to prioritize sites that have degraded since the last check.

Integrating Response Time Checks Into Monthly Maintenance

Pre/Post Update Verification Script

#!/bin/bash
# wp_speed_check.sh — run before and after monthly WordPress updates

API_KEY="YOUR_API_KEY"
MONITOR_ID=1

echo "=== WordPress Speed Check ($(date)) ==="
curl -s "https://miterl.com/api/v1/monitors/${MONITOR_ID}" \
  -H "Authorization: Bearer ${API_KEY}" \
  | jq -r '"Response time: \(.avg_response_time_ms) ms | Status: \(.status)"'

Monthly maintenance checklist additions:

• Record response time before starting updates
• Complete core, plugin, and theme updates
• Re-check response time 5–10 minutes after updates
• Flag any increase over 500ms for investigation before closing the maintenance ticket

Alert Thresholds by Site Type

Including Response Time in Monthly Reports

Adding a response time section to monthly client reports demonstrates that your maintenance service monitors more than just "is it up or down."

[Site Speed]
Monthly average response time: 420ms (prior month: 380ms)
Peak response time recorded: 1,240ms (directly after plugin update batch)
Notes: Temporary spike detected post-update. Resolved to normal within 24 hours. Root cause confirmed: one plugin's background process added extra DB queries; reverted to previous version.

For automating the full monthly report including response time and uptime data, see "Automating Monthly Uptime Reports for Clients."

Correlating Response Time Spikes with Maintenance Events

Miterl's time-series response time data, when compared against your maintenance log, makes root cause identification straightforward.

Typical pattern:

12/03 10:00 — Plugin batch update completed
12/03 10:05 — Response time: 320ms (normal)
12/03 10:15 — Response time: 1,840ms (spike)
→ One of the updated plugins introduced the regression

This kind of correlation narrows the investigation from "something is wrong" to "we know which maintenance action caused this, and we can roll back that specific plugin."

The Full WordPress Maintenance Monitoring Stack

Response time monitoring combines with uptime, SSL, and mail authentication monitoring to give near-complete coverage of WordPress site health.

For SSL certificate management across WordPress client sites, see "Managing SSL Certificate Expiry Across WordPress Client Sites." For mail authentication continuous monitoring, see "How to Monitor SPF, DMARC, DKIM, and MX Records."

Summary

WordPress response time degradation is common, damaging to client relationships, and invisible without monitoring in place.

• Disable WP-Cron and run it from a real server cron to eliminate request-time spikes
• Record response time before and after every plugin update batch to catch regressions immediately
• Miterl HTTP monitors record response time automatically — no additional configuration beyond the standard uptime monitor
• A one-line response time summary in monthly reports gives clients concrete evidence that their site performance is actively managed

Sign up for free to create an HTTP monitor and start tracking response time trends across your client portfolio. Full configuration details are in the documentation. Agency-specific use cases are covered in the use cases section, and common questions about setup are answered in the FAQ.