Support

Account

Home Forums General Issues ACF Performance – Data Storage

Solving

ACF Performance – Data Storage

    • aegon

    • April 17, 2020 at 4:59 am

    Hi there!

    First off: wonderful plugin, I really like it.

    I’ve been a long-time user of the competition plugin. Not going to mention the name but I believe it’s the 2nd most popular metabox-related one, right after ACF.

    Anyways, I’m starting a new, pretty big project for a client and by an accident, I was asked to do some tweaks on another client’s website where ACF PRO is being used. I allowed myself to look around and I really like the way ACF works visually. It’s simply perfect.

    I tend to code all metaboxes programmatically and I was glad to find out it’s possible with ACF as well. I was nearly sold on making a switch over to ACF for all my future projects but… I noticed something that I’m concerned about which is related to performance & optimization.

    I created a repeater field and I found out that every single field inside is actually stored as a separate meta field meaning if I create a repeater field including 4 subfields and someone creates 10 items based on that, it will result in 40 meta fields… I got scared as I was expecting a serialized data inside a single meta field to what I’m used to.

    I noticed the same thing happens with the Options Page (creating a WP settings page with ACF). Every option field is actually a new record in the options table in the database. I was expecting a possibility to attach all of my option fields to a single option that would store the serialized data.

    I’ve been trying to find the reason why the plugin is designed this way but with no results which is why I’m creating this very topic.

    The question is: why is the approach of creating so many separate fields taken? Is there any specific reason for it? Am I missing some positives here? Why wouldn’t the repeater field data be stored serialized field but create so many meta fields creating all this bloat in the databse? Why can’t I store options in a single option field instead of creating so many different option fields?

    Or does it all NOT affect the performance and I’m getting it all wrong? I’d really, really like to make a switch over to ACF but this is truly holding me back.

    Thank you for your answers!
    F.

  • I am not the developer, but I’ve been using ACf for a very long time.

    In general, the reason that ACF stores all fields as separate entities is that ACF is only an admin tool and the ACF function are just wrappers for the build in WP function for meta and options values used for getting add updating these values. So, for example you can actually get the value of an ACF field by using get_post_meta();

    The repeater fields, and all repeater type fields, this includes repeaters, flex fields, and groups, this was done to conform to above and at the same time to allow a way to associate all of the fields on the same row because WP does not provide any way to relate one meta field to another meta field.

    The number of fields may affect front end performance slightly, however, it should not be significant. When WP sets up a post it automatically gets all of the meta values associated with the post in a single query.

    How you code can effect performance, for example, if you do any coding that does a query on the database based on the meta value, this could effect performance because it causes WP to do a “LIKE” query on the meta value.

    Where you will see performance drop off if you have a lot of fields is in the admin when making updates. This is due to the way that WP updates meta values as each field updated creates several queries. I personally do not concern myself with the performance of the admin.

  • work like a charm <3
    thanks a lot

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.