Skip Navigation

[Closed] Slow Performance

This support ticket is created 4 years, 5 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
- 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 -
- 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 -

Supporter timezone: Europe/London (GMT+00:00)

Tagged: 

This topic contains 3 replies, has 2 voices.

Last updated by Nigel 4 years, 4 months ago.

Assisted by: Nigel.

Author
Posts
#1676959
Schermata 2020-06-25 alle 15.10.00.png

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).

Is there any way to speed up this issue?

I show you the performance metric from google

#1677751

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

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.

You would use the WordPress function wp_schedule_event to schedule such a script (https://developer.wordpress.org/reference/functions/wp_schedule_event/). I can't write the script for you I'm afraid, if you need help with that you'll need to consult a developer.

#1678825

Hi Nigel thank you.

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

#1680187

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

"i still maintain the field comparison"

I'm not sure what you mean.

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.