Table of contents of the article:
Query Monitor is probably one of the most useful tools available to anyone developing, managing, or optimizing a WordPress site. It allows you to observe what happens during page execution, identify slow or duplicate SQL queries, analyze PHP errors, check hooks, HTTP calls, scripts, stylesheets, and numerous other aspects that would normally remain hidden.
The problem, then, is not Query Monitor. The problem is how it is used.
Over the years, we've seen a fairly common bad habit develop: installing Query Monitor for a test, activating it, and then forgetting about it. The plugin thus remains present and operational for weeks, months, or even permanently, even when no one is actually analyzing the data it collects.
This is a conceptually flawed approach.
Query Monitor should be thought of as a diagnostic tool : you activate it when you need to observe how WordPress is working, you gather the necessary information, you identify the problem, and once the diagnosis is complete, you deactivate it.
Because, to borrow a rule that takes on a very concrete meaning in Poker, calling has a price.
In poker, seeing has a price. Even in debugging.
At the poker table, you can't keep looking at other players' hands for free. To get information, you have to pay, call a bet, or put something into the pot.
In software debugging the principle is not much different.
Gathering information has a computational cost.
If we want to know the number of queries executed, we need to intercept and log them. If we want to know which component generated a particular query, we need to collect additional information. If we want to analyze PHP errors, hooks, HTTP calls, templates, scripts, and other events that occur during the request, we must introduce an observation layer.
Query Monitor does this job extremely efficiently and with generally low overhead, but that doesn't mean the cost is mathematically zero.
Observing a system inevitably means using some of that system's resources.
And this is where we need to distinguish between use and abuse.
How Query Monitor Works
When Query Monitor is enabled, WordPress provides the administrator with a range of information about the current request. The admin bar immediately displays useful indicators, including the time it takes to generate the page, peak memory usage, the total time spent by SQL queries, and their number.
By opening the relevant panels it is possible to go much deeper into the analysis.
Query Monitor can show, among other things:
- le SQL queries performed during the request and the related execution time;
- slow, duplicate, or error-filled queries;
- the plugin, theme, or feature responsible for certain queries;
- PHP errors, warning, notice and use of deprecated functions;
- hook, action and filter involved in execution;
- requests made through the HTTP API of WordPress;
- loaded scripts and stylesheets with their dependencies;
- templates and template parts used;
- information about PHP, WordPress, database and web server environments;
- conditional tag and other information related to the current request.
So it's much more than just a query counter.
Query Monitor builds a real X-ray of the WordPress request , trying to relate the observed events to the components that generated them.
And it is precisely this ability to observe that makes it invaluable during a diagnosis.
To gather information you have to do some work
One of the most common mistakes is to think that since the Query Monitor panel is visible only to the authorized administrator, then its operation is completely free in terms of resources.
This is not the correct way to think.
To present diagnostic information, Query Monitor must connect to various points in WordPress execution, collect data, organize it, and retain it long enough to later display and analyze it.
On a healthy, relatively simple site, this overhead may be small and barely noticeable. But a small overhead doesn't equal no overhead at all.
The difference becomes particularly interesting precisely on the sites where Query Monitor is used most often: those that already have a problem.
Imagine a WordPress page that executes hundreds of SQL queries, generates numerous warnings, makes numerous calls to external APIs, or loads an abnormal number of components. Query Monitor will need to collect significantly more information than would be necessary to analyze a simple page that executes a few dozen queries.
Consequently, the more complex or pathological the system to be diagnosed, the higher the cost of its observation can become.
The paradox: Query Monitor can be the most burdensome precisely when the site is having problems
This aspect deserves particular attention.
A WordPress site that is already close to its PHP memory limit, with an excessive number of queries or with numerous events to monitor, is starting from a resource-starved state.
By activating a diagnostic tool we simultaneously ask it to continue running normal application load and to log information about what is happening.
This is why, in certain situations, Query Monitor may contribute to increased memory usage or the time it takes to generate the page.
This isn't a conceptual flaw in Query Monitor. It's a natural consequence of instrumentation and profiling.
This also happens in other system areas: enabling extremely verbose logging, tracing, profiling, or debugging modes comes at a cost. These are valuable features when we need to troubleshoot a problem, but not necessarily configurations that need to be permanently maintained for no reason.
Debugging is an operational state, it should not become the normal state of the system.
The risk of measuring a site by altering what we are measuring
There is also another important issue, especially when Query Monitor is used for performance comparisons.
If we want to know the real-world performance of a given WordPress configuration, we should try to measure it as much as possible under the conditions in which it will actually be used.
Keeping a diagnostic tool active during every test can introduce an overhead that ends up partially altering the data we want to measure.
This doesn't mean the numbers displayed by Query Monitor are useless. On the contrary, they're extremely useful for understanding where WordPress spends time and which components are involved during a request.
However, we must distinguish between two different questions.
The first is: “What is WordPress doing during this request?”
To answer, Query Monitor is an excellent tool.
The second is: “What is the actual performance of the production site without instrumentation?”
To seriously answer this question, you also need to perform measurements with Query Monitor disabled and use appropriate benchmark tools.
Installed does not necessarily mean to leave active
There is also a common misconception in the WordPress ecosystem: if a plugin is useful to us, then it must necessarily always remain active.
It is not so.
There are plugins that are an integral part of the site's application functionality and must obviously remain active. A caching plugin, a WooCommerce extension required for checkout, or a custom application function typically fall into this category.
Query Monitor, on the other hand, has a different purpose.
It is a technical observation and troubleshooting tool.
There's no need to delete it every time. It can easily remain installed and deactivated, ready to be reactivated when a diagnosis is needed.
What makes little sense is to leave it active for months simply because “it might come in handy.”
When it comes in handy, it only takes a few seconds to activate.
The correct way to use Query Monitor
A sensible procedure is very simple.
When a slowness, strange behavior, or error is reported, Query Monitor is activated and the problem is reproduced under the necessary conditions.
Then you look at the data that is actually relevant to the diagnosis: SQL queries, times, HTTP calls, errors, responsible components, hooks, or any other useful information.
The cause of the problem is then identified, a change is made if necessary, and the test is repeated to understand what has changed.
Finally, a performance check is performed even without Query Monitor.
Once the work is finished, the plugin can be deactivated again.
In summary:
- activate Query Monitor when there is something to watch;
- to collect the information necessary for the diagnosis;
- to correct the problem identified;
- check the site's behavior again;
- deactivate Query Monitor when the diagnostic phase is complete.
It is a simple, clean operating model that is perfectly consistent with the role of the instrument.
Query Monitor in Production: Yes, but Only When You Need It
This is not to say that Query Monitor should never be enabled on a production site.
There are issues that only appear in production and can't be easily reproduced in staging. In these cases, being able to directly observe the actual request can be extremely useful.
The important thing is to understand the difference between conscious activation and permanent activation by inertia.
Enabling it on a production site to investigate a specific issue, collect the necessary data, and then deactivate it makes perfect sense.
Leaving it active indefinitely just because “it doesn’t bother you” is a much more questionable choice.
Especially on very complex WordPress installations, WooCommerce with many extensions, heavy backends, or systems that are already running hundreds of queries per request, each additional diagnostic layer should be used with a specific purpose.
The problem is not the tool, but the lack of operational discipline
In systems engineering, there is a huge difference between having lots of tools and knowing when to use them.
Detailed logging, profilers, debuggers, tracing, and diagnostic tools are indispensable when something goes wrong. But indiscriminately keeping every debugging level permanently enabled doesn't necessarily make a system more controlled.
It often just makes it more complex.
The same principle should be applied to WordPress.
A production environment should contain and maintain the components necessary for its normal operation . Tools used exclusively for development and troubleshooting activities should be used only when there is a concrete reason to do so.
This approach also allows you to avoid paradoxical situations in which you are trying to optimize WordPress while simultaneously keeping plugins and diagnostic modes active whose results no one is reading.
“But Query Monitor has very little impact”: that's not the point
One possible objection is that Query Monitor is carefully designed and that in most installations its overhead is small.
It's true, and it's important to say it.
Query Monitor should not be demonized, and it would be pointless to present it as a plugin that, by itself, necessarily turns a fast site into a slow one.
The point is an other.
If we don't need a diagnostic feature right now, why pay even a small cost for it?
On a single request, the difference may be negligible. On a pathological page with hundreds of queries, numerous errors, HTTP calls, or a significant amount of information to collect, the effect can become more noticeable, especially in terms of memory.
And most importantly, there is no real benefit to incurring that cost when no one is analyzing the data produced.
This is precisely the meaning of the expression "seeing has a price." It doesn't mean that the price is always high. It means that the price exists and there must be a reason to pay it.
Conclusions: turn it on, use it, then turn it off.
The final message is therefore extremely simple.
Use Query Monitor. It's an excellent tool for diagnosing WordPress problems, understanding SQL queries, identifying errors, analyzing HTTP calls, and understanding which components are involved in generating a page.
But use it consciously.
Don't leave it permanently active on a site simply because it was installed during a troubleshooting activity six months ago and no one remembered to disable it.
Also, don't confuse a query executed under instrumentation with a neutral benchmark of your site's actual performance. Use Query Monitor data to understand where and why WordPress is working, then confirm the final result under normal operating conditions.
Good systems management isn't about turning on every available tool and leaving it on forever. It's about knowing which tool to use, when to use it, and when you're no longer needed.
Query Monitor is no exception.
Because even in debugging, just like at the poker table, seeing has a price.
