Continuous Profiling
Monitoring tells you that TTFB is worse. Profiling tells you why.
Profiling vs Monitoring
| Monitoring answers | Profiling answers |
|---|---|
| "what is slow?" | "where is the time spent?" |
| "when did it regress?" | "which function/plugin/regression caused it?" |
Prefer Sampling Profilers
For production-like insight, use sampling. Avoid heavy tracing (like Xdebug) on production.
Common options:
- Tideways (continuous, hosted UI)
- Blackfire (on-demand profiling)
- SPX (self-hosted, sampling; secure it carefully)
Production Safety Rules
- Secure access (IP allowlist and a secret key).
- Keep sampling conservative and time-bounded.
- Profile uncached and important routes (login, checkout, search), not only cached pages.
Reading a Flame Graph (Fast)
- Wide boxes: where time accumulates.
- Repeated call stacks: loops or repeated template work.
- Surprising namespaces: often a plugin hooking globally.
Common hotspots in WordPress:
$wpdbcalls: query volume or slow queries.wp_remote_get()/ external calls: blocking network I/O.do_action()/apply_filters(): plugin hook overhead.
A Simple Workflow
- Baseline a profile for a known-slow route.
- Make one change.
- Re-profile the same route.
- Keep the before/after artifacts with the change log.
Checklist
- Profiling tool selected.
- Access is restricted (IP allowlist + secret).
- Baseline profile captured for key routes.
- Before/after profiles are saved per change.