Support

Account

Home Forums Feature Requests Better performance when saving large numbers of fields

Solving

Better performance when saving large numbers of fields

  • Currently if you are using ACF in an advanced configuration (particularly as a page builder with nested repeaters/flexible content), you can easily get some really terrible load times when saving pages (I’ve seen +30s times). I know this is due to how WordPress saves custom field data (one at a time), but I’d like it if ACF could implement some improvements on top of this.

    Potential ideas along these lines are tracking changed fields and only submitting new or altered fields when saving a post – that would help with updates but would of course still be painful on a first save. Also potentially if the WP update_metadata function could be avoided in favor of a more efficient query – though I know ACF prefers to do things the WordPress way as much as possible. My last idea is if each field group could be individually be configured to store its data in a serialized format instead of as individual fields – allowing for fields that do not need to be queried individually to instead be stored as a single object (similar to how most page builders store everything in post_content).

    I’m sure there are other possibilities, but these are the ones I’ve come up with while thinking about this issue. Clone fields largely fixed a similar issue when creating large field groups – but this side of it remains an issue.

  • Yes, I tend to agree. I’ve thought about this every time this topic is posted and it’s posted fairly regularly. I personally like the second option you mentioned, avoiding the WP meta data functions entirely. I also know that Elliot tries as you say “to do things the WP way”. The third option I know is really out because that would pretty much eliminate the ability to use standard functions in place of acf functions, get_post_meta(), get_option() and the like, which is also something that the developer wants to avoid. Back in the beginning he worked very hard trying to figure out how to save repeater field and flex field rows in the standard WP fashion before he decided on the current solution because there was no way in WP to keep the fields of each row associated properly.

    I think that until one of us that has the ability to do so creates some type of fast save add on, or E finally finds many hours of time and the desire to do it, that we’re not going to see it.

    I do think that it is possible, I’ve thought about it and looked into it a bit. If you have an acf/save_post action that run before ACF and you use some other method for inserting and updating all the meta data and then you clear the $_POST[‘acf’] value, this will pretty much bypass ACF and cause it to do nothing. The real problem comes in when you try to do all that updating yourself, that’s the tricky part. If I had the time to do it I would. And then you also need to account for all of the ACF add on fields that have been created. It’s really no small task or to maintain.

  • I’m going to try to work on something, but it’s going to take some serious testing and community support https://github.com/Hube2/acf-fast-save. Nothing there yet except my random thoughts.

  • I’d like to help as much as possible, and will spread word of your effort. Time is (as you say) a major constraint, but I’ll do what I can. I think this issue is a real limiter on the usefulness of ACF going forward, and I’ve already had to make design decisions based around it on several occasions.

  • I’ve been digging through the code in ACF and I’ve discovered something else that slows things down. Revisions. If revisions are supported by a post type then this will more than double the number of queries that need to be performed. Revisions is not something that I thought about. Before saving the values ACF gets all the existing values and copies them to the most recent revision and every field goes through the same update process for the revision.

  • I make dev decisions based on this limitation all the time. When I see that the group might get out of and then I must find a better solution. But I’m in the middle of building another page builder type of field group that has a potential of having…. well, an infinite number of content editors, not to mention the supporting fields. I’m afraid that even if I limit the users that the number could grow out of control.

  • Hello,

    any updates on your plans to develop this plugin?

    We’re very interested. Also having +30s delays on save_post with big flexible content field (used as the main content builder). We also need revisions.

    All the best,
    LXT

  • I’ve pretty much given up on this. WP does not support any way to bypass the way that post meta is saved, at least nothing that can be depended upon.

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

The topic ‘Better performance when saving large numbers of fields’ is closed to new replies.