There is a specific performance problem with queries in WordPress that has a quick fix, but it is not well documented — maybe because it has a hard-to-understand name and function.
Origin
This performance problem has its origin in MySQL. There is a query modifier named SQL_CALC_FOUND_ROWS which returns the total amount of rows if the query had no limit.
For example, if we had an SQL query with a limit of 5, this modifier would return the total number of results it would have if there was no limit.
This modifier has performance issues and has been deprecated and replaced with a new method. But it happened in version 8.0.17, and versions 5.* are still more common in commercial web hosting. To the point that most hosting companies have blog posts warning about it and its effect on performance.
Problem
WordPress uses this modifier in all its queries by default, mostly for pagination purposes. Knowing the total results a query would have allows WordPress to know how many pages it will require to show all results, thus calculating how many pages. This is necessary when displaying pagination.
WordPress contributors are working on a solution to this, although it is still not scheduled for release.
Solution
Whenever pagination is not needed — because some templates will not display pagination navigation, or when making a query for related posts or post lists on a sidebar — you can use a parameter to tell WordPress to not include this modifier in its SQL query.
The parameter in question is 'no_found_rows', which can be included in any WP_Query.
What does it mean?
The name is not self-evident, because it comes from a variable name in earlier WordPress versions: $found_rows, which included the SQL query modifier to include it in queries.
In version 3.0, released in 2010, a new parameter was added to be able to tell WordPress not to use this modifier: 'no_found_rows'.
How does it work?
This is where it gets tricky.
'no_found_rows'isfalseby default, and this means that the query will use the modifier and count the rows so pagination can be used. If'no_found_rows'is set totrue, WordPress will not include the modifier in the query.
Which can be confusing. If true, there is no modifier, no row count, and no pagination. If false, the modifier is included, rows are counted, and there will be pagination — or the possibility of having one.
Summary
Every time we include a WP_Query that will not display or use pagination, we should set 'no_found_rows' to true. It can have a huge impact, especially when there are several post lists on the same page. In a given project, I had the time needed to complete all queries on a page reduced by >90%, so use it as much as you can.