Hi Elliot,
We’re running into an issue with one of our custom fields in that the edit experience is so slow as to make it unusable. It feels like this is a JS issue (though I could be wrong).
It’s a fairly complex field that has a structure like the below:
– Repeater
– text
– image
– select
– select
– flexible content
– text
– repeater
– file
– image
– true_false
– relationship
– textarea
– image
– repeater
– text
– text
With some conditional logic in there too!
Can you think of anything in the above that may be causing the page to load very slowly? I can get you access to a dev environment if you’re able to investigate.
Many thanks,
Glyn
Just an update on this – we’ve removed the conditional logic that was applied to the various fields and the load time of the page has gone down from 15-20 seconds to 5 seconds. This performance level would be fine but unfortunately all the fields on the page at once make it unusable in terms of reading the content.
Have you seen any performance issues with conditional logic elsewhere or is it something specific to our data?
Hi @Glyn
Thanks for all the info.
Are you able to export this field group to XML and attach it to a comment below.
I can then import the field, and test the JS myself and hopefully fix the lag.
Thanks
E
Thanks Elliot,
Attached is the export of the field group. Let me know if you need any more info.
Glyn
Hi @Glyn
Looks like the attached file didn’t upload correctly… Perhaps you will need to .zip the exported file?
I’ll do some testing with the uploader to make sure attachments are working.
Thanks
E
Hi Elliot,
How about this one? If you don’t get it I’m happy to email if you send me an address.
Thanks,
Glyn
Hi @Glyn
Thanks for the follow up. Yes, the .zip has uploaded correctly, thanks for that.
I’ll install the field group and test locally, but can you also download the latest ACF from github and override your current ACF with that?
The latest github code contains an updated JS logic for conditional functionality which may help the performance on your site.
Thanks
E
Hi Elliot,
Thanks for this. We’ve tried the latest from github, and unfortunately it seems to behave worse now for my situation. The page now rarely finishes loading and often crashes FF. I’ve now reverted back to my original copy of ACF.
Any luck testing locally?
Thanks,
Glyn
I seem to be having a similar if not the same issue for a site that I’m currently developing. Hang times of 30 seconds and up, sometimes completely crashing the browser (Chrome), depending on how much content I have input into the repeater.
The repeater field is somewhat complex, mostly text fields, and a nested repeater with image uploads. I removed all conditional logic that it had as I thought that’s what was slowing it down but the issue remains.
This is all on a local setup, mind you, running the latest WP release (3.8) and the latest ACF (I also tried the current build on GitHub to no avail).
If I can contribute anyway to getting this solved, let me know.
Thanks,
Scott
Hi Scott – my issue definitely shows a marked improvement after removing conditional formatting, so I think this may be a different issue.
Thanks,
Glyn
Hi @Glyn
Thanks for the follow up. I’m yet to do some testing but looking forward to seeing and fixing the issue
Thanks
E
This reply has been marked as private.
This reply has been marked as private.
I have run in to this issue as well. It seems like a very serious one, too.
In advanced-custom-fields/js/input.js, in the acf.conditional_logic object, the change event gets called for every single ACF input on the page.
This causes the JS to get slower and slower with each new field (or set) added because it’s checking the conditions for every field instead of just what was added or modified.
In addition to this, there is some display modifications on the elements during these nested loops that is causing a browser recalculate/reflow for every input. This all adds up to an increasingly slow, and at a certain point, unusable experience.
I put some timers in the code to illustrate the time increases with each new set of fields added.
Thanks for adding this Colin; it sounds like you’ve helped identify the issue here. Have you any thoughts as to the solution? (i.e. I’m wondering if it’s a quick edit we can make to the plugin files to at least make it usable again whilst we wait for an official update)
Cheers
Hi @collin.garvey
Thanks for the info. I think I might know what’s going on right now.
Please note that a recent push to github introduced some new logic which only runs the conditional logic on ‘new’ HTML, not ‘all’.
Thanks
E
Hi, I love your plugin. Congratulations for such a great effort.
Said that, I’m afraid my site runs super-slow recently becuase of this issue. Any updates on it?
Thanks in advance
I also had this problem, I found the answer to be in the included javascript of the repeater field (acf-repeater/js/input.js).
At the end of input.js there is this part:
$(document).on('mouseenter', '.repeater tr.row', function( e ){
// vars
var $el = $(this).find('> td.remove > a.acf-button-add'),
margin = ( $el.parent().height() / 2 ) + 9; // 9 = padding + border
// css
$el.css('margin-top', '-' + margin + 'px' );
});
$(document).on('acf/conditional_logic/show acf/conditional_logic/hide', function( e, $target, item ){
// Makes shit crappy slow
$target.closest('tr.row').trigger('mouseenter');
});
Just comment it out, and everything is fast again.
Hi @raldenhoven
Thanks for the feedback. I find it hard to believe that this fixes the JS lag, but stranger things have happened in the past!
Can everyone else try this fix?
Thanks
E
Well it doesn’t solve the problem completely, but it did change the click on a conditional field from 1.5s to beneath 300ms. But it still seems to go up when I add more repeater fields. I think it happens because when a condition is changed it still searches trough all the siblings of a repeater field.
When i change a condition in the first repeater, it should not check for changes in the second repeater. But this does happen causing lag.
But the above solution made my environment workable again, I think everybody could test it.
I’m a very happy punter, but unfortunately I have the same issue as described above – a general slow down that gets worse the more times the repeater (with conditionals embedded) is repeated.
The fix above has improved the situation a little, but there is certainly some very substantial (and probably unnecessary) JS overhead going on.
Looking forward to the official fix.
T
I too have a very slow edit page. However, I am NOT using repeater plugin on this page. I am using the flexible content though. Also, it gets worse and worse the more flexible content I add.
BTW, I do have the repeater plugin installed. Also, i’m on WordPress 3.8
/* After a little bit of debugging in Chrome code inspector */
Looks like there is a bunch of Garbage Collection that occurs during my 7 second freeze. Here is a screenshot: https://www.dropbox.com/s/43esgobg2jmzquq/Screenshot%202014-02-25%2009.29.37.png
Here is the timeline output for the event:
https://dl.dropboxusercontent.com/u/643924/TimelineRawData-20140225T092639.json
So what I did was click on “add new layout” for my flexible content, then choose one from the list and then it freezes. I also get lags in scrolling and just general stuff. Anything else I can do to help,just let me know.
Hi Elliot,
The suggested fix from raldenhoven didn’t work for me. Sorry, but I’ve noticed no difference whatsoever.
I can confirm the issue as mentioned above. Conditional logic in repeater field slows down the editing significantly.
If additionally you have nested repeater field with its own conditional logic then it can simply kill the editing experience.
EDIT:
Hi,
I’ve installed latest version from the github. I can confirm that editing experience is now greatly improved!
There is still a lag when adding new repeater field or changing select field with conditional logic but this lag does not grow exponentially like before. It seems constant.
Also before it was nearly impossible to add more than few images but now it works quite fast.
I’ll keep adding content and let you know if it goes downhill.
I updated to the latest github versions, but did not see any significant improvement. (not saying you’re lying!) Maybe its because of the flexible content instead of repetitor field?
Yeah, it didn’t work for me straight away. In my installation js was cached on WP level and on browser level.
So clean all you caches and ensure the new version of input.min.js is loaded on post edit page.
And yes I’m using Repeater field but not Flexible Content so I guess Flexible Content has its own set of problems which might have an impact.
The issue with JS performance is not completely fixed though anyway.
After adding like 10 repeater fields with 1-3 nested repeater sub-fields each the edit page loads terribly slow (on JS level). It can take 20 sec or more for JS to stop calculating whatever it is calculating before I can interact with the page.
Also time to add new Repeater increases with every added field. Increase is not exponential but it gets longer and longer to add each new field.
The same with conditional logic. They are fast when you start adding fields but after you have a few fields the lag is noticeable and is increasing with every added field.
.
advanced-cus....zip
