Caching multiple ACF values until they change

• 

  • gs84marketing

  • September 25, 2017 at 2:28 pm

  I’m not the most savvy, I can get a lot done but really advanced techniques are beyond me. I’ve tried hiring several people from Upwork and thus far to provide me actionable solutions to move forward with however, most of them know less than I do unfortunately.

  I’ve got a project with a lot of ACF fields. It’s a fantastic plugin that offers a lot of features when you need certain areas to be dynamic. The problem is, I’m trying to go back and optimize things for speed.

  There are a lot of fields where the value doesn’t change / hasn’t changed for a year. I’ve read a lot of places about not using get_field and using WordPress core functions to improve performance. I don’t know how substantial those arguments are or not.

  I have several page templates that use a lot of ACF fields where its been defined as something in the back-end but hasn’t changed in a long time. Normally I would just make this static in the template, but the site staff likes the idea of being able to change it (even if they don’t). In these cases I’m wondering if there could be a performance improvement by caching all relevant fields used on a page template so you only need one retrieval for 30 options instead of 30 retrievals.

  I don’t know how efficient ACF Pro is or what would be considered standard use. I know my project has a lot of fields that don’t change and it seems in theory it would be good to have all these unchanging values saved as a serialized array to manage the output on a page template of all the values. All of this I could likely do.

  What I’m trying to figure out is checking if the value has changed, I don’t know if ACF uses update_meta / update_option and re-saves all fields or has some native function that only saves changed fields. If there is a hook I can use to rebuild my values for the page template.
• 

  • psics

  • September 25, 2017 at 10:48 pm

  I would suggest that you use one field for fields and store them as an array + JSON. To do this, you can use the standard functions of WordPress and snippets.
• 

  

  • John Huebner

  • September 26, 2017 at 3:50 am

  get_field() is no less optimized that get_post_meta(), in fact, get_field() is just a wrapper for get_post_meta() that formats the value in a specific way before returning the value. If you use get_post_meta() then you need to do all that formatting work yourself anyway.

  There can be times when you may be doing extra DB calls when getting one field at a time, but these conditions are rare. You might see some improvement by calling get_post_meta() without specifying a meta key before getting any fields. For example $meta = get_post_meta($post_id);. What this does is forces WP to get all of the meta values for a post and to store those values into the cache so that no db calls will be needed to get values later on. After this you can go ahead and use the ACF functions as normal and be sure that no extra db calls are made.

  The best bet you have for improved performance is to install one of the caching plugins that are available for WP. This stores a static version of the page so that it is only updated when a change is made, dependent on the settings you use for them.
• 

  • gs84marketing

  • September 26, 2017 at 4:08 am

  I was just reviewing information presented here: https://craigsimpson.scot/performance-considerations-working-with-acf

  We have caching at the server level enabled, but we haven’t been able to use any WordPress level caching, it also interferes with some functionality or another. The site is a larger member-based system with a lot of dynamic features.

  There are a lot of plugins which add to load but I can’t control them, so I’m trying to do everything I can to improve performance and code that I’ve built.

  I’m quite happy to pay for someone to provide me a good practice to follow through. I’ve been testing looking at saving multiple fields into a single field and compare performance but I thought I’d reach out here to get some suggestions I might not think of or consider from my experienced developers.
• 

  

  • John Huebner

  • September 26, 2017 at 4:28 am

  The post you refer to uses an example with an image field. Image field, and gallery field performance can be significantly different depending on what value you return for this field.

  For example, if you’re returning image arrays (or objects) this will have a great impact on load time, especially if you’re loading many of these image fields or you have a lot of images in a gallery. This can also be impacted by the number of custom image sizes you’ve added to WP.

  When returning an image as an array ACF gets all the data for every available image size. 99% of the time you will never use this data.

  When it comes to image fields it is best to either return just the image IDs or to get the unfomatted value from ACF and then only get the values for the images that you need. Using an image field for a performance test in ACF is using the worst case field, but when it comes to image fields, I can agree that using native WP function and the image ID will improve performance over returning and image array.