Use Query Monitor to debug WordPress and improve website performance
Performance issues are often encountered when dealing with WordPress development projects that have dozens or more plug-ins installed. However, it is not always easy to figure out the cause of performance problems. A common way to identify troublesome plug-ins is to deactivate them until a performance bottleneck is found.
However, you can use the free Query Monitor plug-in to better solve problems. It can help you debug performance issues, develop your website more effectively, and better handle your WordPress website.
In this guide, you will learn everything you need to know about Query Monitor-what it is, what it does, and how to use it.
article directories
What is Query Monitor?

Query Monitor is a 100% free plug-in that helps you debug the performance and development of your WordPress website.
You can think of it as a Chrome developer tool, but specifically for WordPress. You can delve into database queries, scripts, scheduling, and more. You can also view a lot of useful information, such as general environmental information and details on specific pages.
Query Monitor then presents all this information in an easy-to-access way that you can access from anywhere on the site.
Query Monitor is maintained by John Blackbourn, chief Web engineer at Human Made. He also has several other useful plug-ins, including WP Crontrol (great for wp-cron debugging) and User Switching (great for debugging the experience of different user roles).
John is quick and constantly committed to maintaining and improving Query Monitor. Automattic and other sponsors support his work.
What does Query Monitor do?
Query Monitor can help you debug more than just queries to WordPress databases, it also delves into many other areas, including performance-centered debugging and general development debugging.
Here are examples of many details that Query Monitor can help you analyze and debug:
- Database queries, including displaying queries from specific plug-ins
- PHP errors
- memory usage
- HTTP API calls
- Queued scripts and styles, including dependencies
- Hooks and actions
- Theme template file
- language and translation
- rewrite rules
- Block Editor Block
- General environmental information
- WordPress Management Screen
A significant limitation of Query Monitor is that it is mainly used for “on-the-fly” debugging. When it shows you database queries, time, etc., it only does it for the current page load.
It typically does not track or display historical information/trends, although John said this feature is planned for future releases.
How to use Query Monitor to debug WordPress and improve performance
Now that you know what Query Monitor is and what it does, let’s learn about how to use Query Monitor to debug site performance and some other tools for general development debugging.
We will give you a brief introduction to the query monitor interface and how it works. Then we will delve into each area in the interface.
Introduction to Query Monitor
Query Monitor does not have its own independent interface area. Instead, it displays new information in the front-end and back-end WordPress management bars.
Query Monitor initially displays a quick summary of four pieces of information:
- Page generation time–0.05 seconds in the screenshot.
- Peak memory usage–7.7 MB in the screenshot.
- Total time spent in SQL queries(in seconds) 0.00 seconds in the screenshot.
- Total SQL queries–54 in the screenshot.

If you click this summary, you will open the entire query monitor interface, which appears overlaid by a window on the front-end or back-end page you are currently viewing.

All functions and information provided by Query Monitor are included in this overlay window.
If you want to change the layout of the overlay window, you can click the button in the upper right corner to switch it to the sidebar interface. You can also use drag-and-drop to change the size of a window.

The Query Monitor interface and its information are only visible to administrators (or super administrators on WordPress multiple sites).
There is also an option to set an authentication cookie to still view query monitor output even if you are not logged in (or you are logged in as a user with a lower user role). We will share how to do this in the guide later.
Let’s browse through each tab in the interface and explain how to use it to debug your WordPress website.
overview
overviewThe tab displays more detailed information from the management bar summary and some general environmental information.
For example, the “Overview” tab can not only view peak memory usage, but also further view peak usage compared to your server and WordPress memory limits.

There’s nothing too detailed here-it’s just an overview (hence the name).
query
queryTabs give you insight into each database query for the page you are viewing. It is one of the most informative areas in the query monitor, which makes sense when you consider the name of the plug-in.
For each query, you can see the following information:
- a complete query
- Query caller
- Query components (e.g. whether they come from core, theme, or plug-in)
- number of rows
- Time taken to query
In general debugging, you can use it to find slow-loading queries that hinder the performance of your website.
The query monitor will break down the query by your theme and individual plug-ins so that you can see the impact of each extension.
Suppose a particular plug-in causes a large number of slow-loading queries. In this case, you need to find a way to solve the problem-either by optimizing something in the plug-in settings or server configuration (such as using a database or object caching), or switching to a different plug-in that is more efficient.
In the main tab, you can view all advanced information for each query.

If you want to learn more about a specific query, click the plus icon to expand more details.

If you see abnormally low numbers here, it could be due to some type of caching-such as page caching or plug-ins that cache their database queries. Therefore, it can be helpful to disable caching while debugging.
There are also some sub-menus in this area that help you find specific types of queries:
- Duplicate query
- Caller inquiry
- Query by component
Duplicate query
Duplicate queryThe area highlights duplicate queries and lists “potential troublemakers” to help you debug them and simplify things.

requester query
requester queryThe area allows you to view all requesters on this page. If you click one, you can see a query list for that requester.

Query by component
Query by componentThe area displays a list of all components for querying, including the WordPress core, your theme, and individual plug-ins.
You can click on a specific component to view all of its queries.

Again, this is one of the most valuable reports because it allows you to find specific plug-ins that can degrade your website’s performance due to slow queries.
If you don’t view the query by component, please read this
If you don’t see component information in Query Monitor, it may be because Query Monitor cannot symbolically link its db.php file. In these cases, you will see an error message like the following.

Here are two possible reasons:
- File permissions for your site’s wp-content folder.
- The wp-content/db.php file already exists (probably because of caching plug-ins like W3 Total Cache).
You can see some fixes and workarounds in this GitHub article. If you feel comfortable connecting to your server via SSH, you can use the WP-CLI command to resolve the problem.
Most query monitor features will still resolve this issue, but you will not be able to see any component information until the issue is fixed.
log
logThe tab is an advanced tab that lets you set the messages and variables to log. This can help you debug technical problems or pay close attention to your site to identify problems.
When you first install Query Monitor, this tab will not display anything because you have not set any logging variables.
However, if you do want to set custom logging variables, you can use this simple syntax:
do_action( 'qm/debug', 'This happened! ' );
Query Monitor supports the following operations, allowing you to record issues at different levels:
- qm/emergency
- qm/alert
- qm/critical
- qm/error
- qm/warning
- qm/notice
- qm/info
- qm/debug
If you want to learn more and see some examples, check out the Query Monitor Logging Variables page.
request
requestThe tab displays the currently requested query variables.

Also checkRequest HeadersandResponse Headers, which may be more helpful for performance debugging.
For example, maybe you want to debug caching behavior or CDN behavior. inResponse HeadersIn the submenu, you can see the Cache-Control behavior, allowing you to debug browser caching on your site.

block
Only when you view a page built using the WordPress Gutenberg Block Editor,”block“The tab is only visible.
One of the smart things here is that it will tell you whether the block comes from the WordPress core or another plug-in.

template
Only when using Query Monitor on the front end of the site,templateThe tab will be visible. It helps you view and debug the template hierarchy for the page you are viewing.
You can see the specific template file for the page as well as the various template sections and body classes.
This has nothing to do with performance, but can be beneficial for custom theme development.

management screen
Only when you use Query Monitor in the WordPress Management Dashboard,management screenThe tab will be visible. You may not use it often, but it can be helpful if you need to debug behavior in the Custom Management screen.
If you view the management screen with lists, it displays custom column filters and actions. It will also show you the status of get_current_screen.

script
inqueryAfter the tab,scriptTabs are probably the next most useful performance debugging area in the query monitor.
This tab displays each queued JavaScript script on the page and its dependencies and dependencies. You can also use filters to quickly find scripts from specific hosts or that have explicit dependencies/dependencies.
As a rough rule, more scripts equals a slower website because they increase page size and add HTTP requests.
You can use this area to discover the impact of different extensions and find ways to reduce the number of queued scripts loaded on each page.

However, query monitor does not show you the load times for all these scripts. If you want to see this, you’ll need to use speed testing tools and delve into waterfall analysis-both Pingdom and GTMetrics are great choices.
Expand reading: Who is the best website performance Detection Tools: GTMetrics, PageSpeed Insights, Kingdom Tool, WebPageTest
style
StylesTabs are similar toScriptsTab, but it displays queued CSS instead of JavaScript. This is another convenient tab for debugging performance on your site.
Like scripts, loading more stylesheets on a page often causes the site to load slowly.
In this area, you can discover the impact of different extensions on your website. You can use this information to reduce the number of stylesheets that need to be loaded on the page, which will reduce the file size and the HTTP requests required to load the page.

Like scripts, Query Monitor does not delve into how CSS is loaded and whether it prevents critical parts of the site from loading. To do this, you need to use waterfall analysis again.
Hooks and actions
Hooks & ActionsThe tab lists all hooks and actions on the current page and their priorities.
For operations, you can expand individual operations to view the actual files and lines of code associated with the operation. You can also filter actions by component to find actions from WordPress cores, plug-ins, and themes.
This area is not really about performance, but it is easy for custom development.

language
languageTabs show the language and text fields on your website and the language files used for each extension.
If you have a single-language English website, this is not very useful. However, if you have a multilingual site and/or your site is in a language that may not have full translation package coverage, this tab can be helpful.
HTTP API calls
HTTP API callsThe tab shows you all server-side HTTP requests that occurred during page loading, including request details, time, and HTTP status codes.
If the HTTP API calls for a plugin or theme are slow, which is often a “hidden” cause of poor performance, you need to find a way to resolve this problem, either by changing something in the extension settings or switching to a different extension.
For many pages, you should see “no HTTP API calls”, which is a good sign, because it means nothing is hindering the performance of your website.
capability check
Capability ChecksAreas allow you to view which user features can access the current content you are viewing. This makes it easy to see whether certain front-end or back-end content can be accessed by different users.
However, for performance reasons, this feature is disabled by default. If you want to enable it, you need to edit thewp-config.phpFile and add the following code snippets:
define( 'QM_ENABLE_CAPS_PANEL', true );
environment
environmentThe tabs provide a detailed summary of the site environment, including:
- PHP
- database
- WordPress
- server
You can view important details, restrictions, version numbers, configuration settings, and more.
This can also inform important decisions about performance.
For example, if you find that your site’s memory limit is limited, you may want to increase the memory limit to avoid errors related to memory limits.
Similarly, if you find that you are using an older version of PHP, you may need to upgrade to the latest version to improve performance.

conditionals
conditionsTabs help you see which conditional statements apply to the page you are viewing, which helps with custom development.
You can see “true” conditional sentences and “false” conditional sentences.

How to view Query Monitor information as a non-administrator user
In some cases, you may want to view query monitor information as a different user role or as a registered user. This is very useful for WooCommerce stores, member websites and similar sites.
You need to set an authentication cookie in your browser to do this. After setting this cookie, you can view query monitor information whenever you visit the site, even if you have logged out.
To set an authentication cookie, click the gear icon in the upper right corner of the Query Monitor panel. Then, clickSet authentication cookiesButton.

If you want to disable this feature, you can return to this interface and clickClear authentication cookiesButton to delete cookies.
If you combine it with another useful plug-in, User Switching, from the same developer, you can quickly switch between different user roles on your site.
How to use the Query Monitor extension
So far, we have only focused on the features and analysis options in the core Query Monitor plug-in. However, some third-party plug-ins can further extend the query monitor.
These can add support for specific performance technologies, such as Memcached and Redis, and specific WordPress plug-ins, such as WooCommerce or GiveWP.
Query Monitor also supports all add-ons to the Debug Bar plug-in, which adds integrations of ElasticPress, Elementor, Cache Lookup, etc.
You can view the complete list of Query Monitor plug-ins on this GitHub page.
summary
If you want to debug performance and development issues on a WordPress website, the Query Monitor plug-in is one of the best free tools out there.
To analyze the performance of your website, you may need to focus on these areas of the interface most:
- overview
- query
- Log (for more advanced users)
- script
- style
- HTTP API calls
- environment
However, if you develop a WordPress website, other areas are also convenient.
Try Query Monitor now and see how it helps. If you don’t want to install it on your real-time site, you can always create a temporary site and install it there to see what’s happening on the bottom of your site.
Expand reading:
- Website Performance Detection Tools: GTMetrics, PageSpeed Insights, Kingdom Tool, WebPageTest
- How to use the browser’s developer tools to debug a website
- 11 WordPress debugging plug-ins for developers
- Detailed introduction to the WordPress configuration file wp-config.php
- How to turn on and set WordPress debugging mode
- Basic Guide to WordPress Debugging Mode
- 23 excellent PHP code editors and IDEs for WordPress developers to choose from
- 12 useful WordPress website mobile device testing tools
- Debugging and fixing a 503 service unavailability error in WordPress
- Ten ways to speed up WooCommerce stores
- Imsanity: Limit the size of uploaded pictures
- Accelerate your website with WebP images
- How to use WebP images in WordPress?
- How to optimize pictures to speed up WordPress website loading
- WordPress caching guide and caching plug-ins recommendations
- 6 easy-to-use WordPress Lazy Loading Delay Loading Plugins