Monitoring Baseline
Establish a baseline before you optimize. It is the reference point that makes improvements provable and regressions obvious.
What to Capture (Minimum)
Record baselines across four layers:
- User experience (field and lab): CWV distribution (p75), lab waterfalls for a few key pages.
- Edge and cache: CDN cache status, origin page cache status, cache bypass rules.
- Origin health: CPU/RAM/disk pressure, PHP worker saturation, DB load.
- Application signals: error rate, slow queries, top slow routes (if you have APM).
tip
Baseline a small set of representative URLs (homepage + a content page + a dynamic page like search/contact, and cart/checkout if applicable). Optimizing only the homepage is how regressions slip into revenue-driving routes.
Baseline Note Template
Copy/paste template
baseline-template.txt
# Performance baseline: example.com
# Date:
# Tester:
# Environment: production | staging
# Stack: web server / PHP / DB / cache / CDN
## URLs tested
- /
- /some-post/
- /?s=test
## Cache state during tests
- CDN: on/off, cache rules:
- Origin page cache: on/off, bypass conditions:
## Field signals (p75)
- LCP:
- INP:
- CLS:
- Notes:
## Lab signals (median of repeated runs)
- Waterfall notes:
- Main bottleneck:
## Origin snapshot
- CPU:
- RAM:
- Disk:
- PHP workers:
- DB:
## Notes / anomalies
-
Collect the Data
Capture a quick origin snapshot
uptime
free -m
df -h /
ps aux --sort=-%cpu | head -10
ps aux --sort=-%mem | head -10
Measure TTFB repeatedly (use the median)
for i in {1..5}; do
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://example.com/
sleep 2
done
Check cache headers (CDN and origin)
curl -sI https://example.com/ | grep -iE 'cf-cache-status|x-litespeed-cache|x-cache|cache-control'
caution
Keep test conditions comparable. If you change caching, location, device profile, or test time window, write it down. Otherwise you cannot trust the comparison.