WordPress Query Monitor: Find What's Really Slowing Your Site
WordPress Query Monitor is a free developer plugin that shows you exactly what's slow on a page: heavy database queries, high PHP time, expensive hooks, and blocking HTTP API calls. It diagnoses the problem so you fix the right plugin or query instead of guessing. It's a diagnosis tool, not a cache or speed plugin.
WordPress Query Monitor is a free developer plugin that shows you exactly what's slow on a page: heavy database queries, high PHP time, expensive hooks, and blocking HTTP API calls. It diagnoses the problem so you fix the right plugin or query instead of guessing. It's a diagnosis tool, not a cache or speed plugin. If I were checking this on a real site, I'd start with the page that earns traffic or money, confirm whether the issue is backend, frontend, content, or layout related, then apply one fix at a time.
What is WordPress Query Monitor?
WordPress Query Monitor is a free developer plugin that records every database query, PHP error, hook, script, style, and HTTP API call that runs while a page loads, then shows it all in a panel in your admin toolbar. It's the closest thing WordPress has to a browser DevTools panel for the server side. I install it on almost every slow site I touch because it answers one question fast: what's actually eating the time on this page?
Here's the part people miss. Query Monitor doesn't make anything faster. It's a diagnosis tool, not a cache plugin. It tells you that one plugin fired 340 queries, or that an external API call hung for 1.8 seconds, so you can go fix that exact thing. If you want the why behind slow load times before you even open it, my guide on why WordPress is slow sets the foundation. Query Monitor is how you confirm the cause on your own site instead of guessing.
Why should you use Query Monitor instead of guessing?
You should use Query Monitor because guessing wastes hours and usually fixes the wrong thing. I've watched site owners buy a faster host, add three cache plugins, and compress every image, while the real problem was one plugin running an uncached external API call on every admin page. Query Monitor would've shown that in about ten seconds.
The symptoms it's built for are the ones generic speed tools can't explain. A slow wp-admin, a dashboard that lags, a cart or checkout that crawls, a high TTFB that won't budge no matter how much caching you add. Tools like PageSpeed Insights tell you the page is slow and roughly where, but they can't see your database or which plugin owns a query. Query Monitor can. When your WordPress TTFB sits above 0.8 seconds on a cached page, this is the plugin that finds out why.
How do you install and read Query Monitor?
Install it from Plugins, Add New, search "Query Monitor," then activate it. There's no setup screen and no settings you have to configure to start. A new item appears in your admin toolbar showing page generation time, peak memory, and the number of database queries, something like "0.42s | 12MB | 87Q." That toolbar summary alone tells you a lot before you click anything.
Click that toolbar item and a panel opens with a menu down the left: Overview, Queries, Queries by Component, Hooks & Actions, HTTP API Calls, Scripts, Styles, and more. Read it top down. Overview gives you the totals, Queries shows individual SQL with timing, and Queries by Component breaks the load down by plugin and theme. One important habit: turn off your cache plugin while you diagnose, because a cached page serves static HTML and Query Monitor will show you almost nothing. You want to watch the page build from scratch.
How do you find slow database queries?
Open the Queries panel and click the Time column header to sort slowest first. Query Monitor flags anything that crosses its slow threshold in red. That threshold defaults to 0.05 seconds (50 milliseconds), set by the QM_DB_EXPENSIVE constant, and you can lower it in wp-config.php if you want to catch borderline queries on a fast server. Any single query over about 0.1 seconds on a normal page deserves a look. One that's pushing 0.5 seconds or more is usually your whole problem.
Click the blue plus next to a query's caller to expand the full call stack with file names and line numbers, so you can see exactly which function fired it. Then check the Duplicate Queries tab. This is where the real waste hides. I regularly find the same query run 40, 80, or 200 times on one page because a plugin loops over posts without caching. Forty fast queries can cost more than one slow one. A clean page usually sits in the few-dozen to low-hundreds range; if you're seeing 600 queries, something's looping that shouldn't. For deeper cleanup once you've found the culprit, my WordPress database optimization guide covers indexes, autoloaded options, and table bloat.
How do you find which plugin is the culprit?
Open Queries by Component. This is the single most useful panel in the plugin, and it's the one I go to first on a slow-admin complaint. It aggregates every query by who ran it: each plugin, your theme, and WordPress core, with the count and total time next to each. The plugin sitting at the top with 60% of your query time and 300 queries is your suspect, full stop.
Don't blame the database before you check this panel. A slow site is almost never "the database" in the abstract; it's a specific plugin running bad queries against the database. I once traced a 3-second admin to a related-posts plugin that queried every post's meta on page load. The fix wasn't a faster server, it was swapping that plugin. Once you've named the owner, you decide: configure it better, replace it, or unload it where it isn't needed. A tool like Perfmatters helps you disable plugins per page once you know which one's heavy.
How do you spot high PHP time and slow hooks?
Look at the Overview panel first. It splits your page generation time, and if database time is small but total time is high, your bottleneck is PHP, not SQL. That points you at heavy processing in plugin code or theme functions rather than queries. A lot of people stare at the Queries panel forever when the queries are fine and the PHP is the problem.
Then open Hooks & Actions. It lists every hook firing on the page with the callbacks attached to each, in execution order. Watch init, wp_loaded, template_redirect, and admin_init, because that's where plugins love to hang expensive work. If one hook has fifteen callbacks from the same plugin, that plugin's doing too much on every request. This is also how you catch a plugin that runs on the front end when it only needs to run in admin. Pairing this with the Scripts and Styles panels, which list every enqueued asset and its dependencies, shows you the full weight a plugin adds, and feeds straight into cutting unused JavaScript.
How do you catch blocking HTTP API calls?
Open the HTTP API Calls panel. This is the hidden killer almost nobody checks, and it's information that generic speed scores will never show you. It lists every server-side HTTP request your site made while building the page: license checks, font fetches, social feeds, analytics pings, third-party APIs, each with its URL, response time, and status code. A blocking external call freezes PHP until that remote server answers, so one slow API can add seconds your host can do nothing about.
I've seen a checkout drag because a shipping plugin called a carrier API live on every cart load, and a dashboard that took 4 seconds because a theme phoned home for news on admin_init. The tell is a call with a long duration or a non-200 status. Once you spot it, you cache the response, move the call to a background cron, or kill the feature. External HTTP calls are one of the three things I check first on any slow admin, right next to Queries by Component and PHP time. If checkout is your pain point, my WooCommerce speed optimization guide goes deeper on cart and API fixes.
How do you turn Query Monitor findings into fixes?
Query Monitor finds; you fix. Map each finding to an action. Heavy or duplicate queries owned by one plugin? Configure it down, replace it, or disable it where it's not needed. High repeated query counts that can't be removed? Add a persistent object cache with Redis so WordPress stops re-running the same lookups, which is a real fix, not a band-aid. The plugin even has a panel showing object cache hit rate so you can confirm it's working.
Database overhead from old revisions, transients, and orphaned meta? Clean it with WP-Optimize, then re-check the query counts. Slow external API? Cache it or move it off the request. Assets a plugin loads everywhere? Unload them per page with Perfmatters. After every change, reload the page and watch the toolbar numbers drop, because that before-and-after on the same page is the only proof that matters. To pull a full picture beyond one page, run my free WordPress site audit alongside it.
What mistakes should you avoid with Query Monitor?
The biggest one I see is leaving Query Monitor active forever on a live site. It adds real overhead, roughly 10 to 100 milliseconds of page time and around 10% more PHP memory per request, plus it exposes detail you don't want public. It's a diagnostic tool. Run it, fix things, then deactivate it. If you need it on a live site temporarily, set an authentication cookie so only you see the output.
The second mistake is diagnosing with caching on, which hides the queries you're hunting for. The third is blaming the database when Queries by Component clearly points at one plugin. And the fourth is ignoring the HTTP API Calls panel entirely; people obsess over SQL and never notice the 2-second call to a third-party server. Check all four panels, Queries, Queries by Component, Hooks, and HTTP API Calls, before you conclude anything.
When should you hire a developer?
Query Monitor is safe for any site owner to read. Anyone can spot the heavy plugin in Queries by Component or the slow API call and act on it, no code needed. Swapping a plugin, cleaning the database, enabling object cache, unloading assets, those are all owner-level fixes once the panel shows you where to aim.
Where it gets technical is the actual query work: rewriting a plugin's SQL, adding a database index, or building a custom object cache layer around a query you can't remove. That's developer territory, and trying to hand-edit core or plugin code without knowing what you're doing breaks sites. If Query Monitor keeps pointing at the same query and the only fix is changing how that code runs, that's the line where it's worth bringing in help. My WordPress speed optimization service does exactly this kind of query-level diagnosis and repair.
My checklist for Query Monitor For WordPress Speed
Look for slow database queries.
Check which plugin owns heavy queries.
Review HTTP API calls.
Inspect scripts and styles loaded on a page.
Compare admin and frontend behavior.