Every WordPress site owner has said some version of “the site feels slow” without being able to point at why. Query Monitor fixes that. It is a free plugin that opens up the request lifecycle, every database query, every hook, every external HTTP call, and shows you exactly where the time and memory went. This guide walks through installing it, reading the panels that actually matter, and turning the red numbers into a short list of fixes.
Installing Query Monitor
If you have shell access, wp-cli is the fastest path:
wp plugin install query-monitor --activateWithout wp-cli, install it from the Plugins screen like any other plugin and activate it. Once active, a new admin bar menu appears showing page generation time and peak memory. Click it to open the full panel set.
Query Monitor is safe to run on a live site, but its output is only visible to logged-in users with the right capability by default. If you want a second set of eyes (a developer, for example) to see it without a full admin account, you can filter the capability required, but for most site owners the default behavior of “only admins see it” is exactly right. Deactivate it, or restrict it, once you are done profiling. It adds overhead of its own and should not run at full verbosity on every page load for anonymous visitors.
Start with the Overview panel
The Overview panel gives you the headline numbers: total page generation time, peak memory usage, number of database queries, and a breakdown of time spent in PHP versus the database. This is your triage screen. If query time is a large share of total time, go to the Queries panel first. If most of the time is unaccounted for in PHP, hooks and plugin timing are more likely the culprit. If memory is close to your PHP memory limit, that is worth flagging even if the page loaded fine, because it means you are one plugin update away from a fatal error.
Reading the Queries panel
This is where most fixable problems live. Query Monitor lists every database query for the request, how long each took, and which plugin or theme function called it. Three patterns to look for:
- Duplicate queries. Query Monitor groups identical queries and shows a count. Seeing the same query run 40 times on one page load almost always means a plugin is querying inside a loop instead of once up front. This is one of the most common causes of high query counts on WordPress sites.
- Slow individual queries. Anything that stands out in milliseconds compared to the rest is worth investigating. Often it traces back to a missing index, a meta query on a large postmeta table, or a plugin doing a broad
LIKEsearch. - Queries by component. Query Monitor attributes queries to the plugin, theme, or WordPress core that triggered them. If one plugin is responsible for a third of your total query count, that plugin is your first suspect regardless of what it claims to do.
Hooks and actions
The Hooks & Actions panel shows every action and filter that fired during the request, along with the callbacks attached to each. This is less about raw speed and more about understanding what is running on every single page load, including pages where it clearly is not needed. A common finding is a plugin that enqueues its scripts and styles site-wide instead of only on the pages where it is actually used. That does not always show up as a slow query, but it adds HTTP requests and parsing time on every page, which drags down Core Web Vitals metrics like LCP and INP even when the server itself is fast.
HTTP API calls
The HTTP API Calls panel is worth checking on any site that feels slow specifically on the backend or on certain page loads. This panel shows outbound requests WordPress made during the page load, license checks, API calls to third-party services, remote font or asset fetches. These calls happen synchronously by default, which means your visitor’s page load is waiting on a remote server you do not control. A single slow external API call can add a full second or more to time to first byte. If you see one here consistently, that plugin or integration is a strong candidate for removal, replacement, or a support ticket to its developer asking for the call to be moved off the request path.
Object cache and full page cache
Query Monitor also reports whether an object cache is active and gives hit and miss ratios. If you are running Redis or Memcached as a persistent object cache backend and the hit ratio is low, that is a sign something is bypassing the cache, or that the cache is being flushed too aggressively by a plugin. On a LiteSpeed server with LiteSpeed Cache active for full-page caching, Query Monitor will still show you the underlying PHP execution for uncached requests, which is useful for understanding what a cache miss actually costs on your setup. If you are behind Cloudflare, remember that edge caching happens before your origin server ever sees the request, so a page showing fast even with a slow Query Monitor trace may simply mean Cloudflare served it from cache rather than your server generating it fresh.
Turning red numbers into a fix list
Once you have looked through Overview, Queries, Hooks, and HTTP API Calls, write down three things: the plugin responsible for the most duplicate queries, the plugin loading assets on pages where they are not needed, and any external API call showing up on every request. Those three items are almost always where the real wins are. Fixing them usually means updating the plugin to a version with a fix, changing a setting to limit where it loads, or replacing it with a lighter alternative. If a plugin update does not help, that is useful information for a support request, since you can point to the exact query or hook rather than describing a vague feeling of slowness.
When to look beyond Query Monitor
Query Monitor profiles a single request on your server. It will not tell you about DNS latency, TLS handshake time, or how much of your load is being absorbed by a CDN before it reaches your origin. For that layer, browser developer tools and a real-world Core Web Vitals report are the better instruments. A well-tuned host running PHP 8.3 with OPcache, a Redis object cache, and LiteSpeed’s full-page caching handles a lot of the server-side half of this equation automatically. That is exactly how we configure things at ServerBorn, so the fixes you find in Query Monitor stack on top of an already fast baseline rather than fighting it.
Takeaway
Query Monitor will not make your site faster by itself, but it removes the guesswork. Install it, look at Overview to know where to focus, check Queries for duplicates and slow calls, check Hooks for assets loading where they should not, and check HTTP API Calls for anything reaching outside your server. Three or four fixes from that list will usually do more for your site’s real-world speed than any general-purpose optimization plugin.