I have a page on my site that uses multiple nested repeater fields, multiple levels deep, and it causes the “edit page” section to load extremely slowly. The frontend page still loads quickly, but when I want to edit the page it takes a good 3-4 minutes to fully load and I have to tell Chrome to “wait” at least 3 or 4 times. This happens any time I add a new category or product as well, not just on initial load.
Here is an overview of the field nesting structure:
Product Section
—-Product Category
——–Category Name
——–Products
————Product Name
————Product Logo
————Product Links
—————-Link Title
—————-Link URL
Is there any way to speed up the page load or do we just have to live with it?
Thanks in advance!
Same here…
Running also add_filter(‘acf/load_field’) to preload some data, but have deactivated for speed purposes, still slow…
Is there any way to hav ACF 1st load all HTML, then later a step by step action of loading the stuff?
Any news on this? Im using the ACF PRO!
Thanks.
I am also interested in a fix for this. Unless a fix can be made for this issue then ACF should warn people not to build too much content using repeater fields. I have a nightmare on my hands involving a lot of content due to this issue.
Yup, we’re experiencing a bit of this as well, although not as extreme
– A flexible content canvas that contains multiple flexible content blocks, each of which can have 20 – 30 ACF fields of all types (checkboxes, repeaters, wysiwyg, taxonomy choice, etc)
On the more complex pages (15 or so content blocks), it can take up to 20 or 30 seconds to update. Would really like to get a handle on this as we’re right on the line between tolerable and intolerable.
Here is complicated because some systems created using the ACF and my customers using my tool are complaining that delay in page editing.
When will this be resolved?
I’m also experiencing slow load times on pages with repeater fields. Pages are waiting up to 12 seconds before they load. Page size is small, ~639KB. Any thoughts?
So this may be a solution for some of you. I found that when using the image field, having it return an object significantly slowed down my page load. By switching it return the image id, my page load went from around 12-16 seconds to around 2-3 seconds.
I have found that you need to be a little careful about how complex you build field groups. On of the sites I build the client needed to ability to add multiple section to page. Each section could have up to 7 WYSIWYG editors. Each of these editors also had various layout controls for borders, padding, font settings, etc. This worked fine at first by then the client added a page with 20 sections, that’s 140 WYSIWYG editors. The update process timed out. There really isn’t a solution unless someone comes up with a way to update all of those fields in the postmeta table in a single query rather than one at a time.
As far as getting information @gecugamo is correct. When using image fields you’re better off returning the ID and then doing the work yourself. ACF building of image objects is a serious drain and can take a long time, especially if you have a lot of custom image sizes.
I posted this on another thread, but in the interest of helping others out and getting some feedback I’ll post here as well…
I’ve run into a similar issue specifically with JS performance and multiple TinyMCE elements. I’ve been working on a fix that I’d love some help testing.
Like many of you I end up with sites that have a TinyMCE field in a repeater or flexible content widget. If the client ends up adding more rows than expected the performance degrades quickly.
So I built an add-on field that lazy loads the TinyMCE editor when someone wants to edit the content of the field. That way only one TinyMCE instance is active at a given time and performance improves significantly.
I’ve used it in a few places and it currently supports both ACF4 and ACF5, but I’d love to get more people using it to see if I’ve missed anything.
You can download and try it out here https://github.com/3pointross/ACF-Lite-WYSIWYG
Any feedback would be great.
