Minimising number of queries on a page when using Advanced Custom Fields

I’m currently working on a site where there is extensive use of the popular Advanced Custom Fields plugin. However, as a result the page loading time can be quite slow, especially when using the Gallery plugin.

Does anyone have suggestions regarding what the best practice is with managing a large number of custom fields? In some cases I am effectively working with thousands of variables, and need to reduce the page load time from some cases around 5s.

Read More

Quite an open question I know, though really it would be great to have some suggestions regarding how number of queries in a page can be minimised (such as through directly accessing values in the database perhaps rather than relying on a plugin’s APIs?).

Related posts

Leave a Reply

3 comments

  1. Performance optimization doesn’t really work in vaccum, it takes hands-on profiling an looking for actual bottle necks (which often turn out to be different from perceived ones).

    But it general there are several approaches to the need of lots of database data:

    1. Optimize fetching from database, for example by concatenating multiple requests into retrieving single larger set of data.

    2. Install persistent object cache and keep data in memory for faster turnaround.

    3. Cache resulting calculations or markup fragments to reduce how often they need to be retrieved and possibly making it async from actual page load.

  2. Yet is near heresy, but yes, if you want very efficient queries with very large and complicated date sets “directly accessing values in the database … rather than relying on a plugin’s APIs” is almost certainly the way this will work out.

    I don’t know about the particular plugin in question but frankly, plugins tend to be horribly inefficient. Some considerable blame lies with WordPress itself, as a number of its own core functions are inefficient and another fair chunk are not flexible enough to allow the kinds of queries/alterations that would allow the kind of efficiency I’d like. This in turn, forces plugin authors to either buck the strongly encouraged “use Core functions” rule, or make due with less efficient mechanisms. I believe can effect your ability to get things into the wordpress.org repos. I don’t really submit to the repos so I am not very familiar with the rules but I know there are rules.

    On the downside, “directly accessing values in the database” is going to mean more upkeep for the plugin as you will have track WordPress database structure changes.

  3. It is really hard to make any specific suggestions without a more detailed knowledge about your specific situation, but whenever I am stuck with a site that is slow for no good reason, I install Query Monitor plugin (https://wordpress.org/plugins/query-monitor/) and look closely at what it says.

    I use Advanced Custom Fields extensively, and more often than not the fault is not with the plugin itself, but one of the following things:

    1. Complex get_posts or WP_Query queries with multiple and / or nested 'tax_query' and 'meta_query' parameters. The ability to nest multiple arrays of arrays in these that was added recently is really not helping. At all.
    2. Loading large images without really needing it. When loading an image field, ACF returns an array that contains both url of the full sized image and an array with urls for each of the resized versions of it. You should be using the resized versions as much as possible to save bandwidth. If you absolutely MUST use large, shiny high-res images, consider implementing asynchronous image loading. Lazy Load (https://wordpress.org/plugins/lazy-load/) is a good plugin for that or you can write your own ajax call.
    3. Shitty hosting. There is no way around it – you can’t run WordPress on $1/month shared hosting and expect performance. It will never work.

    If you are outputting a lot of elements on the page (a long list of images / posts), you could also consider explicit pagination or cutting up the list and loading, let’s say, 10 elements first and then adding next 10 and so on either when the user scrolls to the current end of the list or when they click a ‘Show more’ button of some sort (also known as ‘infinite scroll’).

    Hope it helps.