Hi, we are experiencing a very slow performance on a large site.
We use Wp-Rocket to cache the site and also another dedicated server that caches and preload the entire site.
We have views that queries many posts, in particular i think the speed is slow due to this views that filters for next events from a custom field to compare the actual date with all about 6000 posts(event post type).
You can verify if the Views query is causing the slow page load by installing the Query Monitor plugin (https://wordpress.org/plugins/query-monitor/) and reloading the page. It will show all the queries on the page, and will highlight any slow queries.
If you have a large site and are querying using custom fields as a filter, then it is expected that this may result in slow queries.
It's the nature of WordPress and post meta, see hidden link
Views has built-in caching to improve this, but the problem in your case is that you are comparing a date field to "now", and "now" keeps changing. If you were comparing the date to "1 January 2020" then that is a static value and is amenable to caching, but "now" is a dynamic value that is not.
As the linked article describes, taxonomies are optimised for filtering posts in a way that custom fields are not.
You cannot change your date field to a taxonomy. What I suggest is that you make a taxonomy with a couple of terms, e.g. "past" and "future".
You can then write a batch script which runs every night, cycles through the posts and automatically sets the taxonomy term according to the value of the date field. You can then change your View so that it filters by that taxonomy instead of by the date.
I added the next events taxonomy and it is much much faster.
I would ask you for an advice:
In this new view I actually query next events via "next events taxonomy" but i still maintain the field comparison. Do you advise me to totally remove this?
We actually query about 20 events, i know it could be useless but i would to know if it can impact much on the speed.
Now i'm writing the script to schedule the automatic change of the taxonomy.
Thank you again my query time passed from 10sec to 1,3 but
You added the taxonomy filter as well as the custom field filter?
The intention was for you to replace the date query filter with a taxonomy filter, which would be much quicker.
You will still store the date field (you'll need it when outputting the details of the event, for example), but you won't be using it as a query filter (because it is slow). You'll use the taxonomy filter instead.
I'm not sure I understand your follow-up question, if you could please clarify.
The topic ‘[Closed] Slow Performance’ is closed to new replies.
