WP-CLI Profiling Commands
WP-CLI Profiling Commands
Profiling commands measure exactly how long WordPress spends in each phase of a request — bootstrap, main query, template — and how much of that time is core versus your own hooked code. The fastest way to turn “the site feels slow” into one concrete number, before you touch a single line of code.
Commands
wp package install wp-cli/profile-command
Installs the profiling command — not bundled with WP-CLI core.
wp package install wp-cli/profile-commandOne-time setup per environment. Every command below is unavailable until this package is installed. Verify with wp profile --help.
wp profile stage
Profiles all three request stages side by side: bootstrap, main_query, template.
wp profile stage --url=example.comThe first command to run on any “site feels slow” ticket. On a multisite network, always pass --url — without it you profile the network’s main site, not the one anyone actually complained about.
wp profile stage <stage>
Isolates a single stage and shows its hook_time — how much of that stage ran in hooked plugin/theme code versus WordPress core.
wp profile stage template --url=example.comA high hook_time relative to a stage’s total time means the cost is in what’s hooked onto that stage, not in WordPress core or the theme’s own template files.
wp profile hook
Breaks a single hook down by registered callback.
wp profile hook template_redirect --url=example.comThe step after wp profile stage flags a stage as slow — this names the exact plugin function or callback responsible, instead of guessing which of ten active plugins is at fault.
wp profile eval
Benchmarks a raw PHP snippet, no full request required.
wp profile eval "sleep(1);"Useful for isolating whether one specific function call is the cost, before deciding it’s worth wiring into a full page request.
wp profile eval-file
Same as wp profile eval, reading the snippet from a file.
wp profile eval-file bench.phpEasier than eval for anything longer than one line — keep a small folder of benchmark snippets per project instead of retyping them in the terminal.
Common Workflows
Triage a “site is slow” ticket
wp profile stage --url=example.com
wp profile stage template --url=example.com
wp profile hook template_redirect --url=example.comFind the slow stage, isolate it to check hook_time, then drill into the specific hook. Three commands, no guessing, no plugin installed in production.
Confirm a fix actually worked
wp profile stage --url=example.comRun once before the fix, once after. “It feels faster” is not a number — a repeated wp profile stage is.
Benchmark a snippet before shipping it
wp profile eval-file candidate-function.phpTest a function’s cost in isolation before it goes into a hook that runs on every request.
Notes on Reading wp profile Output
time — how long the stage actually took, in seconds. The number everyone asks for first, and the least useful one on its own.
query_num — how many SQL queries ran during that stage. High and rising across releases is worth tracking even before it becomes a visible slowdown.
cache_ratio — the share of queries served from the object cache instead of the database. Low cache_ratio on a site that should have Redis or Memcached usually means the persistent cache isn’t actually connected — check with wp cache type.
hook_time — only shown when profiling a single stage. How much of that stage’s time ran inside hooked plugin/theme callbacks, versus WordPress core itself. This is the column that tells you where to actually look.
Related Command Groups
- Core — bootstrap loads every active plugin and the theme, same code path
wp corecommands touch - Plugins — a heavy plugin on
initis the most common cause of a slow bootstrap - Database — main_query and cache_ratio both depend on database and index health
- Cache — a low cache_ratio often just means the persistent object cache isn’t connected