Support

Account

Register Login

Home › Forums › Backend Issues (wp-admin) › JS performance issues

Solving

JS performance issues

  • I’m having this issue with my Repeaters as well in ACF5. I think Elliot’s question of how much HTML and JS is on the page could be correct.

    I’ve got a page with only 57 repeater rows. Each repeater has some conditional logic resulting 9400 lines of HTML. 1600 lines of that is TinyMCE and the Media Library scripts.

    Has anyone else made any progress on finding a solution for this?

  • –

  • Hi all,

    Updated x2 websites to the latest version to 5.2.1. Both sites have the exact same fields with plenty of repeaters. I have no idea whether it should make a difference but 1 site is on a Windows server and with 6000ish lines of HTML it takes 1.1min TTFB post.php. The other is on a linux server and has 9500ish lines of HTML and takes 35sec TTFB post.php.

    Even 35sec is a bit laggy,if I had known it would slow down so much I would have used a different plugin, but the repeater field seemed perfect. Many have contributed content to my sites using ACF and repeater so switching to a different plugin would be impossible.

    Elliot, if you’re out there, please come up with a fix :/

  • QuietNoise, have you got those patched files handy. I tried editing manually but didnt have much luck

  • Any solution for that??

  • I’m also having this issue. Repeater field with conditionals is rendering the backend virtually unusable.

    Elliot, any update on a fix?

  • I’m having load issues using a repeater field with conditionals as stated above. The main problem is the JS load time crashes the browser, and I also get a lot of “connection lost” errors.

    I changed all text fields to text areas versus wysiwyg, and also elminated a couple of conditionals. This helped a little bit, but still not good.

    I’m thinking of rebuilding using the ACF Pro with the Flexible content. Can you tell me if you think this would solve my issue?

  • After spending many days trying to fix this issue I gave up. I think the problem is a fundamental flaw in the way the ACF repeater code is written, and to fix would involve the ACF authors rewriting the plugin. ACF is an excellent plugin but they should warn customers that the repeater and flexible content fields have their limitations. at least then developers, such as myself, wouldn’t have the embarrassment of trying to fix this issue when a site is in production and being edited daily.

    For my own situation I was able to come up with a workaround. My repeater rows had:

    ***Client name (text)***Client rating (1-5 number selection)***Comment about client (textarea)***Comments about improvements (textarea)***

    I removed all the repeaters and replaced them with a single textarea. The editors input each row as a new line in the textarea. Each field in the content is separated with a “#”, like this:

    Walmart#3#Walmart communicated effectively to get the job done.#Walmart has issues with management that could be addressed.

    KFC#4#KFC were excellent clients, understanding and trustworthy#KFC could improve their internal workforce structure.

    The textarea is called “clientreport”. To call the data I use:

    $str = get_field(“clientreport”); /////this gets the field////
    $arr = explode(“\n”,$str); /////this explodes the content by line break/////
    foreach ($arr as $arrs){
    $arr2[] = explode(“#”,$arrs);} //////this explodes each row by “#”////
    echo $arr2[0][0]; ////will echo out “Walmart”////
    echo $arr2[1][0]; ///will echo out “KFC”/////

    This gives me a similar array as with the repeaters and I can foreach through the array. Above the “clientreport” textarea I put a format example for the client.

    This workaround worked for me and may help some poor soul.

    If you have a lot of repeaters I would advise understanding the plugins limitations and trying to come up with your own workaround.

    Can ACF please communicate the plugins limitations when it comes to using lots of repeaters/flexibles.

  • @hammersmith Pro and flexible makes no difference 🙁 If you do upgrade make sure you backup database as I would lose the fields when rolling back to a previous ACF

  • No response from Elliot since September. Is this problem a priority? Is it going to get fixed? Would really appreciate an answer on that.

    Best regards
    AC

  • Hello

    Is there any reassurance that performance issues as a result of scaling up is a high priority? We’ve started rolling this out to our publisher CMSes however I’m noticing slow down on busy pages with multiple flexible-content elements. I’m apprehensive that gradually as we add more features it will become unusable and plan B will be almost inconceivable.

    Even a performance tuning API/tips might really help: For example if we could flag that on a repeater or flexible-content that if there are more than X number of items then loading is deferred (items is collapsed perhaps) until the user clicks expand.
    I notice that TinyMCE is doing a hell of a lot at startup, could the same flag be applied, defer initialising if multiple TinyMCEs are on page?

    Many thanks
    ecoad

  • Could be related to this issue, which I had created a patch for 5.1.7.1
    http://support.advancedcustomfields.com/forums/topic/unnecessary-ajax-calls/

  • Hi. I use ACF a lot and love all the features you’ve made available, particularly the convenience of the repeater fields and conditional rules.
    However, in trying to use this for websites that require a lot of conditional logic (as a layout builder of a sort) I’m having the same issue with the admin area mentioned above – specifically with extremely slow opening the page, creating a new field and saving the page.
    On the front end the load time is fine so this is really just an issue for the admins and managers.
    Even if I make no changes to existing field values and attempt to save the page there’s a major slowdown. Shouldn’t it be checking for changes to field values before saving? Then if no changes have been made, shouldn’t it skip the fields and not do anything at all?
    I don’t want to switch to anything else as I haven’t found anything else as feature rich or as simple to manage on the admin area (and with all these nifty filters and actions) but looking forward I can’t see being able to continue using this as our standard plugin if it isn’t adjusted to have a lighter touch and to not do things when it doesn’t have to. I’d be forced to go back to hand-coding stuff or using a less feature-rich plugin, which would suck 🙁 I’d much rather use ACF.
    Could we please know if this is being worked on? The conditional rules are an essential function with as many fields as I’m working with so I can’t simply not use them…and this behavior makes it nearly unusable in some cases.
    But I don’t want to end this without saying another ‘thank you’ to you for building this in the first place. It speeds up me and my teams’ work considerably 🙂

  • I currently have the same issue. I am also using a lot more conditionals than it should be because tabs seem to have a problem with them. When there is, let’s say, a field to check (true/false) that makes a tab and its sub-fields appear, the tab appears but the sub-tabs aren’t checked on by the conditionals. In other words, if they are set to appear at another conditional inside the tab, they still are showing.

    Ex.:

    – Show content boxes (checkbox = checked)
    — Tab showing wysiwyg boxes (appears as per conditional)
    — Content box wysiwyg (showing as per conditional)
    — Show alternate content (checkbox = not checked)
    — Alternate content box wysiwyg (showing, conditional not respected)

    I had to add a conditional that applies to each sub field that checks both checkboxes (inside and outside the tab) which adds a lot more than necessary and slows down everything.

    Maybe using Zepto instead of jQuery would help out fiddling a little less with the dom? Is all the dom play necessary?

    acf-export-2....zip

  • Guess 1 :

    @elliot     In my case, it seems it is the great number of TinyMCE WYSIWYG that slows things down. I’ve looked at the code in acf-input.js and there’s a different tinymce.init for every field (which is logical), but since mine were had all the same params, I’ve tried to “cache” all the ones with the same params to init them all at the same time in the same call, but the only effect that had was to prevent loading the CSS files again and again. Which didn’t correct the problem completely even though I saw a really small difference in loading time.

    Guess 2 :
    My other guess is the WOFF fonts. I don’t know why, but in my Chrome developer tools, I see those loading right after as if they were the one to block the loading. Couldn’t figure out why the server wouldn’t cache them, which should rule out that guess as well.

    Guess 3 :
    Before activating script debug mode, it seemed to block ad a load-scripts.php call with a lot of scripts in it. But after activating the debug mode, I’ve seen it didn’t seem to be this one that was causing the slowdown, but much more the 54 calls to tinymce.js… Why 54? I don’t know. I only had 25 tinymce fields in view at the time.

    Guess 4 :
    (╯°□°）╯︵ ┻━┻

  • Has this topic been abandoned? I too am having this issue. I built a page template for a client to showcase breweries at an upcoming event. There are 14 subfields inside 124 repeater fields and that seems to be the limit the browser will handle. I have upped their max_input_vars to 6000 but still no dice. I don’t want to have to go back to them and say “Sorry that’s all it can handle.” If I had known this would happen I would have made the breweries into their post type and looped through them like that. Will this issue ever be resolved? Is there a way to show like 20 repeater fields and then paginate the rest in the admin area? Or do something similar to what was done here (http://sevenspark.com/wordpress/speeding-up-the-appearance-menus-screen-in-wordpress-3-6) for WP menus prior to 4.3?

  • for me this one was resolved by upgrading. I couldn’t get the regular acf repeaters to work right and this remained an issue (last i left it) but when i moved to acf pro, it seems to be built differently so this doesn’t happen. As a matter of fact i switched from repeaters to layouts and used the flexibile layout builder with repeaters and other stuff in each layout, resulting in even more wysiwyg fields and the like, and it still works fine.

  • For me I ended up switching from repeater fields on the page template to instead making a custom post type. The custom post type served as the repeater field and the sub fields then just became regular fields within each single post. Then I just looped through the CPT with their fields on a custom page template. That way the vast amount variables aren’t all on one page in the admin area but only about 14 or so on their respective single posts. This turned out to be a better way to do it anyway and was how I should have done it in the first place.

  • I think that moving from repeaters to layouts can have a positive effect when using many editor fields, but @uptownbrent seems to have a great solution when you think about it.

    Each item that can be repeated, depending on your project, probably can be transformed in a custom post type in which ACF has some fields and then using a repeater or multiple select to link the posts to the original one.

    It’s not as convenient as having all the fields in the same page, but it allows ACF to breathe and to structure things more tightly to your concept.

  • I just finished reading through this thread and am still having a similar problem today as the one this thread describes. The agency I work for has started using flexible content fields to make our designs modular. Each module typically has it’s own flexible content layout. One such layouts uses a repeater to provide the user with column layouts. Each row of the repeater represents a “column” in that layout. Among the options in each row there is a content field that uses a WYSIWYG.

    I noticed page load suffering in a big way the further i got into development. Each time I added a new column layout, each with it’s own set of WYSIWYG Editors, the longer it took to reload/load the page.

    In development I was laying out a design that featured several variations of 1, 2, 3, 4 column layouts. In all there are 39 editors on this page causing a page load time of 18+ seconds. I understand this is an extreme case but this is hardly the only layout where WYSIWYG editors are going to be. After a couple hours debugging I came across an old support forum post suggesting that setting the default tab to “text” on the editor might solve the problem. I dug into the codex and learned that there is a filter for doing exactly that.

    Solution might be a strong word. I definitely saw an improvement. Using this function i was able to reduce the load time by more than 10s. From an average of 18.41s to 8.37s

    //set default tab on WYSIWYG
//return html for the "Text" tab
//return tinymce for "Visual" tab
function tiny_mce_default_tab() {
    return 'html';
}

add_filter('wp_default_editor', 'tiny_mce_default_tab');

    I hope this will help someone else as frustrated by this issue as I’ve been. If you discover an actual solution to this I would greatly appreciate a reply to this post.

    Love,
    Sean

  • Following up on @sdempsey I found that loading pages with large numbers of TinyMCE fields caused the issue. Disabling TinyMCE “fixed” the issue, except that the client isn’t going to be learning HTML to make changes.

    I was also able to get the page load, though at an incredibility slow speed, by switching the WYSIWYG fields to Basic.

    My current solution is to force the page to load in HTML, then to switch to WYSIWYG after load.

    In functions.php, I am adding to @sdempsey code:

    function load_custom_wp_admin_style_scripts() {
    wp_enqueue_script( 'admin-script', get_template_directory_uri() . '/assets/js/admin.min.js', array( 'jquery' ), '20120202', true );
}
add_action( 'admin_enqueue_scripts', 'load_custom_wp_admin_style_scripts' );

    For the admin JS, all I am doing it clicking on all of the Visual switch buttons after the page loads.

    jQuery(document).ready( function(){ 
	jQuery('.wp-switch-editor.switch-tmce').click()
});

    Not a great solution, but it’s working for now.

  • My solution posted above isn’t working consistently at all. Any chance this is being looked at by the team?

  • We have the exact same problem. We are using flex content with wysiwyg and some other fields and the backend is unusable. Scrolling will kill the browser. There is a serious issue with the JS in the ACF version. We are using pro btw.

    Could the developers please have a look at this.
    At the moment, the plugin is not scalable for bigger, more complex environments. We would love to use ACF for future projects, but this really concerns me.

  • Adding onto this thread – similar use case, repeater fields with nested repeaters options and TinyMCE as a page/content builder. DB queries are through the roof even with db caching and transients enabled. There’s just no getting around it.

    ACF is an indispensable WP tool i’ve built dozens of sites with it and consider it one of the finest crafted plugins i’ve ever used. However, this need to be addressed and fixed asap – it critically limits it’s usefulness at best, and at worst can result in a crippled website.

    If I can help with that process in anyway let me know please.

  • Having the same Issues. Just pitched the client to move away from Visual Composer for speed issues and now ACF Flexible Content with repeating WYSIWYG is causing 502 on post update hook.

Viewing 25 posts - 51 through 75 (of 97 total)
1 2 3 4

The topic ‘JS performance issues’ is closed to new replies.